本地网站开发：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e51cb965994c.html
📄
本地网站开发：旧系统字段无法完整迁入时怎样决定保留项
先给结论：决定保留哪些旧字段，不取决于字段在旧库里存在多久，而取决于它是否仍在支撑一个可验证的业务动作。如果某个字段被前台展示、后台筛选、对账或客服查询真实调用，就保留并补齐；如果只剩历史记录价值，就把它降级为只读归档，而不是硬塞进新结构。判断依据是调用证据，不是字段数量或迁移工具的默认勾选。
矛盾现象：字段迁不进去，往往不是技术容量问题
本地网站开发中常见的场景是：旧系统有四十多个字段，新结构只设计了二十个。迁移脚本跑完后，一部分字段因为类型不匹配、枚举值超出范围或缺少对应关系而落空。这时团队容易把问题理解成“新库装不下”，于是要么无限扩表，要么直接砍掉所有对不上的字段。两种反应都跳过了同一个问题：这些字段现在还有谁在用。
字段迁不进去通常有两种解释。第一种是结构设计确实遗漏了仍在使用的数据，比如旧字段“客户来源备注”被销售在后台筛选时依赖，新结构却只留了标准来源枚举。第二种是旧字段早已停止写入，只是历史数据还躺在表里，前台从未读取，报表也不再引用。两种解释对应的处理完全相反：前者要补结构，后者要归档。仅看“迁移失败数量”无法区分它们。
区分两种解释的证据：调用链而不是字段年龄
能区分上述解释的证据，是字段的调用链。可以按下面顺序查一遍，每一步都记录结果：
- 在前台模板和接口返回中搜索字段名，确认是否有页面或接口真正输出它。
- 在后台筛选、排序、导出和搜索条件中查同一字段，确认运营是否依赖它做日常操作。
- 在报表、对账脚本和定时任务中查引用，确认它是否进入过任何对外数字。
- 查最近一段时间的写入记录，确认它是否还有新数据产生，而不是只有历史值。
如果四步中至少一步命中，这个字段就属于“仍在使用”，应进入保留清单并明确新结构中的对应位置。如果四步全部落空，它更可能是历史残留，适合以只读方式归档。这里要注意一个反常现象：某些字段的查询量或写入量降到零，并不能单独证明可以删除。零调用也可能是因为旧入口已经下线、报表被临时停用，或数据被别的字段间接覆盖。要排除这些解释，需要确认入口和报表本身是否还在运行，而不是只看字段计数。
两个成立的选择：补结构还是降级归档
选择一：补结构并保留可写。成立条件是字段仍参与业务动作，且新系统里没有等价字段可以承接。代价是要同步修改表结构、表单、校验规则和导出逻辑，迁移期间还要处理旧值到新枚举的映射。实际动作是先在测试库加字段并跑一遍映射，观察前台展示和后台筛选是否正常；如果映射后出现大量空值或非法值，说明枚举对应关系还没定清楚，下一步应先补映射表，而不是直接上线。
选择二：降级为只读归档。成立条件是字段只有回溯价值，不再进入新写入流程，也不参与任何对外数字。代价是查询历史数据时需要走归档表或导出文件，不能再像以前一样在主表里直接筛选。实际动作是把归档字段连同原始主键和时间戳一起搬到独立表，并在新后台保留一个只读查询入口。做完这一步后，如果客服或财务仍频繁要求按该字段筛选，说明归档判断偏早，应把它重新提升为可写字段。
一个假设例子：用映射结果决定下一步
假设旧系统有一个“安装方式”字段，取值是自由文本，新结构只允许“上门、远程、自送”三个枚举。迁移时约三成记录无法自动对应。此时不要立刻把这三成记录丢弃。先抽样查看这些值，如果它们大多能归入现有枚举，只是写法不统一，就补一张映射表并重新跑迁移；如果它们指向的是已经停止的业务类型，就把这些记录标记为“历史值”并保留原文，新表单不再提供该选项。这个动作的结果会直接影响下一步：映射表能覆盖大部分记录时，保留可写字段是合理的；映射后仍有大量无法归类时，说明该字段的业务含义已经漂移，更适合归档而不是继续扩枚举。
保留项清单要写清适用条件，而不是只列字段名
最终决定应落成一份带条件的清单，每个保留项写明：保留原因、在新结构中的位置、是否可写、由谁负责维护、以及什么条件下可以再次评估降级。这样做的价值在于，后续有人质疑某个字段为什么还在时，能直接看到调用证据和适用条件。对于本地网站开发项目，字段取舍往往还会影响后续的模板调整和接口设计，因此清单最好在迁移前定稿，而不是等上线后再补。若某个字段的保留条件依赖一个尚未确认的报表或入口，先把它标为待定，等确认后再决定，不要用“先留着总没错”代替判断。
