版本管理不是记录"现在是什么"，是记录"从哪里来、到哪里去"

第一次给客户端设计更新服务的时候，我的数据库里只有一张表，字段极其简单：app_name、version_code、download_url、release_date。当时觉得够用了，一个版本一行，客户查最新版本就返回最新那一行。直到有一天需要回滚——线上版本出了紧急问题，需要让所有用户退回到上一个稳定版本。我打开数据库看了半天，发现自己根本不知道"上一个稳定版本"是哪个。回滚变成了人工翻聊天记录去找历史版本号，那一刻我意识到，版本管理的数据库设计，不是在记录"当前状态"，是在记录"版本之间的故事"。

第一条认知：版本表的核心是"关系"，不是"列表"。

大多数人的第一反应是把版本设计成"列表结构"——一行一个版本，按时间排序。这种设计只能回答"有哪些版本"，回答不了"这个版本跟上一个版本是什么关系""这个版本是从哪个分支来的""哪些版本之间有依赖关系"。

真正好用的版本表，至少应该包含两个关系字段：parent_version_id（当前版本基于哪个历史版本发布）和version_type（主版本/次版本/补丁/热修复/回滚版本）。有了这两个字段，版本之间的血缘关系就能完整追溯。你不仅能知道"现在是什么版本"，还能知道"如果这个版本出问题，应该回到哪个版本"，以及"这个版本是从哪条开发线路上长出来的"。

这就像家谱记录，不是只记每个人的名字和生日，还要记"这个人是谁的儿子、谁的父亲、谁的兄弟"。版本管理也是一样，版本号只是名字，版本之间的关系才是灵魂。

第二条认知：更新策略跟版本状态必须强绑定。

不同状态下的版本在更新策略里扮演的角色完全不同。正在灰度测试的版本只有少量用户能收到，全量发布的版本所有用户都能收到，被标记为"不推荐"的版本只允许已安装的用户继续使用、但新安装不允许选到这个版本，被标记为"紧急回滚"的版本需要强制所有用户在一小时内升级走。

数据库设计里如果只存一个版本号和发布日期，这些策略完全没法支撑。必须给每个版本加上状态字段和状态生效时间。灰度的开始时间、全量的开始时间、回滚的触发时间——这些时间点记录了版本在整个生命周期里的每一个关键节点。

第三个认知：灰度策略需要单独的"发布规则表"来管理。

版本状态是全局的，但更新策略往往需要更细致的控制。同一个版本，可能先放百分之五的用户升级，观察两天没问题再扩大到百分之三十，再观察两天全量。这个过程如果用版本表的状态字段来管理，就太粗糙了——你无法在同一个版本上同时记录"当前灰度的比例是多少""哪些用户已经拿到了灰度资格""灰度的下一阶段计划什么时候启动"。

我后来的设计里单独加了一张发布规则表，跟版本表分开。版本表只记录"这个版本是什么、基于谁发布的、当前处于什么状态"，发布规则表记录"针对这个版本，具体的发布策略是什么——按用户ID尾号放量、按地域放量、按设备型号放量"。两表独立的好处是，版本回滚或者切换的时候不需要动发布规则，直接改版本表的状态字段就能触发对应的规则执行。

第四条认知：客户端当前状态和服务端最新状态之间需要一个"差值计算层"。

数据库里存了一堆版本信息和发布规则，但最终要回答的问题是：给定一个客户端，它当前的版本是X，服务端应该告诉它升级到哪个版本？ 这个问题看似简单，但加上灰度规则、依赖关系、强制升级策略之后，逻辑变得相当复杂。

我不建议把所有的判断逻辑都在API接口里用SQL硬编码。更清晰的架构是：API从数据库里拉取全量的版本信息和发布规则，在应用层用代码做"匹配计算"。数据库层的设计目标是"让这个计算过程能够高效地获取所需数据"，而不是"让SQL直接算出来答案"。数据库存的是事实，应用层根据事实做决策，分工明确，逻辑清晰。

第五条认知：回滚方案的数据库设计是救命用的。

回滚这件事，在数据库设计里必须当作"一等公民"来考虑。每一个版本发布的时候，数据库里必须预先存好"如果这个版本挂了，回滚的路径是什么"。这个回滚路径不是人为事后补的，是发布流程里必须录入的数据。

我踩过的坑是：版本表里存了parent_version_id，但parent_version_id指向的是"基于哪个代码分支"，而不是"哪个版本是稳定的、可以直接回的"。后来给版本表加了一个rollback_target_id字段，明确指向"如果当前版本需要回滚，应该回退到哪个版本"。这个字段跟parent_version_id可以相同，也可以不同——取决于当前的版本质量评估。

第六条认知：日志不是审计，是"交通记录"。

版本更新的数据库里还需要一张更新请求日志表。每次客户端来检查更新，都记录一行：时间、客户端ID、当前版本、服务端返回的建议版本、实际执行的更新动作。这张日志表看起来是"审计用的"，但实际上它最大的价值是"异常排查"和"策略验证"。

某天突然有大量用户被建议升级到一个不该升级的版本，查版本表可能看不出问题，但查日志表就能定位是哪条发布规则在什么时候被触发了。灰度放量的效果怎么样，看日志表里不同版本的实际升级率就能验证。这张表的体量会很大，但它的存在让"瞎了"变成"看得见"。

最后做个总结：版本管理的数据库设计，不是一张表能解决的事，它至少需要版本主表、发布规则表、更新日志表三张表配合，再加上清晰的"版本关系"设计来保证回滚和依赖追溯的能力。 真正重要的不是"现在是什么版本"，而是"这个版本从哪里来、谁发布的、处于什么策略状态、如果出问题了应该回到哪里、历史上发生过哪些更新事件"。把这些问题在数据库层面回答清楚，更新服务才能从"发出去就收不回来"的恐慌，变成"发出去也能稳稳地控制住"的从容。