Bot 服务因为发版、服务器维护或者意外崩溃而重启，是再常见不过的事情。问题是，很多 Bot 在重启之后悄无声息，用户发消息过来半天没反应，还以为 Bot 挂了。如果能
一、先把 chat_id 持久化，别让重启清空用户列表
要主动给用户发消息，前提是知道往哪里发。Telegram 的 Bot API 不提供“获取所有曾对话用户”的接口，所以你必须自己在用户第一次与 Bot 交互时，把对方的 chat_id 存下来。存哪里都行，SQLite、Redis、甚至一个 JSON 文件都可以，关键是不能只放在内存变量里，否则进程一重启数据就没了。
比较推荐的组合是：开发阶段用 SQLite，上线后换 PostgreSQL 或 Redis。下面的例子用 Python 展示如何在收到消息时自动记录 chat_id：
import sqlite3
def init_db():
conn = sqlite3.connect("bot_users.db")
conn.execute("""
CREATE TABLE IF NOT EXISTS users (
chat_id INTEGER PRIMARY KEY,
username TEXT,
first_seen TEXT DEFAULT CURRENT_TIMESTAMP
)
""")
conn.commit()
return conn
def save_user(conn, chat_id, username):
# INSERT OR IGNORE 防止重复插入
conn.execute(
"INSERT OR IGNORE INTO users (chat_id, username) VALUES (?, ?)",
(chat_id, username)
)
conn.commit()在轮询或 Webhook 的入口处调用 save_user，只要用户给 Bot 发过一次消息，他的 chat_id 就永久保存下来了。有些开发者只在收到 /start 命令时记录，这样会漏掉通过深链接直接进入的用户，建议在所有消息入口统一记录。
如果你用的是 node-telegram-bot-api 或 grammY 这类框架，思路完全一样：在 message 事件或者中间件里把 msg.chat.id 落库即可。持久化这一步做完，重启后才有能力找回“要通知谁”。
二、捕获启动时机，发送上线通知
有了用户列表，接下来就是在 Bot 启动完成、能正常处理消息之后，触发一次批量通知。时机很重要：不要在进程刚拉起、还没连上 Telegram 服务器时就发，那样可能因为网络未就绪而失败。正确做法是在轮询启动、Webhook 注册完成之后再执行通知逻辑。
Python-telegram-bot 库提供了 post_init 钩子，专门用于应用初始化完成后的回调，非常适合放这段代码：
from telegram.ext import Application
import asyncio
NOTIFY_TEXT = "机器人已完成重启，服务恢复正常，感谢耐心等待！"
async def notify_all(app):
rows = db_query_all_users() # 从数据库读取全部 chat_id
for chat_id, in rows:
try:
await app.bot.send_message(chat_id=chat_id, text=NOTIFY_TEXT)
except Exception as e:
# 用户可能已屏蔽 Bot，记录日志继续处理下一个
print(f"发送失败 {chat_id}: {e}")
await asyncio.sleep(0.05) # 控制频率，避免触发限流
async def post_init(app):
await notify_all(app)
def main():
app = Application.builder().token(TOKEN).post_init(post_init).build()
app.run_polling()这段代码里有三个细节值得注意。第一是 asyncio.sleep(0.05)，Telegram 对 Bot 广播有严格限流，全局每秒大约 30 条消息，间隔 50 毫秒是比较稳妥的节奏，用户量大时还要考虑任务队列。第二是异常捕获，用户一旦屏蔽了你的 Bot，调用 send_message 会抛出 403 错误，此时应该把这个 chat_id 标记为失效，下次广播时跳过。第三，通知文案要克制，频繁重启的 Bot 每次都打扰用户会引起反感。
如果你用 Node.js，grammY 框架同样可以在启动完成后执行自定义逻辑：
const { Bot } = require("grammy");
const bot = new Bot(process.env.BOT_TOKEN);
async function notifyAllUsers() {
const users = await getAllChatIds(); // 从数据库读取
for (const chatId of users) {
try {
await bot.api.sendMessage(chatId, "机器人已完成重启，服务恢复正常！");
} catch (err) {
console.error(`发送失败 ${chatId}:`, err.description);
}
await new Promise(r => setTimeout(r, 50)); // 限流保护
}
}
bot.catch(err => console.error("Bot 错误:", err));
bot.start().then(() => notifyAllUsers());三、去重与容错：避免重复通知和处理边界情况
实际运行中还有一个容易被忽略的坑：如果使用了进程守护工具（systemd、PM2、Docker 自动重启），Bot 可能在短时间内反复重启，用户会连续收到好几条一模一样的通知。解决办法是给每次启动生成唯一标识，记录“本次启动是否已通知”，或者在数据库里写入上次通知的时间戳，间隔小于某个阈值（比如 10 分钟）就不再发送。
另一个思路是只通知“最近活跃”的用户。比如只给 7 天内与 Bot 有过交互的用户发通知，长期沉默的用户不必打扰，既省了 API 调用配额，也减少了被投诉屏蔽的风险。这就要求在数据库的 first_seen 字段之外，再加一个 last_active 字段，每次用户发消息时更新。
还有一种进阶做法：不主动群发，而是等用户下次发消息时，通过中间件检测“这是重启后的第一条消息”，先回复一条恢复提示再处理正事。这种被动式通知对用户完全零打扰，适合重启频繁的服务。两种方案可以按场景组合使用。
最后提醒一点安全相关的实践：BOT_TOKEN 绝对不要硬编码在代码里，用环境变量或密钥管理服务注入，数据库连接信息同理。把这套持久化加通知的机制搭好之后，无论你的 Bot 是正常发版还是意外崩溃，用户都能第一时间感知到服务已恢复，整体使用体验会提升一大截。
Telegram Bot自动通知Bot开发修改时间：2026-09-07 11:37:03