巴中网站建设：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4087cd9aeb33.html
📄
巴中网站建设：旧系统字段无法完整迁入时怎样决定保留项
先给结论：当旧字段无法完整迁入新站时，保留项不应按“字段在旧系统里有多重要”来决定，而应按“这个字段离开旧系统后，哪个下游动作会断”来决定。保留的判断依据是下游依赖，不是字段本身的历史地位。下面用两个解释路径说明怎么区分，并给出可执行的选择条件。
矛盾现象：迁移工具报错为零，内容却对不上
常见的情况是：迁移脚本跑完，日志显示成功，字段映射表也填满了，但编辑打开新站后台发现正文里混进了旧模板的样式标记，或者某个分类描述被塞进了另一个字段。这时容易产生两种解释。
解释一：旧字段本身结构混乱，属于历史遗留问题，应该趁迁移做减法，把无法对应的字段直接丢弃。解释二：字段结构没问题，是迁移映射逻辑把语义相近但用途不同的字段合并了，丢弃会永久损失信息。两者都成立，但对应完全不同的动作，所以需要证据来区分。
区分两种解释的证据：看字段的下游消费方
能区分这两种解释的关键证据，不是字段在旧数据库里的类型，而是谁在读它。可以按下面的顺序排查：
- 列出每个待定字段的读取方：是前台模板直接渲染、是站内搜索索引、是列表页筛选条件，还是只被后台编辑人工查看。
- 查该字段是否被外部系统引用：例如旧站的接口、第三方统计脚本、导出的报表模板。这类引用往往不在新站需求文档里，却会真正断掉。
- 看字段是否参与过历史内容的生成规则：例如某个字段曾被用来拼接标题或摘要。若规则仍在新站沿用，字段丢失会导致批量内容异常。
如果排查后发现某字段没有任何前台或外部读取方，只有编辑在后台看，那解释一更可能成立，可以丢弃或在后台备注。如果发现它有外部引用或参与生成规则，解释二更可能成立，应保留并单独映射，而不是合并进近似字段。
两个可选做法及各自成立的条件
做法A：保留原字段，在新站中单独建字段并原样迁入。成立条件是字段有明确下游读取方，或迁移后短期内仍需要与旧系统并行比对。代价是新站字段数量增加，后台表单变长，编辑录入负担上升，且新旧字段可能长期并存造成混淆。
做法B：合并或丢弃字段，把内容并入语义最近的现有字段。成立条件是字段无任何自动读取方，且内容属于描述性、非结构化信息，人工阅读即可理解。代价是若日后需要按该字段筛选或做结构化展示，历史数据已经无法还原，只能靠人工回补。
一个注明假设的短例子：假设旧站有一个“来源单位”字段，前台从不显示，但编辑在后台用它区分稿件出处。若新站也没有按来源筛选的需求，做法B成立，把来源信息写进正文末尾即可。若新站计划做按来源聚合的列表页，做法A成立，必须单独保留该字段，否则聚合页无法生成。这个判断与实际站点无关，只说明比较方法。
可执行动作：先冻结字段清单，再决定迁移批次
具体动作是：在迁移前冻结一份字段清单，对每个待定字段标注读取方、是否有外部引用、是否参与生成规则。标注完成后，把字段分成三组——必须原样迁入、可合并、可丢弃。然后按组安排迁移批次，必须原样迁入的字段先迁并做一次前台渲染验证；可合并的字段在合并后抽查若干条内容，确认语义没有反转；可丢弃的字段在旧库中保留只读备份，不写入新站。
这个动作的结果会直接影响下一步：如果必须原样迁入的字段在前台渲染验证中出现空值或错位，说明映射逻辑还有问题，此时不应继续迁移其余批次，而应先修正映射再重跑；如果合并后的抽查发现语义反转，说明该字段应退回必须原样迁入组，而不是继续合并。反过来，如果三组验证都通过，下一步才可以进入内容校对和链接检查，而不是直接宣布迁移完成。
一个容易忽略的适用条件
上述判断成立的前提是旧系统仍可读取。如果旧系统已经下线或数据库不可访问，那么“可丢弃”就不再是选项，所有字段都只能按现有导出文件处理，此时保留项的决定依据变成导出文件里实际存在的列，而不是旧系统的原始设计。这种情况下应先确认导出是否完整，再讨论取舍。
不要用请求量归零来证明处理正确
迁移后旧站请求量下降甚至归零，常被当作迁移成功的证据。但请求量归零还有别的合理解释：旧站域名解析已切换、旧站被设置为禁止访问、或者外部引用方已经改用了新地址。这些都不能单独证明字段保留项决定得对。真正能说明问题的是前台渲染结果、外部引用是否报错、以及编辑能否在新后台完成原有录入流程。把这几项作为验收依据，比看请求量更可靠。
