LINE webhook 的 standby 模式：为什么没有 replyToken？
如果 LINE webhook 事件包含 mode: standby，收到事件并不代表你的 channel 应该回复。LINE 的模块频道文档明确说明：待机频道不应发送消息，其 webhook 事件也不会包含 replyToken。这是 Chat Control 主导权问题，不是 token 过期或 webhook 投递失败的证据。先检查事件模式和接入类型，再决定是否回复。
要点
- webhook 可以成功到达，但当前频道不是回复方。
- 不要因为缺少
replyToken就自动改发 push 消息。 - 模块频道属于特定企业接入功能，不是所有机器人都能直接启用的设置。
- 事件接收、回复归属和发送结果应分别管理。
LINE webhook 的 active 与 standby 是什么？
官方模块频道 Messaging API 指南要求在回复前检查 mode。在文档描述的模块接入关系中，只有一个关联频道处于 active，其余为 standby。
| 事件模式 | 文档含义 | 应用侧处理 |
|---|---|---|
active | 接收频道拥有聊天主导权，可以发送回复或 push | 继续检查事件类型与正常发送条件 |
standby | 接收频道处于待机，事件没有 replyToken | 可处理获授权的内部任务，但不向客户发送消息 |
| 缺失或无法识别 | 尚未确认当前接入的数据契约 | 检查原始事件和解析器，不默认当作 active |
最后一行是建议的防御性策略，不是 LINE 新增的模式。active 也不代表所有事件都会提供回复 token，或都需要回复；应查阅 Messaging API 参考中的具体事件定义。
这与多个普通工具共用一个 Messaging API channel 不同。多工具接入检查表解决共享凭据、webhook 所有权及配额问题；模块接入还涉及另一个问题：目前由哪个频道主导回复？
先确认 Module 文档是否适用
LINE 说明，Module 功能仅供完成规定申请的企业客户使用。不要默认普通机器人有资格关联模块或调用 Chat Control 操作。
Chat Control 指南还提示：目前提供的模块频道在关联时会自动取得主导权，即 Default Active，通常不需要手动控制。因此，看到这份文档并不意味着应该给每个 webhook handler 都加上取得或释放主导权的调用。
先完成以下检查：
- 确认请求对应的 Official Account、接收频道及供应商集成。
- 向集成负责人确认是否关联了模块频道。
- 检查安全保存的原始事件，不只看经过转换的队列记录。
- 对比解析前后
mode的值与replyToken是否存在。 - 主导权不符合预期时，由负责的模块供应商调查，不要无依据地更换 token 或 webhook URL。
日常日志不应保存频道凭据或回复 token。排障记录可以只写“token 是否存在”，无需记录其值。
先判断缺失，再调查过期
token 缺失、token 过期和发送响应丢失，处理方式不同。
| 观察结果 | 应调查什么 | 不应采取的动作 |
|---|---|---|
原始事件是 standby，没有 token | 聊天主导权与预期回复方 | 自行构造 token，或自动改发 push |
| 原始事件有 token，worker 却没有 | 解析、序列化及队列映射 | 用变更主导权修复数据转换错误 |
| active 事件没有 token | 该事件的数据定义与接入上下文 | 认定所有 webhook 都能回复 |
| 有 token，但回复失败 | 实际 API 响应、使用记录和处理延迟 | 把所有失败都归因于 standby |
| 发送请求超时 | 请求是否处于结果未知状态 | 立即通过另一个操作发送同样内容 |
如果确实收到过 token，只是使用太晚或重复使用，请转到 LINE 回复 token 排障指南。它与“事件本来就不提供 token”是两条不同路径。
将观察事件与回复权限分开
建议接收端先走正常的验签和持久化流程。LINE 的 webhook 接收指南说明接收与重投机制。不要故意让有效的 standby 投递失败，期待下次重投就能获得主导权。
接收后，先分类，再创建发送任务：
- **Standby：**仅保留获授权内部处理所需的数据，并记录本次没有发出客户回复。
- **Active 且事件可回复：**由一个业务操作评估是否回复，并管理去重及发送结果。
- **契约不明：**暂停自动发送，交由负责人调查，不悄悄当作 active。
这些都是应用内部决策，不是额外的 LINE 字段或 API 状态。保留事件到达时的 mode；不能因为后来出现 active 事件，就把旧 standby 事件改为 active，或认为获得了回复旧消息的新许可。
对于延迟任务，发送前应遵循集成当前的回复归属策略。如果无法确认归属，暂缓发送并人工核查，而不是换一种消息操作。仅对事件去重，无法决定多个工具中谁应回复。
建议测试以下场景：standby 消息不发送、active 且可回复的事件、解析器丢失 token、重复投递，以及排队期间回复归属变得不确定。这些是验收建议，不是生产测试结果。
UnifyPort 的适用位置与边界
UnifyPort 的非官方接口是独立的账号接入路径。LINE 授权参考描述二维码登录，以及异步提供的二维码 URL 和 PIN。它不是模块关联流程，也不会取得 Official Account 的聊天主导权。
在这条独立路径中，使用文档定义的标准化 message.received 事件。Webhook 投递契约说明配置 signing_secret 后的签名验证。不要将 LINE 原生的 mode 或 replyToken 假设套入这一结构，也不要把 UnifyPort 发送描述为恢复 Official Account 缺失的 token。
如果消息必须由 LINE Official Account 发出，应继续使用官方 Messaging API，并与模块供应商确认主导权。换成另一个已连接账号，不是 standby 的自动补救措施。
常见问题
standby 是否说明 webhook 离线？
不是。事件可能已正常到达。standby 描述接收频道的聊天主导权，不是服务器连接状态。
没有 replyToken，能否直接改发 push？
不能将它作为 standby 的自动补救方案。LINE 要求待机接收方不发送消息；问题在于谁应回复，而不仅是调用哪种发送方法。
active 一定会提供 replyToken 吗？
不会。还要检查具体事件是否支持回复。active 本身不能让所有事件都可回复。
每个 LINE 机器人都需要实现 Chat Control 调用吗？
不需要。Module 有特定申请要求，当前指南也说明了 Default Active 行为。添加控制操作前，先确认实际架构。
下一步与参考资料
将安全保存的事件与官方模块频道指南对照，并明确由哪个组件负责回复。如果需求是独立账号接入，请查看 UnifyPort LINE 授权契约。
官方资料核对日期：2026-10-27。
让消息接入变成一条稳定的产品管线。
先用统一 API 跑通发送，再用标准事件把所有入站消息接回业务系统。