顾客在 Telegram 里发了“查订单”，机器人却毫无反应。很多人第一反应是重启程序、重新部署，甚至重置 Bot Token；但如果问题出在群组权限、Webhook 配置或消息处理逻辑，这些操作不但无效，还可能造成更新丢失、重复回复或凭证泄露。
更稳妥的办法，是沿着消息经过的路径逐段确认：Telegram 是否收到消息、消息是否送达你的程序、程序是否处理成功、回复是否成功发出。下面以一个小店客服机器人为例，给出一套能缩小故障范围的排查流程。
先别重启：确认机器人在哪个场景不回复
先记录问题出现的位置和条件。是私聊完全没反应，还是只在群组里不理人？是所有消息都不回复，还是只有按钮、图片或某个命令失效？最好用自己的测试账号发送一条简单文本，例如“测试”，并记下发送时间、所在聊天类型和预期回复。
这个区分很关键：私聊正常、群组失灵，常常指向隐私模式、群组权限或命令格式；只有按钮失灵，则更可能是回调查询没有处理；所有场景都沉默，才需要优先检查程序运行状态和消息接收方式。
第一步：检查消息有没有送到机器人程序
使用 Webhook 的机器人
如果你的程序通过 Webhook 接收更新，先查看 Telegram 记录的 Webhook 状态。调用 getWebhookInfo 后，重点关注 url、pending_update_count、last_error_date 和 last_error_message。
url为空：当前没有设置 Webhook，程序却只等待 Webhook 请求时，自然收不到消息。pending_update_count持续增加：更新积压，可能是服务不可达、响应超时或处理程序报错。last_error_message出现连接或证书错误：检查域名解析、HTTPS 证书、防火墙和反向代理。
还要确认 Webhook 路由确实能收到 Telegram 的 POST 请求。服务器日志里应能看到请求时间、状态码和处理耗时。不要只看“网站能打开”：浏览器访问成功，不等于 Webhook 路由可以正常接收 POST。
使用长轮询的机器人
如果程序使用 getUpdates 长轮询，检查进程是否运行、轮询是否持续，以及日志里有没有网络超时或 API 错误。一个常见误区是：同一个 Bot 同时配置 Webhook 又调用 getUpdates。这两种接收方式不能同时使用，切换前应确认当前配置，避免程序看似在线却始终拿不到更新。
如果最近改过 allowed_updates，也要确认没有把实际需要的更新类型排除。例如只监听消息，却没有监听按钮回调，用户点按钮时程序就可能收不到对应事件。
第二步：确认更新到了，但业务代码有没有接住
如果日志能证明消息已经进入程序，就不要继续折腾网络配置，应该检查消息分发和业务逻辑。先记录收到的更新类型、聊天类型、消息文本或回调数据，再检查程序是否进入了对应处理函数。注意不要把用户隐私信息、完整聊天内容或 Bot Token 无差别写入公开日志。
群组消息与私聊规则不同
Telegram 群组中的机器人可能启用了隐私模式。启用后，机器人通常不会接收群里的每一条普通聊天消息，因此顾客直接发送“查订单”时，程序可能根本看不到这条消息。可先测试明确的命令，例如 /start 或 /help，并按机器人的设计尝试 /命令@机器人用户名。
如果业务要求机器人读取群内普通消息，再检查 BotFather 中的隐私模式设置，并确认群组管理员权限及程序过滤条件。不要为了省事就给机器人所有管理权限；只授予业务确实需要的权限，更安全也更容易定位问题。
检查命令、文本与按钮是否匹配
程序可能只处理以斜杠开头的命令，而用户输入的是自然语言；也可能只匹配精确文本，导致多一个空格、大小写变化或语言差异就不触发。对内测机器人来说，可临时加入一条兜底日志：收到消息但未匹配任何规则时，记录“未命中处理器”，并向测试账号返回清晰提示，而不是静默失败。
如果失灵的是内联按钮，检查是否收到 callback_query，并及时调用 answerCallbackQuery。只编辑按钮消息而不回应回调，用户界面可能一直显示加载状态，让人误以为机器人完全没反应。
第三步：检查程序是否发出了回复
“消息已收到”不等于“回复已送达”。检查发送消息的 API 调用结果和错误日志，重点留意目标 chat_id 是否正确、机器人是否被用户拉黑、是否在群里被限制发言，以及发送内容是否超过格式或长度限制。
如果 API 返回限流错误，按响应中的 retry_after 等待后再重试，不要在循环里立即连续发送。重试逻辑还应避免重复回复：可以为每条更新记录处理状态或更新 ID，确保网络超时后再次执行时不会给顾客发送两条相同答案。
小店客服机器人的15分钟排查顺序
- 第1—3分钟：分别在私聊和目标群组发送测试消息，记下时间、消息类型和是否出现提示。
- 第4—6分钟：查看 Webhook 状态或长轮询进程，确认 Telegram 更新是否进入服务器。
- 第7—10分钟：对照日志确认消息进入了哪个处理器，检查群组隐私模式、命令路由和按钮回调。
- 第11—13分钟：查看发送 API 的返回结果，核对聊天 ID、权限、限流和消息格式错误。
- 第14—15分钟：修复一个明确问题后，用同一条测试用例复测，并记录修改内容，避免同时改多个配置而无法判断原因。
这些“快速修复”可能让问题更严重
- 随手重置 Token：只有怀疑凭证泄露时才应轮换，并同步更新所有部署环境。切勿把 Token 发到群聊、截图或公开日志中。
- 同时切换 Webhook 和长轮询：先确认原有接收方式，再按计划切换；盲目混用只会增加排查变量。
- 立刻清空待处理更新：积压更新可能包含尚未处理的顾客请求，删除前先确认业务影响并做好记录。
- 无差别开放群组权限：先验证是否确实是权限问题，再只增加必要权限，不要把安全问题当作排障捷径。
建立可复现的故障记录，减少下次停摆
为每次故障保留一份简短记录：发生时间、私聊或群组、更新类型、接收方式、关键错误信息、修复动作和复测结果。再加上服务健康检查、Webhook 错误告警和限流监控，通常比反复重启更能缩短恢复时间。
排查电报机器人不回复，核心不是猜“哪里坏了”，而是确认消息最后出现在哪一层：没有进入服务器，就查接收配置和网络；进入服务器却没触发业务，就查过滤与处理器；程序处理了却没发出回复，就查发送 API、权限和限流。按这条路径逐段验证，既能更快恢复服务，也能避免误删更新或泄露机器人凭证。