LINE Login 与 Messaging API 的用户 ID 不同？先检查 Provider
同一个人的 LINE Login 与 Messaging API 用户 ID 不一致时，先检查两个 channel 所属的 LINE provider。LINE 按 provider 分配用户 ID：同一用户在同一 provider 下，不同类型的 channel 会取得相同 ID；跨 provider 则不同。不要按显示名称合并客户，也不要以为更换 token 就能统一这些 ID。
核心要点
- 先核对 provider 归属，再调整登录或 webhook 配置。
- API 用户 ID、用于搜索好友的 LINE ID、显示名称不是同一概念。
- 已创建的 channel 不能移动到另一个 provider。
- 统一消息结构不等于统一客户身份。
为什么 LINE Login 与 Messaging API 用户 ID 会不同
LINE 的获取用户 ID 文档明确说明：身份命名空间取决于 provider，而非 channel 类型。
| 比较对象 | 官方说明或判断边界 | 应用处理 |
|---|---|---|
| 同一用户，同一 provider 下的 Login 与 Messaging API channel | 用户 ID 相同 | 在该 provider 范围内比较已验证的 ID |
| 同一用户，不同 provider 下的 channel | 用户 ID 不同 | 在明确的账号关联流程完成前保持独立 |
| 显示名称相同 | 不能证明是同一人 | 不自动合并 |
| 用于搜索的 LINE ID 与 API 用户 ID | 不同标识 | 获取正确的 API 值，而不是个人资料中的搜索 ID |
例如，面向海外客户的网站登录 channel 与客服 Messaging API channel，可能由不同团队建立在不同 provider 下。这只是配置示例，不是客户事故。此时 CRM 查询失败，并不证明 LINE 意外改变了用户身份。
还要区分两个同名概念：LINE provider 是 LINE Developers Console 中的渠道归属分组；UnifyPort 的 provider: line 表示消息平台。二者不是同一个命名空间。
先排查来源，不急着改配置
- 标明两个 ID 的来源。 记录生成它们的 channel，以及来自可信登录流程还是 Messaging API webhook。不要把手工输入的名字拿来与 API 标识比较。
- 查看 provider 归属。 在 LINE Developers Console 打开两个 channel，记录所属 provider；同时区分测试与生产环境。名称相似不代表归属相同。
- 使用受控测试用户。 让指定账号登录并发送消息，比较服务端经过验证的记录，不使用无关截图或未经验证的客户端资料。
- 检查应用存储。 若 provider 相同而记录不同，先排查旧会话、实际登录用户、环境混用和字段映射错误。
- 暂停不确定的合并。 保留两份来源记录，不要为了让查询命中而直接覆盖其中一个 ID。
如果问题其实是多个工具争用同一官方账号的凭据或 webhook，请看多工具共用 LINE 官方账号检查清单。这是与用户 ID 范围不同的问题。
两个 channel 已经属于不同 provider，怎么办？
LINE 的登录接入指南说明，channel 创建后不能移动到其他 provider；需要关联的 Login 与 Messaging API channel 应从一开始就建立在同一个 provider 下。
对已经上线的系统，不要把删除再创建当成无影响的修复。先盘点登录依赖、凭据、回调和已有身份引用，再制定替换计划。新建 channel 并不能证明旧 CRM 映射会自动延续。
建议在应用中把外部身份与内部客户档案分开：保存来源系统、LINE provider、channel 来源及用户 ID，另行维护经过验证的内部客户关联。这是本地数据设计建议，不是 LINE webhook 新增字段。
确实需要跨 provider 关联时，应使用明确流程，验证相关账号的控制权并取得用户同意，保存关联依据且支持解除关联。名字或头像相同都不够。同一 provider 内的 ID 相同，也不表示权限或用户授权可以跨流程转移。
UnifyPort 身份与回复目标应分别保存
UnifyPort 的非官方接口提供独立的已连接账号消息通道。标准事件文档包含 provider、account_id、data.sender.id 和 data.conversation.id：sender 是发送者，conversation 是聊天。群聊中尤其不能混用。
| 本地记录 | 建议作用域 |
|---|---|
| 官方 LINE 身份 | 应用租户、LINE provider、已验证用户 ID |
| UnifyPort 发送者 | 工作区、provider、account_id、data.sender.id |
| UnifyPort 会话 | 工作区、provider、account_id、data.conversation.id |
| 内部客户关联 | 指向具体来源身份的显式验证关系 |
这种保守隔离是应用设计，不代表 UnifyPort 能转换官方 LINE 用户 ID。公开契约没有提供这种转换。不要删除前缀、改变大小写，或因字符串看起来相似就认定等价。
联系人列表文档分别返回 id、conversation_id、provider_user_id，并说明定位聊天或发送消息应使用 conversation_id。保存返回的映射，不要直接替换成联系人 ID。WhatsApp 联系人名称同步也涉及这一边界，但不能把其中的 contact.updated 行为套用到 LINE。
更新身份关系之前，按webhook 投递契约验证并持久化事件。签名有效只能认证收到的载荷，不能证明两个外部账号属于同一个人。
验收与限制
启用 CRM 自动关联前，测试同一用户同 provider、同一用户跨 provider、两个同名用户，以及不同 UnifyPort 消息账号。失败或模糊匹配应保持身份独立，不能静默合并聊天历史。
也要测试群聊：不能把发送者误当成原本要回复的会话。消息路由应独立于后续客户档案合并。
如果目标是 LINE Login 与官方账号身份关联，应使用官方 channel。UnifyPort 不会移动 channel、授予官方权限或自动建立跨 provider 身份等价关系。
常见问题
LINE Login 与 Messaging API 应返回相同用户 ID 吗？
同一 LINE 用户、同一 provider 时是。不同 provider 会分配不同 ID。
能通过移动 channel 修复吗？
不能。LINE 明确说明现有 channel 无法移到其他 provider，应在创建关联渠道前规划归属。
显示名称或 UnifyPort sender ID 能自动解决不一致吗？
不能。显示名称不是身份主键，公开文档也未定义官方 LINE 用户 ID 到 UnifyPort sender ID 的转换。
下一步与参考资料
先记录两个官方 channel 的 provider 归属。若另建已连接账号收件箱，请先阅读 UnifyPort 事件结构，设计有作用域的身份存储，再导入联系人。
官方资料核对日期：2026-10-05。
让消息接入变成一条稳定的产品管线。
先用统一 API 跑通发送，再用标准事件把所有入站消息接回业务系统。