龙岩网站开发：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0e6a7300c04b.html
📄
龙岩网站开发：旧系统字段无法完整迁入时怎样决定保留项
先给结论：如果旧字段的缺失会影响业务闭环或法定留存，就保留并补结构；如果只是展示冗余、口径重复或长期无人使用，就合并或丢弃。判断依据不是字段数量，而是这个字段一旦缺失，是否会让某条业务流程走不下去。
先判断字段属于哪一类：业务必需还是历史沉淀
把旧系统的字段逐个过一遍，分成三类。第一类是业务必需，比如订单号、客户标识、金额、状态、时间戳，缺少任何一个都会导致对账或流程断点。第二类是展示冗余，比如同一地址拆成省、市、区、详细地址四个字段，新系统可以合并成一个结构化地址。第三类是历史沉淀，比如多年前某个活动留下的标记字段，现在没有任何查询、导出或页面引用它。
区分的动作很具体：在旧系统里跑一次字段引用检查，看这个字段被哪些页面、接口、报表、导出任务读取。如果引用数为零，且近一段时间没有新增写入，基本可以归入第三类。但这里有个例外：引用数为零不等于可以删，因为可能存在线下导出、人工核对或外部对接方仍在按固定格式取数。所以引用检查之后，还要向业务方确认一次，而不是只依赖代码搜索结果。
两种条件下的不同选择：能补结构就迁，补不了就冻结
条件一：新系统的数据模型可以扩展。这时优先保留业务必需字段，并为旧字段单独建一张扩展表或附加字段区，不与主表核心字段混在一起。动作是先迁主表，再迁扩展表，最后做一次字段级比对。结果会影响下一步：如果比对发现扩展表里有主表没有的关联键，说明迁移映射还没定完，必须先补映射再继续，不能先上线再补。
条件二：新系统不允许改表结构，或者改结构成本高于收益。这时不要硬塞，而是把无法迁入的字段做冻结归档：导出成结构化文件，记录字段名、类型、来源表和导出时间，同时在新系统里留一个说明性的备注字段，指向归档位置。动作是导出后抽样校验，确认归档内容和旧系统一致。这个动作的结果是：后续如果业务方提出要查某个旧字段，可以直接从归档里找，而不需要重新打开旧系统。
两种选择的代价不同。扩展表方案前期开发量更大，但后续查询方便；冻结归档方案上线快，但每次查旧字段都要多一步人工操作。选择的关键是问一句：这个字段未来还会不会被频繁读取？会，就扩展；不会，就归档。
用“缺失后果”做取舍，而不是用字段多少
一个假设例子：旧系统有“客户来源”字段，取值是手工填写的自由文本。新系统要求来源必须是下拉选项。如果直接丢弃这个字段，后续做渠道分析时就没有历史数据；如果原样迁入，又会出现大量无法归类的文本。这时合理的做法是保留原始文本字段，同时新增一个标准化字段，先迁原始值，再按规则逐步映射。映射规则没有覆盖到的部分，标记为待处理，不强行归入某一类。
这个例子的判断依据是：字段缺失会不会让后续分析无法进行。会，就保留原始值；不会，就只保留标准化结果。动作是先迁原始值再映射，结果是映射覆盖率可以被观察，下一步可以据此决定是否需要人工补录，而不是一次性把不确定的值全部丢掉。
实施时的检查点和例外
迁移前先做字段清单，标注每个字段的类型、是否必填、是否被引用、是否有外部对接方使用。迁移中做字段级比对，至少覆盖记录数和关键字段的非空率。迁移后保留旧系统只读一段时间，不要立刻下线。
- 例外一：字段涉及个人信息或敏感数据。这时不能只考虑业务是否需要，还要看留存是否有依据。没有明确依据的，应优先考虑脱敏或删除，而不是原样迁入。
- 例外二：字段是旧系统的主键或外键。这类字段即使业务上不再使用，也可能影响数据关联，不能简单丢弃，需要先确认关联关系是否已经在迁移中重建。
- 例外三：字段被外部系统按固定格式读取。迁移前要通知对接方，确认新格式和切换时间，否则会出现对方取不到数的情况。
如果迁移后发现某个字段的查询量很低，这不能单独证明当初保留它是错的，因为低查询量也可能来自入口太深、没人知道它存在，或者查询方式发生了变化。要结合业务反馈和实际使用场景判断，而不是只看一个数字。
把决定写下来，减少反复
每个字段的最终处理方式应该有记录：保留、合并、归档还是删除，以及做出这个决定的理由。这份记录不需要复杂，但要在迁移完成后交给后续维护的人。否则过一段时间，同样的问题会被重新讨论一遍，而当初的判断依据已经找不到了。决定保留项的标准，始终是业务是否还需要它，而不是旧系统里有多少字段。
