网站开发时长，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9d13c534c49e.html
📄
网站开发时长，旧系统字段无法完整迁入时怎样决定保留项
结论先行：当旧系统字段无法完整迁入时，决定保留项的依据不是字段多少，而是该字段是否仍被当前业务动作读取、是否承担对外承诺、以及迁移后能否在合理工期内被新结构承接。三者都成立的字段优先保留；只满足其中一项的，通常应转为归档或人工留档，而不是硬塞进新库。这个判断有一个明确的反例：如果某字段虽然当前无人读取，却是合同、对账或审计中唯一可追溯的凭证，那么它必须保留，哪怕会增加开发时长。
先分清三类字段，再谈保留还是丢弃
把待迁移字段分成三类，比逐个争论更省时间。
- 活跃字段：当前表单、接口或后台列表仍在读写的字段。这类字段若不迁，新系统上线当天就会缺功能。
- 凭证字段：不再参与日常流程，但对外产生过承诺，例如订单备注、审批意见、历史价格构成。它们决定日后能否解释清楚一笔记录。
- 沉积字段：早期试验、已废弃的渠道标记、重复录入的冗余列。它们通常只增加迁移和校验成本。
分类完成后，保留项自然浮现：活跃字段全迁，凭证字段以只读或归档形式保留，沉积字段默认不迁。真正需要讨论的，是那些横跨两类的字段。
用三个问题筛出必须保留的字段
对每个边界字段依次问：
- 新系统里有没有任何页面、接口或报表会读取它？如果没有任何读取方，迁入后它只是占用空间。
- 如果丢失，会不会导致某笔历史记录无法解释、无法对账或无法回应外部询问？会，则属于凭证字段。
- 保留它的代价是改表结构、补数据清洗脚本，还是仅仅多一列？代价越高，越需要前两个问题同时成立才做。
三个问题的答案会直接改变下一步。假设某旧系统的“来源渠道”字段在新系统中已无对应报表，但客服偶尔需要据此判断历史订单的归属，那么合理做法是把它迁成一个只读备注列，而不是重建完整的渠道字典表。这个动作的结果是：迁移脚本不需要处理渠道枚举映射，开发时长缩短，但客服查询路径要提前告知，避免上线后找不到入口。
一个会让结论失效的反例
上面的筛选默认“当前无读取方”等于“可以放弃”。这个默认在一种情况下不成立：字段是某类外部义务的唯一载体。例如旧系统里有一列手工填写的“特殊约定”，它不参与任何自动化流程，也没有报表引用，但它是当时与客户确认交付范围的唯一文字记录。此时若按活跃度判断而丢弃，后续出现争议时无法还原约定内容。反例的教训是：读取频率低不等于价值低，凭证类字段的判断标准是“能否被替代”，而不是“是否常被使用”。
决定保留项后，迁移顺序怎么排
保留项确定后，不要按旧表顺序迁移，而按依赖关系排：
- 先迁活跃字段，保证新系统能跑通主流程。
- 再迁凭证字段，以只读或独立归档表的形式接入，避免污染新结构。
- 最后处理沉积字段，只做一次性导出留档，不进入新库。
这样排的原因是：活跃字段的缺失会阻塞测试，凭证字段的缺失只在特定查询时暴露，两者的紧急程度不同。把凭证字段做成独立归档表，还能让后续的字段清理不再牵动主表结构，减少反复改表带来的工期波动。
把判断写进迁移清单，避免上线后返工
落地时，为每个保留字段记录四项：字段名、保留理由（活跃或凭证）、在新系统中的存放位置、以及谁负责验证。验证动作要具体到可执行，例如“用三条历史记录核对归档表能否按原编号查到”。如果验证失败，处理方式不是立刻改主表，而是先确认是映射遗漏还是归档逻辑错误，再决定是否调整。这个顺序能防止一个字段的问题拖慢整体上线，也能让开发时长的估算更接近实际。
