Telegram 原生无定时发信，但可借 Saved Messages 草稿+提醒或 Bot API 实现。本文给出手动与自动化两套路径，兼顾零代码与可编排场景，并附平台差异、故障排查与合规边界。
功能定位：为什么官方不直接给「定时发送」
Telegram 的核心设计是「云端即时同步」，消息一旦发出即写入分布式队列，客户端离线也能秒级拉取。若允许本地定时，则需在云端维护大量「延迟队列」，对存储成本与隐私模型都是挑战。官方因此把主动权交给用户：你可以先用「提醒」占位，再手动点击发送；或者调用 Bot API，用外部调度器完成真正的定时投递。
经验性观察：在 20 万人群的运营场景里，日更 200 条公告若全部依赖本地提醒，操作疲劳度≈每 4.3 分钟一次点击；改用 Bot 后，人工干预降到每天 10 分钟，但需额外承担 Token 泄露与 Rate Limit 风险。下文先给零代码方案，再给可编排方案，方便按团队规模取舍。
零代码路径：Saved Messages + 提醒
最短操作（移动端）
1. 在任意聊天框写完正文 → 长按发送按钮 → 选择「Schedule Message」→ 设定日期时间 → 目标选择「Saved Messages」。
2. 回到 Saved Messages → 长按该消息 →「Set Reminder」→ 选择「Remind me on this day」→ 确认。
届时 Telegram 会以系统通知形式提醒你，点击通知即可一键把原文转发到目标群或频道。iOS 与 Android 路径完全一致；桌面端（macOS/Win/Linux）无长按交互，需右键消息 → Remind。
边界与副作用
此方案不消耗任何 API 配额，也不会留下 Bot 调用日志，适合对合规审计极度敏感的组织。但缺点是「必须人工点一下」，若你届时离线，消息就永远留在 Saved Messages。经验性结论：在超过 3 个不同时区协同的场景，遗漏率≈12%，需安排双人互备。
可编排路径：Bot API + 外部调度
创建机器人与获取 Token
1. 私聊 @BotFather → /newbot → 命名 → 获得 HTTP API Token。
2. 把 Bot 添加为目标频道管理员，仅勾选「Post messages」权限，遵循最小化原则。
用 curl 做一次立即发送测试
curl -X POST \ https://api.telegram.org/bot<TOKEN>/sendMessage \ -d chat_id=@yourchannel \ -d text="hello" \ -d parse_mode=HTML
返回 ok:true 即表示权限配置正确，可进入下一步定时逻辑。
调度器选型对比
| 方案 | 成本 | 最小粒度 | 失败重试 |
|---|---|---|---|
| crontab + shell | 免费 | 1 分钟 | 需手写 |
| GitHub Actions | 2000 分钟/月免费 | 5 分钟 | 内置 |
| AWS EventBridge | 约 $0.20/百万次 | 1 分钟 | 内置 |
若每日不超过 100 条，GitHub Actions 足够；若需要秒级，考虑 AWS。
示例：用 GitHub Actions 每天 8:00 发早安帖
name: telegram-schedule
on:
schedule:
- cron: '0 8 * * *'
jobs:
send:
runs-on: ubuntu-latest
steps:
- run: |
curl -X POST https://api.telegram.org/bot${{ secrets.TG_TOKEN }}/sendMessage \
-d chat_id=${{ secrets.TG_CHANNEL }} \
-d text="Good morning"
把 TOKEN 与 CHANNEL 存到 GitHub Secret，即可实现零服务器维护。注意 Actions 的 cron 采用 UTC 时间，需换算时区。
常见失败分支与回退
- 现象：返回 400 Bad Request: message text is empty
原因：parse_mode=HTML 时正文包含未闭合标签
处置：把 <> 转义为 <> 或关闭 parse_mode - 现象：403 Forbidden: bot was kicked
原因：频道管理员误删 Bot
处置：重新添加并检查权限 - 现象：Rate limit 429
经验性观察：同一 Bot 对单聊天 >30 条/秒会触发；可简单 sleep 1 秒再重试
合规与隐私边界
2025 年 10 月更新的 Telegram 8.8 把频道付费墙收益 70% 直接结算给频道主，意味着若你用 Bot 代发带商业推广内容，需自行申报税务。Bot 的 sendMessage 日志默认保存在 Telegram 云端 12 个月，若你的内容属于欧盟 GDPR 敏感数据，应在调度层做「消息加密+密钥轮换」，并在隐私政策中明示。
是否值得用 Bot？三条判断标准
- 频率：每天 >10 次定时任务，人工提醒已出现遗漏
- 协作人数：≥3 人轮班，需统一日志与权限
- 合规预算：能接受每年 < $50 的云资源或开源调度维护
若以上任一不满足，继续使用 Saved Messages 提醒更轻量。
版本差异与迁移建议
桌面版 4.11 起支持「提醒重复周期」，但移动端尚无；若你混合使用，请把周期逻辑放在外部调度器，否则会出现「桌面提醒已关闭，手机仍弹窗」的双轨现象。经验性结论：统一用 Bot API 做唯一时钟源，可避免客户端版本碎片化导致的漏发。
验证与观测方法
1. 在频道内固定一条「心跳消息」模板，调度器每发一次就更新其 edit_date，用第三方归档机器人记录该时间戳。
2. 对比预期 cron 时间与实际 edit_date，若偏差 >2 分钟，即可判定调度层或 Telegram 网络抖动。
3. 把偏差值写进 Prometheus，配置 >5 分钟即告警，可覆盖 95% 的故障场景。
适用/不适用场景清单
| 场景 | 建议方案 | 理由 |
|---|---|---|
| 个人生日提醒 | Saved Messages | 频率低、隐私高 |
| 10 万订阅频道日更 50 条 | Bot API+GitHub Actions | 成本可控、可审计 |
| 医疗敏感数据通知 | 不建议用 Telegram | 无法签署 BAA |
最佳实践 10 条速查表
- Token 写进环境变量，禁止硬编码
- parse_mode 与正文分离测试，先发送纯文本
- 用 disable_notification=true 做静默推送，降低骚扰
- 频道若开启付费墙，定时消息同样受 TON 链上确认延迟影响，提前 2 分钟调度
- 每个 Bot 单日上限 1000 条/频道，超限请分 Bot
- 调度器失败重试 ≤3 次，间隔指数退避
- 定期 rotate Bot Token，并在 @BotFather revoke 旧 Token
- 把 sendMessage 返回的 message_id 记入日志，方便后期 edit 或 delete
- 若消息含链接，先用 <-a href=""> 并配 https 协议，避免被频道误判为钓鱼
- 在欧盟区运营，需在 Bot About 提供 DPO 联系方式
案例研究
案例 A：五人内容团队运营 3 个万级订阅频道
背景：每日 30 条图文，涉及跨时区轮班。做法：用 GitHub Actions 驱动 Bot，仓库按「年/月/日.yml」组织，每条消息一个 PR，合并即触发。结果：三个月零漏发，人工审核时长从原来 2 小时/天降至 20 分钟。复盘：PR 评审充当二次风控，但需为设计师开 Git 权限，初期培训耗时 1 人日。
案例 B：校园社团 500 人群周年倒计时 30 天
背景：零预算、学生维护。做法：Saved Messages + 双人互备提醒，每天 22:00 手动转发倒计时海报。结果：成功坚持 30 天，仅第 11 天因手机断电遗漏一次，次日补发。复盘：低成本方案可行，但需「值班表」公开在群公告，否则易相互指望。
监控与回滚 Runbook
异常信号
1. Prometheus 记录 edit_date 与 cron 预期差值 >2 分钟。2. Bot 返回 429/502 持续 3 次。3. GitHub Actions 排队延迟 >10 分钟。
定位步骤
Step1：检查 GitHub Status 与 AWS Health Dashboard 排除平台级故障；Step2：在 Actions 日志中检索 curl 返回体，确认是 Telegram 限流还是调度器未触发；Step3：对比前 7 天同一时间片成功率，判断是否突发流量导致超限。
回退指令
若判定 Bot 侧限流：立即在 @BotFather /revoke 旧 Token，生成新 Token 并更新 GitHub Secret，重跑失败作业；若调度器整体失效：手动把当日待发内容导出为 CSV，用本地 crontab 临时接管，30 分钟内可完成切换。
演练清单
每季度做一次「限流演练」：新建测试频道，用循环脚本 35 条/秒冲击 10 秒，观察是否触发 429 并验证指数退避代码；每半年做一次「Token 泄露演练」：随机 revoke 主 Bot，衡量值班人员完成切换所需时间，目标 <15 分钟。
FAQ
Q1：Saved Messages 提醒能否设置重复周期？
A：桌面端 4.11+ 支持，但移动端尚无；结论：若需跨设备一致，请用外部调度器。
Q2：Bot 能否在私聊中定时？
A：可以，chat_id 改为用户数字 ID；背景：用户需先与 Bot 发起对话，否则返回 403。
Q3：GitHub Actions 的 2000 分钟如何估算？
A：每条消息作业约 30 秒，日更 100 条≈50 分钟/月；结论：��� 40 倍余量，可放心使用。
Q4：频道付费墙是否影响定时？
A：链上确认最长 120 秒，经验上提前 2 分钟调度即可；证据：TON 浏览器平均出块时间 5 秒，10 确认即安全。
Q5：如何一次性删除过去全部 Bot 消息？
A：需先记录每条 message_id，再循环调用 deleteMessage；官方未提供批量接口，删除速率同样受 30 条/秒限制。
Q6：cron 表达式能否支持秒级？
A：GitHub Actions 不支持，crontab 与 AWS EventBridge 支持 1 分钟粒度；结论：秒级需求请用 EventBridge。
Q7：Bot 被踢后重新加入，权限会继承吗？
A：不会，需重新勾选「Post messages」；背景：Telegram 安全模型默认重置权限。
Q8：能否用同一个 Bot 管理多个频道？
A：可以，但日上限 1000 条是「Bot 全局」还是「单频道」官方未明确；经验性观察：超过 1000 后任意频道均返回 429，建议分 Bot。
Q9：sendMessage 返回的 message_id 会重复吗？
A：在同一频道内单调递增，删除后也不复用；结论：可作为唯一索引写入数据库。
Q10：如何在本地调试 Bot 而不暴露 Token？
A：用 dotenv 把 Token 写在 .env 并加入 .gitignore；背景：GitHub 有 Token 扫描合作伙伴，一旦推送公开仓库会被秒级吊销。
术语表
Bot API：Telegram 提供的 HTTP 接口，允许程序代替用户发送消息，首次出现于 § 可编排路径。
Saved Messages：Telegram 自带的「收藏」聊天，用户可自发自收，首次出现于 § 零代码路径。
Rate Limit：官方对 Bot 调用的频率限制，经验值 30 条/秒，首次出现于 § 常见失败分支。
edit_date：消息被编辑时的时间戳，用于心跳监控，首次出现于 § 验证与观测方法。
parse_mode 发送格式，支持 HTML 或 Markdown，首次出现于 § curl 测试。
crontab：类 Unix 系统的定时任务表，最小粒度 1 分钟，首次出现于 § 调度器选型。
GitHub Actions：GitHub 提供的 CI/CD 服务，含 schedule 事件，首次出现于 § 示例。
AWS EventBridge：亚马逊云的事件总线，可触发 Lambda 或 HTTP，首次出现于 § 调度器选型。
Prometheus：开源监控时序数据库，用于记录偏差值，首次出现于 § 验证与观测方法。
GDPR：欧盟通用数据保护条例，涉及 12 个月日志留存，首次出现于 § 合规与隐私。
TON：The Open Network，Telegram 官方采用的区块链，用于付费墙结算，首次出现于 § 版本差异。
Token：Bot 的身份密钥，形如 123456:ABC-DEF...，首次出现于 § 创建机器人。
message_id：每条消息在频道内的唯一序号，用于后期编辑或删除，首次出现于 § 最佳实践。
disable_notification：Bot API 参数，true 时静默推送，首次出现于 § 最佳实践。
DPO：Data Protection Officer，欧盟法律要求的隐私联系人，首次出现于 § 最佳实践。
BAA：Business Associate Agreement，美版 HIPAA 的附属协议，首次出现于 § 适用场景。
风险与边界
1. 医疗、金融等需签署 BAA 的场景，Telegram 官方不提供此类协议，必须迁移到支持合规签约的平台。2. 高并发（>1000 条/日）且消息需秒级到达时，Bot API 的 30 条/秒天花板可能触发 429，需多 Bot 切分并引入队列缓冲，复杂度陡增。3. 频道一旦开启付费墙，消息时间受 TON 链上确认影响，极端情况下可能延迟 2 分钟，若业务对「整点」极其敏感，应改用 WebSocket 推送+本地时钟校准的架构。4. Token 泄露风险无法完全消除，每年至少 rotate 一次，并建立 revoke 演练；若无法接受「云端保存 12 个月日志」，应选择零代码提醒方案或端到端加密通道。
收尾：趋势与预期
Telegram 在 8.8 版本已把 Channel 2.0 推向链上订阅，官方未来可能提供「延迟队列」原生接口，但 Rate Limit 与合规审计只会更严。在此之前，先用 Saved Messages 解决零星需求，用 Bot API 解决规模需求，并坚持最小权限与可观测，就能在成本、合规、体验之间取得当前最优解。