通化网站开发，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b4eb37ead15f.html
📄
通化网站开发，旧系统字段无法完整迁入时怎样决定保留项
决定保留项的依据不是字段在旧系统里是否存在，而是它是否仍参与当前业务判断、能否在新结构中独立表达、以及缺失后是否会造成不可逆的信息损失。三者缺一，才考虑放弃或合并；只凭迁移工具映射失败就删字段，往往会在上线后才发现无法补回。
为什么小样本迁移顺利，规模化后却出现例外
试迁几十条记录时，字段大多能对上，看起来方案可行。但样本量一放大，例外就冒出来：同一字段在不同年份被填入了含义不同的内容，或者早期记录为空、后期才被强制填写。此时若仍按样本阶段的映射表执行，就会出现两种相反的结果——要么大量记录被塞进并不适合的新字段，要么原本有业务含义的数据被静默丢弃。
这个矛盾并不说明迁移工具不可靠，而是说明旧系统的字段语义本身没有在新结构里被重新确认。样本阶段掩盖了历史数据的分布差异。
两种解释：字段冗余，还是结构缺位
规模化后出现例外，通常有两种解释，需要分开验证。
- 解释一：字段确实冗余。旧系统里多个字段记录的是同一件事，只是命名不同或分属不同模块。这种情况下，例外只是重复数据之间的不一致，保留一个规范项即可。
- 解释二：新结构缺少承接位置。旧字段承载的业务含义在新模型里没有对应容器，于是迁移时只能硬塞或丢弃。例外暴露的是结构设计缺口，不是数据脏。
两者处理方式完全不同：前者可以合并，后者必须先补结构再迁。误判会把结构问题当成数据问题，用清洗手段掩盖设计缺陷。
用哪些证据区分这两种解释
可以按下面几步取证，每步的结果都会改变下一步动作。
- 统计字段的取值分布与空值率。若某字段在全部记录中高度重复另一字段，且差异只出现在少数历史记录，倾向冗余；若空值集中在早期、后期稳定填写，倾向结构缺位。
- 追踪字段被谁读取。列出当前前台展示、后台查询、导出报表中对它的引用。若没有任何读取路径，它可能只是录入遗留；若仍被读取但新结构无对应项，就是缺位。
- 做一次假设性删除。假设该字段不迁入，检查哪些页面、导出或人工判断会因此失去依据。若答案是“无法从其他字段推导”，保留优先级上升。
假设一个短例子：旧系统用“客户等级”和“客户标签”两个字段，样本里两者几乎一致。规模化后发现标签有十几种取值，等级只有三档。此时等级可能是标签的粗粒度投影，属于冗余；但若标签只在近两年填写，早期记录只有等级，那么等级是早期唯一的业务依据，不能简单删除，需要保留并标注时间范围。这个判断不依赖工具，而依赖对读取路径和填写历史的核对。
保留项决策的实际动作与影响
对每个存疑字段，先做一个动作：在迁移映射表里把它标为“保留—待确认”“合并—需规则”或“暂缓—需补结构”，并写明判定依据。这个动作的结果会直接影响下一步：标为保留的字段需要在新结构里分配独立位置并保留原始值；标为合并的字段需要先定义合并规则，否则不同来源会互相覆盖；标为暂缓的字段不能进入首轮迁移，需要先补结构或确认业务方是否仍需要。
完成标注后再做一次小范围回放，用规模化阶段暴露的例外记录验证规则是否成立。若某条规则在回放中产生新的歧义，说明它依赖的假设还不稳，应退回确认而不是继续扩大迁移范围。
不能直接照搬的边界
上述方法适用于字段仍参与当前业务判断、且新旧结构之间可以建立语义对应的情况。如果旧系统字段本身来自外部接口、且对方已停止提供，或者字段内容涉及需要单独授权的数据，保留决策就不能只按业务读取路径判断，需要先确认数据来源与使用条件是否仍然成立。边界之外的情况，应单独列出，不要用同一套映射规则处理。
最终判断标准可以归纳为一句：保留项是那些删掉之后无法从新结构其他位置重建、且仍被实际读取的字段；其余字段的取舍，取决于合并规则能否被验证，而不是迁移工具能否自动映射。
