邯郸做网站：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /631393cf78a4.html
📄
邯郸做网站：旧系统字段无法完整迁入时怎样决定保留项
先给结论：当旧系统字段无法完整迁入时，保留项不应按“字段新旧”决定，而应按“这个字段是否仍被前台展示、后台筛选或对外接口消费”决定。只要一个字段同时缺少展示位置、筛选入口和下游读取方，它通常可以退出迁移范围；反之，哪怕它很旧、很乱，只要有任一消费方，就必须先处理再决定是否保留。这个判断成立的前提是你能确认消费方清单，而不是只凭栏目编辑或开发人员的印象。
先确认字段的消费方，再谈保留
旧系统字段之所以难迁，往往不是字段本身复杂，而是没人说得清它现在还有没有用。比较稳妥的做法是先把字段分成三类：前台可见、后台可筛、对外可读。前台可见指页面上确实渲染出这个值；后台可筛指运营会用它做列表过滤、导出或统计；对外可读指接口、小程序、第三方系统会读取它。
三类都不沾的字段，可以先放入“不迁移”清单；只沾一类的字段，要结合迁移成本决定；沾两类以上的字段，默认进入“必须迁移”清单。这样做的结果会直接影响下一步：你能把讨论从“这个字段要不要”变成“这个字段由谁消费、迁移后谁验收”，减少来回拉扯。
一个反例：字段没人看，但它是历史对账依据
上面结论有一个容易失效的反例：字段在前台、后台筛选和公开接口里都没有消费方，但它被财务、客服或售后用作历史对账依据。比如旧系统里有一个“来源备注”字段，页面早就不展示了，后台也没有筛选入口，但客服在处理历史订单时仍会按它核对渠道归属。
这时不能因为“没人看页面”就删掉。更合理的处理是把它迁入一个不对外展示的归档字段，或至少保留可查询的只读副本。判断依据不是它现在是否出现在页面上，而是它是否仍承担追溯、对账或责任划分功能。只要存在这种用途，保留项就不能只按前台消费来判断。
用一组可区分的证据决定去留
为了避免拍脑袋，可以给每个争议字段收集三类证据：
- 展示证据：在模板、组件或页面配置中搜索字段名，确认是否有渲染位置。
- 操作证据：在后台列表、导出、报表或筛选条件中查找该字段，确认运营是否使用。
- 读取证据：在接口文档、调用日志或下游系统配置中查找字段名，确认是否有外部读取。
三类证据都没有，且业务方书面确认不再用于对账或追溯，才可以移出迁移范围。只有其中一类证据存在，就应进入保留评估，而不是直接删除。这样做的实际动作是：先产出字段消费清单，再据此生成迁移映射表；映射表确定后，开发和运营才能按同一份清单验收，后续返工也会减少。
假设例子：三个字段的不同处理
假设旧系统有三个字段：old_phone、old_source、old_remark。经核查，old_phone 仍在新版联系表单中展示，属于前台可见，必须迁移；old_source 不再展示，但运营每周按它导出渠道统计，属于后台可筛，应迁移并保留筛选入口；old_remark 既不展示也不筛选，但客服用于历史对账，应迁入只读归档字段，不进入新表单。
这个例子的数字只用于说明比较方法，不代表真实项目规模。它的作用是让你看到：保留项不是按字段数量决定，而是按消费方决定。迁移映射表一旦按这个逻辑写好，下一步就是让每个消费方确认自己的字段是否可用，而不是等上线后再发现缺字段。
下一步动作：先冻结映射表，再决定是否清理
完成消费方核查后，下一步不是立刻清理旧字段，而是冻结一份迁移映射表，写明每个字段的去向：进入新表、进入归档表、或明确不迁移。冻结后再让前台、运营、接口三方分别确认。确认通过后，才进入数据清洗和导入。
如果跳过冻结直接导入，常见结果是上线后才发现某个筛选条件失效，或者历史对账查不到依据，届时再补字段成本更高。先冻结映射表，再按消费方验收，能让保留项的决定有据可查，也能让不迁移的字段真正退出，而不是留在旧库里继续制造混淆。
