Telegram 机器人群发怎么设计：订阅、限流与失败重试

“每天给所有订阅者发一条通知”听起来像一个循环，但可靠群发更像一项可恢复的批处理任务。机器人需要知道谁真正订阅、哪些消息已经发送、何时因限流暂停，以及某个用户屏蔽机器人后怎样停止重试。否则一次中断就可能造成漏发或重复发送。

Telegram 官方的机器人介绍明确：机器人不能主动与从未联系过它的用户开启对话，用户必须先发送消息或把机器人加入群组。grammY 的限流指南则建议把 429 当作正常控制信号：发送、遇到 429 后等待并重试，而不是忽略错误或无节制并发。群发需求应围绕这些边界设计。

先定义订阅名单，而不是导入用户名

机器人能发送通知的前提，不是你有一个用户名列表，而是目标聊天已经与机器人建立可发送关系。订阅记录至少应包含：

• 稳定的聊天标识，不只依赖可能变化的用户名；
• 用户明确订阅的主题或通知类型；
• 订阅时间、语言和时区；
• 最近一次成功或失败状态；
• 退订、屏蔽或永久失败标记。

提供 /subscribe、/unsubscribe 和 /status 等清晰入口。对营销或高频通知，还应在首次订阅时说明内容和频率，避免把“启动过机器人”直接解释为同意所有群发。

把一次群发保存成独立任务

不要只保存“当前循环到第几个用户”。更稳妥的设计会保存一次广播任务以及每个收件人的投递状态。

| 对象 | 建议字段 | | --- | --- | | 广播任务 | 内容版本、目标筛选条件、创建时间、状态、开始与完成时间 | | 收件人投递 | 任务 ID、聊天 ID、pending / sent / retry / failed、尝试次数、最后错误 | | 消息内容 | 可审阅的快照或版本标识，避免任务恢复后内容被悄悄替换 |

这样任务重启后可以继续 pending 和 retry 项，而不是从头再发。任务 ID 加聊天 ID 也可以作为幂等键，防止同一广播对同一用户重复创建成功记录。

429 是等待指令，不是普通失败

Telegram 会在请求过快时返回限流错误。可靠实现应读取返回的等待时间，在对应时间后重试，并控制并发。grammY 的 auto-retry 文档说明，带有 retry_after 的错误应等待指定时间；网络错误和服务端错误通常需要有上限的指数退避。

需求中应区分：

• 限流：等待后重试，不立刻标记永久失败；
• 临时网络或服务端错误：指数退避并限制最大次数；
• 无权限或被屏蔽：停止对该聊天继续发送，并更新订阅状态；
• 内容或参数错误：停止当前任务，先修复模板；
• 未知结果：查询本地投递记录，避免盲目重复。

不要用一个固定休眠值假装解决所有限制，也不要一次启动大量并行请求。具体吞吐会变化，正确策略是尊重 Telegram 返回的等待信息，并让任务可暂停和恢复。

重试必须与去重一起设计

一次发送可能已经被 Telegram 接收，但调用方在收到响应前断线。此时立即重发可能产生两条相同通知。业务上可以采取：

• 为每个“任务 + 收件人”只允许一个活动投递；
• 在尝试前记录发送状态和内容版本；
• 对未知结果设置人工复核或延迟确认，不进行紧密循环；
• 对可接受的重复场景使用明确的通知编号或日期；
• 恢复任务时只扫描未成功、未永久失败的记录。

Telegram API 的单次调用不能自动替你解决整个批次的 exactly-once 语义。更现实的目标是让重复可检测、可限制并能解释。

给运营者暂停、预览和统计

群发机器人至少应支持：

• 先向测试账号发送预览；
• 显示预计人数、主题、语言和内容版本；
• 开始前二次确认；
• 随时暂停，不再领取新的 pending 项；
• 从已保存的进度继续；
• 统计成功、重试中、永久失败和退订，而不是只显示一个总数；
• 对失败原因做聚合，不在群聊暴露用户清单。

若通知受时区或安静时段影响，应按订阅者设置分批，而不是按服务器时区一次发完。Telegram Serverless 是否提供定时触发或外部调度必须按当前平台能力核验，不能因为代码能表达时间就假设运行环境会自动唤醒。

可直接使用的需求模板

创建一个订阅通知机器人。用户可订阅、查看状态和退订。管理员创建广播草稿，选择主题和语言，先发送预览并确认后启动。每次广播保存独立任务，按任务和聊天去重；重启后从未完成收件人继续。遇到 429 时按返回等待时间暂停后重试，临时错误使用有上限的退避，被屏蔽或无权限时停止重试并标记该订阅。管理员可暂停、继续，并查看成功、重试、永久失败和退订数量。

验收清单

• 从未启动机器人的用户名不能被误认为可发送订阅者。
• 同一用户重复订阅只保留一个有效订阅。
• 同一广播任务恢复两次，不会给已成功用户再发一遍。
• 模拟 429 后，任务等待并从原进度继续。
• 模拟网络中断，不会形成无限快速重试。
• 用户退订或屏蔽后，不再进入后续任务。
• 暂停后没有新的收件人开始发送，继续后不丢进度。
• 内容变更会产生新版本，不会悄悄改变正在执行的任务。
• 统计总数能与各状态明细对上。

与 BotFatherV2 的关系

BotFatherV2 可以用 AI 对话创建和修改 Telegram Serverless 机器人。将订阅、任务状态、退订、限流和失败分类写清楚，有助于把“群发通知”转化为可验收的机器人需求。

这不代表平台已经提供任意队列、定时器、外部数据库或大规模付费广播能力。公开文档说明生成代码受固定 SDK 范围约束；第三方服务、运行环境调度和费用都需要单独确认。首版 AI 开发也不新增依赖付费 AI 的机器人运行能力。BotFatherV2 是独立产品，与 Telegram 官方 BotFather 无隶属关系。

参考资料

• Telegram，Bots: An introduction for developers，访问于 2026-10-13。
• grammY，Scaling Up IV: Flood Limits，访问于 2026-10-13。
• grammY，Retry API Requests，访问于 2026-10-13。
• BitBear Studio，使用 AI 开发，访问于 2026-10-13。