Telegram Bot 能做什么？从一个签到机器人讲起
之前写过一篇聊 Telegram 官网版和商店版区别的文章,这次聊点相关但不完全一样的话题——Telegram 上的机器人(Bot)到底是怎么一回事,普通人自己动手搭一个大概需要经过哪些步骤。
Bot 本质上是一个”特殊账号”
Telegram 里的 Bot 账号在结构上和普通用户账号很像,同样有用户名、同样可以被搜索、拉群、发消息,唯一的区别是它背后不是一个真人在操作,而是一段跑在服务器上的程序,根据收到的消息自动做出响应。
从使用者角度,和 Bot 聊天的体验跟和真人聊天差不多——发一条消息,过一小会儿收到回复,只是这个”回复”是代码逻辑算出来的,而不是人手动打的字。
创建 Bot:从 BotFather 开始
Telegram 上创建 Bot 的入口本身也是一个 Bot,官方维护的账号叫 @BotFather。跟它对话、发送 /newbot 指令,按提示依次填写 Bot 的显示名称和用户名(用户名必须以 bot 结尾,比如 my_checkin_bot),创建成功之后,BotFather 会返回一长串字符,这就是这个 Bot 的 Token。
谁拿到这串 Token,谁就能以这个 Bot 的身份收发消息、修改设置。如果不小心把 Token 提交进了公开的代码仓库,或者贴在了聊天记录里被别人看到,应该第一时间找 BotFather 用 /revoke 指令重新生成一个,让旧的 Token 失效。
Bot 怎么”知道”用户发了消息:轮询 vs Webhook
Token 到手之后,Bot 本身还只是一个空壳,需要写代码去接收消息、处理逻辑、发送回复。这里有两种常见的接入方式:
长轮询(Long Polling):程序主动、反复地向 Telegram 服务器发起请求,问”有没有新消息”,服务器如果暂时没有新消息,会把这次请求先”挂着”一段时间,直到有新消息才返回,而不是让程序发一次问一次、每次都是空转。这种方式好处是不需要一个公网可访问的服务器地址,本地跑一个脚本、只要能访问外网就行,适合个人练手或者小规模使用。
Webhook:反过来,由 Telegram 服务器主动把新消息推送到你指定的一个 HTTPS 地址,你的服务器被动接收就行,不需要一直发请求去”问”。这种方式效率更高(没有轮询造成的空转请求),但要求你有一个带有效 HTTPS 证书、公网可访问的服务器地址,门槛比长轮询稍高一些。
个人练手项目通常从长轮询起步,等真的需要更高并发或者更低延迟的场景,再考虑切换成 Webhook。
一个签到机器人大概需要哪几块东西
假设想做一个最简单的”群签到”机器人——用户发 /checkin,机器人记录一下这个人今天签到了,月底能查一下自己签到了多少天。拆开来看大概需要这几块:
- 接收并解析指令:识别出用户发的是
/checkin这类指令,而不是普通聊天内容(Telegram Bot API 里,以/开头的消息会被特殊标记为”命令”) - 记录数据:需要一个地方存”谁、在哪个群、哪一天签到过”,通常是接一个轻量数据库,或者简单点直接用文件存
- 防重复签到:同一个用户同一天不能重复签到多次,查数据库判断一下今天是否已经有记录
- 反馈结果:调用 Bot API 的发消息接口,把”签到成功,连续签到 X 天”之类的结果发回去
- (可选)定时任务:比如每天凌晨清空当天的签到状态、每月初生成一份签到排行,这部分靠服务器上的定时任务触发,和 Bot API 本身没有直接关系,是独立的一层
Telegram 官方提供的 Bot API 文档把能调用的接口都列得很全,发消息、发图片、发文件、创建内联键盘(消息下面那种可以点击的按钮)、编辑已发送的消息,基本能想到的交互方式都有对应接口,不需要自己额外造轮子。
群组里的 Bot 需要额外注意权限
如果 Bot 是被拉进群里用的(而不是私聊场景),默认情况下 Bot 只能看到”命令消息”和”@ 它的消息”,看不到群里的普通聊天内容——这是隐私保护设计,除非群主专门去 BotFather 的设置里把 Bot 的”隐私模式”(Privacy Mode)关掉,才能让 Bot 读取群里的所有消息。做签到这类只需要响应命令的场景,默认的隐私模式已经完全够用,不需要特意关闭。
小结
Telegram Bot 上手门槛其实不算高:申请 Token、选一种消息接入方式、按需调用发消息接口,一个最基础的签到机器人往往几十行代码就能跑起来。真正决定一个 Bot 好不好用的,反而是后面这些细节——命令响应要不要防抖、数据要不要做持久化、异常输入要怎么兜底,这些工程层面的打磨比”能不能跑起来”本身要花更多功夫。如果之后有机会把自己写的某个 Bot 整理成一篇完整的实操教程,应该会放在文档站里,这边就先按下不表了。