为什么"改数据"必须做成功能
上线后一定会遇到脏数据：历史导入的地址缺省份、早期订单金额与明细对不上、某次活动配置漏了字段。这类问题的共同点是不能靠改代码解决，只能改数据。
如果开发直接连库执行 UPDATE，会带来三个后果：
- 没人知道改了多少行、改前是什么值；
- 没有预演，第一条 SQL 写错就可能污染全表；
- 下次遇到同类问题，又得重新写一次 SQL。
所以这套系统把"修数据"做成后台模块，包含三个能力：体检（发现问题）→ 修复任务（预演与执行）→ 日志（留痕与复核）。
数据体检：先看清楚再动手
体检的思路很简单：对每张业务表定义若干"健康规则"，逐条扫描并给出统计。
- 第一步看表清单：哪些表存在疑似脏数据，各自多少行；
- 第二步看列明细：具体是哪一列、哪一类问题（空值、越界、引用不存在、金额不平）；
- 第三步可以一键生成修复任务，把体检发现的问题直接转成待处理任务，不用手工抄。
扫描结果对"不可自动修"的情况会给出待修复记录行明细——不能修也必须让人看到是哪几行，否则运营只能得到一句"有 12 条有问题"，无从下手。
体检规则本身是只读的，不修改任何业务表；它只负责回答"哪里不对、有多少、具体是哪些行"。
修复任务：四步走
一个修复任务的生命周期固定为四步：
- 试运行：只在事务里执行并统计影响行数，最后回滚，不真正落库；
- 备份：执行前把受影响表的当前数据导出为快照，落盘保存；
- 执行：正式执行，按步骤记录每条 SQL 与影响行数；
- 复核：执行后再次运行同一套体检规则，确认问题行数下降且有据可查。
任务日志记录到独立表，包含分步 SQL、影响行数、耗时、执行人。这条日志不可编辑，出问题时是唯一的对账依据。
两道安全闸
第一道：禁改表白名单。 权限表、菜单表、迁移台账这类表被列入禁止修改，界面上按钮可见但点击被拦截，并提示原因。为什么不直接隐藏？因为隐藏会让运维以为是"页面缺功能"，明确拦截反而更清楚。
第二道：任务不可二次执行。 一个任务执行过就标记为已完成，需要再跑必须新建任务。这样避免了"同一个脚本被重复点两次导致重复扣减"的问题。
一个真实的价值场景
某次体检发现"部分订单明细金额之和与订单总金额相差 0.01~0.3 元"，来源是多供应商拆单时的运费尾差分摊。修复方案不是写一条 UPDATE 抹平，而是：先定位受影响的订单范围 → 试运行确认行数 → 备份 → 按"尾差归末行"规则重算 → 复核对齐。
整个过程在后台可查、可回放。这类问题的处理方式，直接决定了这套系统能不能交付给客户自己运维。
给同行的建议
数据修复功能看似"内部工具"，实则是交付质量的分水岭：
- 没有它，每次脏数据都要开发介入，客户离不开你；
- 有它但没预演，迟早出一次全表事故；
- 有它且有预演与日志，客户的技术人员可以自己处理 80% 的数据问题。
投入大概是两天的开发量，换来的是长期的可交付性。