网站制作流程：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /37fb5715b6f0.html
📄
网站制作流程：旧系统字段无法完整迁入时怎样决定保留项
没有一份字段清单能直接告诉你哪些该留。可行的做法是先按“业务是否仍需要它”和“新系统是否已有等价承载”两个维度把字段分成四类，再对每一类给出不同的处理动作。只有当旧字段仍然驱动着对外承诺或对内结算时，保留才是默认选项；如果它只是历史遗留的备注，删掉通常不会引发连锁问题。
先确认分歧是事实分歧还是口径分歧
多个角色对同一字段有不同理解，往往不是谁记错了，而是各自看到的是不同侧面。运营记得这个字段用来筛选客户，技术记得它从未被任何查询调用，财务记得它出现在月度导出里。这三种说法可以同时为真。
把分歧转成可核对的项目，需要为每个字段收集三类证据：
- 谁在什么动作里读取它，例如导出、筛选、对接第三方；
- 它是否参与对外展示或对账，例如合同附件、账单明细；
- 它是否被其他字段或流程间接依赖，例如作为关联键或状态判断条件。
证据收集完成后，分歧通常会自动收敛：要么有人能指出具体动作，要么所有人都找不到实际读取路径。后者不等于可以立即删除，只说明它暂时没有活跃用途。
用两个条件把字段分成四类
把“业务仍需要”作为横轴，“新系统有等价承载”作为纵轴，可以得到四种处理方式：
- 需要且已有等价字段：做映射对照，把旧值写入新字段，保留映射记录备查，旧字段本身不迁。
- 需要但没有等价字段：这是必须保留的部分，需要在新系统里新增承载位置，并明确由谁维护。
- 不需要但已有等价字段：可以直接丢弃，但要确认等价字段的语义完全一致，而不是名字相似。
- 不需要且没有等价字段：默认不迁，但把旧值导出成离线归档，注明归档时间和责任人。
这个分类的价值在于，它把“要不要留”这个容易争论的问题，换成了“有没有读取动作”和“新系统能不能装下”两个可以查证的问题。
一个会让上述结论失效的反例
假设某字段在旧系统里从未被任何页面或报表读取，按上面的分类应归入“不需要”。但如果它被用作两张表的关联键，删除后会导致历史记录无法对应，那么“没有读取动作”这个判断就是错的——读取发生在关联逻辑里，而不是在界面上。
反例的教训是：判断字段是否被需要时，不能只看界面和报表，还要看数据结构层面的引用关系。如果无法确认引用关系，保守做法是先保留该字段的原始值，即使它不再出现在任何新界面上。
把决定落成可执行的动作
完成分类后，下一步不是直接开始迁移，而是先产出一份字段处置表，每行包含旧字段名、分类结果、处理动作、责任人和验证方式。验证方式要具体到可操作的程度，例如“导出最近一个月的对账文件，比对总额是否一致”，而不是“检查是否正常”。
执行时按“先保留、后清理”的顺序推进：先把必须保留的字段迁入并验证通过，再处理可以丢弃的字段。这样即使中途发现问题，也不会因为删除了某个字段而失去回退依据。验证通过后，再决定是否清理旧系统中的冗余字段；清理动作本身应记录时间和执行人，以便日后追溯。
