Telegram 机器人回滚：为什么恢复旧代码不等于恢复旧数据
区分机器人代码版本、数据库结构和业务记录，用待办案例理解保留数据回滚的边界，并检查兼容性、云端冲突和回滚后的真实行为。
机器人新版本出现问题时，恢复旧代码可能让原来的命令重新工作。但用户在新版本期间创建的待办、偏好或报名记录怎么办？理解回滚前，先把代码、数据库结构和业务数据分开看。
本文使用一个虚构的任务机器人解释决策方法。示例说明可能发生的情况，不代表已运行测试，也不保证某个数据库变更一定能在产品中通过。
回滚涉及三个不同的对象
- 代码版本决定命令如何解析、按钮如何响应、记录如何读写。
- 数据库结构定义表、字段、类型及相关约束。
- 业务记录是用户已经保存的任务、状态或偏好。
因此，“上线旧代码”与“把数据库恢复到旧日期”是不同操作。前者可能继续读取今天的数据；后者可能覆盖最近新增或修改的记录。不能只凭一个版本编号推断三者都会一起恢复。
用一个待办案例判断兼容性
假设 v1 读取任务编号、用户编号、标题和完成状态。v2 增加优先级字段，并让用户在这段时间创建了新任务。
如果回到 v1 时，它需要的原字段仍存在，旧逻辑也能理解当前记录，那么额外的优先级字段未必阻碍旧代码工作。新任务可以继续存在，只是 v1 不一定展示优先级。这是需要检查的兼容情形，不是单凭“只增加字段”就能保证的结论。
如果 v2 删除或更名了标题字段、改变了编号类型，或者写入了 v1 不认识的状态，情况就不同：旧代码可能无法读取记录，或者把新状态错误解释成未完成。检查表和字段是基础，业务含义也需要人工验证。
BotFatherV2 的保留数据回滚边界
截至 2026 年 10 月 9 日，BotFatherV2 的安全回滚文档说明：回滚引用历史代码产物并创建部署记录，检查旧代码需要的表、字段和类型；缺失或不兼容时阻止操作。当前多出的表和字段保留，不运行反向迁移，也不恢复历史数据备份。
这意味着“保留当前数据”不能用来修复所有数据问题。比如，新版本已经把某个任务错误标为完成，恢复旧代码并不等于撤销那次修改。若需要找回历史记录，应单独确认备份、审计记录或数据修复方案是否存在；本文不声称平台已经提供这些能力。
回滚前记录四类信息
- 目标版本与问题：记下目前线上版本、准备恢复的版本，以及具体出错操作。避免只凭“昨天还能用”选版本。
- 当前数据样本：用允许查看的测试记录核对编号、数量、状态和关键内容。只记录必要信息。
- 结构与行为兼容性：查看平台检查结果，并确认旧代码能处理新版本期间产生的值和记录。
- 云端一致性：是否有人在官方 BotFather 或其他工具修改过源码？如有，先同步当前云端状态。
回滚被阻止时，先处理检查指出的不兼容，不要为了让旧代码运行而临时删除新字段或清空数据。修复当前版本、保留现有数据结构，可能比恢复更早的版本更合适。
发布结果不确定时，先确认实际状态
发布文档强调，连接中断不证明发布失败；重试会先对账云端代码。发布过程中已经增加的兼容表或字段，也可能在代码发布失败后保留。产品会检查云端 revision，遇到外部修改时停止发布。
对用户而言，重点是先查看部署详情，再确认云端到底运行哪个版本。不要把“浏览器没有收到成功提示”直接解释为“什么都没有改变”。这也解释了为什么旧代码兼容性应针对当前数据库检查，而非只看旧版本当时的状态。
回滚后验收读取、修改和数据隔离
用少量测试记录分别检查：
- 旧版本的命令和按钮是否恢复预期行为。
- 新版本期间创建的任务能否读取，关键内容和状态是否正确。
- 修改或完成一个测试任务是否只影响目标记录。
- 另一个用户是否仍无法访问不属于自己的数据。
- 重新打开聊天后，保存的结果是否仍可读取。
平台结构检查通过，不代表所有业务语义都正确。为这些操作保留结果，再决定是否让更多用户继续使用。
BotFatherV2支持版本发布与保留当前业务数据的代码回滚。它是独立产品，与 Telegram 官方 BotFather 无隶属关系。其回滚文档还说明，回滚不会删除最新开发草稿，也不会自动让草稿变成当前线上版本；后续修复前，应明确准备继续修改哪个版本。