建站基础知识：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /669009d1af92.html
📄
建站基础知识：旧系统字段无法完整迁入时怎样决定保留项
先给有条件的结论：当旧字段无法完整迁入时，优先保留“下游有明确读取方、且缺失后无法用其他字段推导”的字段；反之，只用于人工回看、可由正文或时间戳重建的字段，可以进入暂缓迁入清单。这个判断成立的前提是你能列出每个字段的读取方和缺失后果；如果做不到，先别决定去留，因为此时任何取舍都只是角色之间的印象之争。
把“字段重要”改写成可核对的三列
多个角色对同一字段的理解不同，通常是因为各自只看见自己那一段：编辑记得它填起来麻烦，开发记得它查询频繁，运营记得报表里有这一列。把分歧转成项目可核对的事实，可以强制每个字段填三列：读取方（谁在什么动作里读它）、缺失后果（页面出错、筛选失效、还是只是少一条参考信息）、替代来源（能否从标题、正文、创建时间或另一字段推导）。三列填不齐的字段，不进入保留或丢弃的投票，先进入待查清单。
这样做的实际动作是：让每个角色只对自己能举证的那一列负责，而不是对“重不重要”表态。结果会直接影响下一步——如果某字段的读取方只有一个人工回看场景，它就不该和“列表页筛选依赖它”的字段争同一个迁入名额。
两种取舍各自成立的条件
保留项决策通常落在两种方案之间，它们不是谁更先进，而是适用条件不同。
- 方案A：按读取方保留。成立条件是读取关系可枚举，且下游系统或模板能指出具体位置。适合字段数量多、但读取路径相对固定的旧站。代价是排查工作量大，需要逐个确认。
- 方案B：按缺失后果保留。成立条件是能快速判断字段消失后是“报错”还是“降级展示”。适合字段数量少、但读取方分散的情况。代价是容易把“暂时没人用”误判为“永远不需要”。
如果两种条件都具备，先用方案A筛出硬依赖，再用方案B处理剩余字段；如果两种都不具备，说明迁移范围还没界定清楚，此时决定保留项只会把问题推迟到上线后暴露。
一个会让上述结论失效的反例
假设旧系统里有一个“内部备注”字段，读取方只有编辑自己，缺失后果看起来只是少一条参考信息，按上面的结论应进入暂缓迁入。但如果这个字段实际上被客服用来核对历史处理记录，而客服并不在最初列出的读取方名单里，那么“读取方可枚举”这个前提就不成立，结论随之失效。
这个反例说明：字段去留的分歧，很多时候不是判断标准错了，而是读取方名单漏了。反例出现后，正确动作不是重新投票，而是回到三列清单，补上遗漏的读取方，再重新判断。假设某站有120个旧字段，第一轮只找到80个有明确读取方，剩下40个里有12个在补查后被确认有隐藏读取方——这个数字只用于说明补查会改变结论，不代表任何真实项目的比例。
把决定写成可复核的记录
决定保留项之后，需要留下能复核的记录，否则下一轮迁移又会重新争论。记录至少包含：字段名、保留或暂缓、判断依据属于哪一列、以及复核触发条件。复核触发条件可以写成“当某个下游功能开始读取该字段时重新评估”，而不是“以后再说”。
这样做的结果是：暂缓不等于删除，保留也不等于永久。下一步动作是把暂缓清单交给能接触下游系统的人复核一遍，确认没有隐藏读取方，再进入实际迁移。若复核中发现新的读取方，就回到三列清单更新，而不是直接推翻整个保留方案。
什么时候应该停止逐字段判断
如果字段数量已经大到逐字段核对无法在合理时间内完成，继续细化判断的收益会下降。此时可以改为按字段组处理：把读取方相同、缺失后果相同的字段归为一组，整组保留或整组暂缓。适用条件是组内字段确实共享同一读取路径；如果组内混入了独立依赖，整组判断就会掩盖个别字段的真实后果，需要拆开。
停止逐字段判断不等于放弃核对，而是把核对粒度从字段提升到组。动作上，先按读取方聚类，再对每组抽一两个字段验证判断是否成立；验证结果若与预期不符，就退回该组逐字段处理。这一步的结果决定后续迁移是按组批量执行，还是继续小步核对。
