后台接口先看鉴权方式,Cookie 登录的接口不适合直接给机器人用
多数已有后台的接口是为浏览器设计的:靠 Session Cookie、图形验证码或前端签名保持登录。机器人是服务端进程,没有浏览器,强行模拟登录会很脆弱,验证码或会话策略一变就失效。对接前要确认三件事:是否有可签发的服务级凭证(API Key、OAuth 客户端凭证或内部签名);凭证能否按接口或资源限定范围;凭证泄露后能否单独吊销而不影响管理员登录。三项里有两项答不上来,说明后台还没有可对接的机器接口层。
Telegram 会重发更新,有副作用的接口必须能防重复
Webhook 返回非 2xx 或超时,Telegram 会重新投递同一条更新。用户连点按钮,也会产生多次回调。如果后台的「创建订单」「调整余额」「审批通过」这类接口没有幂等机制,重复执行就会变成真实的数据错误。常规做法是把 update_id 或 callback_query 的 id 作为幂等键传给后台,后台或机器人侧用它去重。同时确认接口的响应时间:耗时操作应先返回 200,再异步处理并用消息通知结果,而不是让 Webhook 请求一直挂着。
Telegram 用户 ID 不是后台账号,需要一次明确的绑定
Telegram 的数字 user id 稳定,username 可以随时修改或清空,所以不能用 username 识别身份。需要设计一个绑定流程,例如在后台生成一次性绑定码,用户在私聊里发给机器人,机器人把 user id 与后台账号关联并让绑定码立即失效。群聊里要判断的是发送者的 user id,而不是群 id,否则群里任何人都等于同一个身份。还要定义解绑与离职回收:后台账号被停用时,绑定关系和已有会话要同步失效。
角色按操作风险分层,按钮参数不要承载权限
先列出后台操作清单,再按风险分成只读查询、日常操作、敏感操作(资金、删除、权限变更)三层,每层对应机器人里的不同角色。敏感操作建议要求二次确认,必要时只允许在私聊中执行,或者干脆不开放给机器人。注意 callback_data 有 64 字节上限,更重要的是它由客户端回传,不应把金额、对象 id 等参数直接编码进去当作可信数据。更稳妥的做法是在服务端保存待确认操作的状态,按钮里只放一个短令牌,点击时再校验操作者角色与令牌归属。
Webhook 还是长轮询,取决于机器人服务放在哪里
Webhook 要求机器人服务有可从公网访问的 HTTPS 地址和有效证书,端口以官方文档支持的范围为准(常见为 443、80、88、8443)。建议配置 secret_token,并在服务端校验请求头,避免任何人伪造更新。Webhook 与 getUpdates 不能同时使用,切换时要注意清理。若后台只在内网、不便暴露入口,可以让机器人服务用长轮询,只需要出站访问 Telegram,再通过内网调用后台。更常见的结构是把机器人服务单独部署,后台不直接对公网开放,机器人服务只持有受限范围的凭证。限流和文件大小上限也以 Bot API 当时的文档为准,批量通知要自己做排队。
出现这几种情况,先改后台再做机器人
可以用下面几条做停止判断:后台没有按操作者记录的审计日志,事后无法区分是网页操作还是机器人操作;敏感接口没有幂等或没有权限校验,只靠前端隐藏按钮;接口返回格式没有稳定的错误码,机器人无法区分可重试与不可重试;凭证无法限定范围。遇到其中任何一条,直接开发机器人只会把问题放大成群聊里的高频入口。先补一层带鉴权、幂等和审计的服务接口,再让机器人调用它,返工成本通常更低。涉及的 Bot API 细节以 Telegram 官方文档当时的版本为准。