测试环境能跑，生产环境报字段不存在，是不是数据库迁移脚本没执行？

测试环境能跑、生产环境一上线就报字段不存在，很多人的第一反应是“谁漏执行了SQL”。反复出现这类问题，通常不是某个人记性差，而是结构变更没有被当成代码管理。2026年项目交付中还能稳定用的做法，是把迁移脚本提交进版本库，并在每个环境记录执行版本；这样绝大多数漏执行都能在发布前看出来。本文结合多个多环境项目的交付经验，说说漏执行到底漏在哪一步，以及怎么用流程挡住。

为什么“测试有、生产没有”总是最后才发现

表结构在测试和生产之间对不上，很少是某一次手误，更多是长期缺少“单一可信的变更记录源”。当一个库的变更分别散落在不同人的手工执行和临时改动里，最终的结构就变成每个人记忆的拼接。多环境协作时，常见的漂移原因有三类：多人各自改本地库，但没有把脚本合到一起；在测试环境临时加过字段，忘了同步到生产；以及执行了脚本，没人记录执行到了哪个版本。

这类不一致的症状并不总是整张表对不上，更多是“少一个字段”“约束不同”或“索引差异”。等到线上报错再回去查，要同时判断代码和库结构是否匹配，比单纯代码问题更耗时。

上线前先核对三件事，别急着补执行

一旦发现某个字段生产没有，不要立刻在服务器上敲 alter table。先回答三个问题：

1. 当前环境的数据库版本记录停在哪一次变更？如果没有版本记录，这个问题就答不上来。
2. 最新代码分支对应的数据库版本应该到哪一次？可以从分支里最近合并的结构变更文件判断。
3. 中间缺的脚本，有没有已经在目标环境手工执行过？手工执行过但没记录的，要标记为已执行，而不是再跑一遍。

如果没有任何版本记录，第一步要先建基线。把当前代码版本对应的历史变更脚本作为起点，对照目标库现有结构，把已经发生的改动标记成“已执行”，再把这个基线作为后续比对的基础。一个能用的判断标准是：测试库能否按脚本从空库重建，如果重建出来的结构和生产不一致，就说明脚本链路本身不完整，漏执行只是迟早的事。

版本化变更四步法：把结构变更当应用代码管理

要避免“人治”，比较稳的做法是让结构变更走和应用代码一样的提交、评审与发布逻辑。下面这套框架来自多年企业项目交付中的习惯：

1. 脚本入仓库。每次结构变更都对应一个SQL文件，命名带版本号、日期和用途，例如 V20260315__add_user_status.sql，与应用代码一起提交和评审。
2. 只追加不修改。已经提交的脚本不能原地改。若实现方式需要调整，就新写一个补偿变更脚本，保证所有环境执行的序列一致。
3. 记录执行状态。每个环境都维护一张版本记录表，记录成功执行的脚本名、校验值和执行时间。这样哪个环境落后、哪个领先，查表就知道。
4. 发布时按序执行。部署环节读取版本记录，自动执行未执行的脚本；如果没有自动化，发布单里要明确列出本次待执行脚本，禁止在服务器上随手零散执行。

前两步解决脚本本身可信，后两步解决多环境执行状态可见。只把脚本放进仓库、没有状态记录，多环境照样会出现重复执行和漏执行。

举个例子：某个企业后台系统生产库积累了很长时间的手工执行记录，没有任何版本表。我们先把历史SQL整理成带版本号的脚本，再对照生产库实际结构，把已经执行的项标记为baseline，最后接入现有发布流程。整理基线的经验区间，大约是完成一轮迭代工作量的十分之一到三分之一；如果历史手工变更特别多，投入还要再往上走。这是为“之前欠的账”付出的成本，但换来的是后续发版因为漏字段而紧急返工的情况明显减少。

用现成迁移工具还是自研执行器？从成本看选择边界

到了落地层，2026年常见的选择有两个方向：直接用开源迁移工具，或写一个简单的脚本执行器。

方案A：现成迁移工具。像 Flyway、Liquibase 这类工具自带版本表、脚本校验和命令行执行，规则清晰，适合中大型系统和多环境发布。代价是历史遗留的手工变更需要先清理成基线，团队还需要接受工具的约定。十几人的团队、每月几十次结构变更的项目，引入工具并接到持续集成是比较常见的做法，从开始接入到顺畅使用的经验区间大约是一到两个迭代。

方案B：自研执行器。脚本按版本号排序，启动时把未执行的SQL跑一遍，并把文件名写入自己的版本记录表。库表少、只有两三个环境的小项目，几十行脚本就能应付。代价是并发执行、失败恢复、脚本校验这些能力都要自己补；人一多、环境一杂，很容易出现“执行了一半没人知道”的例外。

不要只凭团队大小做选择。关键是看结构变更的频率和多环境数量。如果每个月都有多次变更，即使是小团队，也建议至少保留一个简单的版本记录表，不要停留在“谁记得谁执行”。成熟工具不是银弹，不接入发布流程，时间长了照样会漂移。

适用边界：这套机制管什么，不管什么

版本化迁移这套做法，适合有测试、预生产、生产等多个环境，多人协作，并且业务表结构每月都有若干次变更的项目。在这样的场景下，漏执行不是偶然事件，而是流程缺陷，版本记录能把这类问题提前暴露。

以下情况通常不必上这套机制：

• 一次性演示环境或临时数据库，数据可随时重建，手工执行或整体导入更省事。
• 个人项目或纯本地原型，只有一个人维护，脚本就在手边，不需要版本记录表。
• 表结构基本不动的内部系统，一年改不了几次，用简单清单就够。

如果项目只有一个发布环境，每次改动一两张表，只需要约定“SQL脚本先提交代码库再手动执行”，不一定要引入自动化工具。判断标准始终是：这种改动多久发生一次、多少人同时碰它、出错以后影响多大。

常见问题

迁移工具会把生产库改坏吗？

工具本身不会制造风险，风险来自没备份、没评审就直接执行。先备份，再做变更评审，执行前核对一次目标环境，比裸敲SQL更稳。

线上已经手动执行过某个SQL，自动迁移会不会重复跑？

会，除非在版本记录表里把它标成已执行。建基线时要逐个核实现有结构，手工执行过的动作不能照原样再放一遍，否则可能重复执行报错。

迁移脚本跑到一半失败了，怎么恢复？

先看版本表有没有写入本次标记，再定位失败语句。修好半截变更后继续跑，必要时从备份恢复，不建议不查状态就盲目重跑。

两人维护的小项目，也要用迁移工具吗？

不一定。只有单环境且改动少的，手工加核对清单也够用。若多环境还常加字段，两个人也建议保留版本记录表，否则容易你改过、他忘记。