茂名网站开发：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /285f7e2ac6fc.html
📄
茂名网站开发：旧系统字段无法完整迁入时怎样决定保留项
结论先行：当旧系统字段无法完整迁入时，决定保留项的依据不是字段在旧库里是否存在，而是它是否仍在支撑一个可验证的业务动作。如果某个字段只被历史报表或已停用的流程引用，就应优先舍弃；如果它仍参与订单流转、客户识别或对账，就必须保留并映射到新结构。一个会让上述结论失效的反例是：字段看似无人使用，但它是某个外部合作方接口的必填参数，一旦缺失，对方系统会直接拒绝请求。此时无论内部判断多合理，保留都是硬约束。
先判断字段的“活引用”，而不是看数量
旧系统迁不动，常见原因是字段数量庞大，但真正需要保留的往往只是一小部分。判断一个字段是否属于保留项，可以按下面三类证据逐一排查：
- 入口证据：前台表单、后台录入页、导入模板里是否还有这个字段的输入位置。如果入口早已删除，它大概率只是历史残留。
- 出口证据：是否有页面、报表、接口或导出文件会读取它。只要有一个下游仍在消费，就不能直接丢弃。
- 规则证据：是否有校验、计算或状态流转依赖它。例如某字段参与金额计算或权限判断，缺失会导致逻辑错误。
三类证据都为空，才适合列入舍弃清单。只有入口没有出口，通常是旧录入习惯遗留；只有出口没有入口，则要确认数据是否还能从其他字段推导出来。
把候选字段分成保留、映射、舍弃三档
不要用“保留/删除”二分法，中间应有一档“映射”。具体做法是：先列出所有无法直接迁入的字段，再为每个字段标注去向。
- 保留：新库需要新增对应字段，或旧字段本身就是新结构的必要组成。
- 映射：旧字段的值可以转换后写入新字段，例如把多个旧状态值合并为新的枚举值。
- 舍弃：无入口、无出口、无规则依赖，且不影响任何已确认的业务动作。
映射档最容易被忽略。它要求写清楚转换规则，例如旧字段的哪些取值对应新字段的哪个值，无法对应时是留空还是走默认值。规则不写清，迁移后会出现“数据在但不可用”的情况。
一个假设例子：客户备注字段的去留
假设旧系统有一个“客户备注”长文本字段，新系统的备注被拆成“内部备注”和“对外备注”两个字段。此时不能简单二选一。先查出口：如果客服页面会展示旧备注，且内容同时包含内部判断和对外说明，就应保留并做人工或规则拆分；如果旧备注只在导出报表里出现，而报表已确定停用，则可以考虑舍弃或只归档不迁入。这个例子的关键是：字段的去留取决于它服务哪个动作，而不是文本长短。假设拆分规则无法覆盖全部历史内容，就应把无法判断的部分单独标记，而不是强行塞进某一侧。
反例：外部接口依赖会让“舍弃”判断失效
上面所有判断都可能被一个条件推翻：该字段是外部合作方接口的必填项。内部系统可以停用某个页面，但合作方的请求不会因此消失。判断方法是查接口文档和调用日志，确认字段是否出现在对方要求的参数列表中。如果存在这种依赖，保留项就不再由内部使用情况决定，而要先满足外部约束。此时应把字段标记为“强制保留”，并在新系统中保证它可被读写，再谈其他优化。
下一步动作：先冻结字段清单，再决定迁移顺序
完成分档后，先冻结一份字段清单，写明每个字段的去向、依据和负责人。冻结的意义是防止迁移过程中反复增减，导致结构不断返工。随后按依赖关系决定顺序：被其他字段或接口依赖的字段先迁，独立字段后迁。每完成一批，就核对一次入口、出口和规则是否仍然成立。如果发现某个已舍弃字段重新出现调用，说明前面的证据排查有遗漏，应暂停该批迁移并重新评估，而不是直接跳过。
