WordPress优化：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e94171841641.html
📄
WordPress优化：旧系统字段无法完整迁入时怎样决定保留项
先给出结论：不要按“旧字段是否还有数据”决定保留，而要按“这个字段在新站里是否承担唯一职责”决定。更准确地说，先判断字段是内容本体、展示参数还是历史痕迹，再把无法迁入的字段分成必须重建、可以合并、允许丢弃三类。这个判断不依赖样本页面看起来是否正常，而取决于规模化后例外是否集中在同一类字段上。
矛盾现象：少量样本正常，批量迁移却开始出错
旧系统字段迁移时，常见一个反常现象：抽十条二十条旧内容做样本，字段都能对上，页面也能打开；一旦全量迁移，例外开始出现。表现可能是某类详情页缺一段参数、某类列表页顺序错乱、某类旧内容反复触发人工修补。样本阶段看不出问题，不代表字段映射成立，只说明样本没有覆盖例外分支。
这时容易得到两个相反解释。解释一：旧字段本身质量差，保留越多越容易把脏数据带进新站，所以应尽量少保留。解释二：新站模型没有承接旧字段的职责，导致原本由字段承担的信息被压进正文或模板，规模化后必然出现例外。两个解释都成立，但适用条件不同。
两个解释成立的不同条件
如果例外集中在少数旧内容，且同一字段在多数页面为空、重复或格式不一致，那么“旧字段质量差”更可能成立。此时保留项应收缩，只保留能稳定对应新站内容模型的部分。
如果例外集中在某一类内容或某一个模板，且旧字段在样本里表现正常、批量后才有问题，那么“新站模型缺职责”更可能成立。此时不应继续删字段，而要先确认该字段是否承担了筛选、排序、权限、展示或关联职责。删掉它，等于把职责转移给正文或人工维护，短期看不出问题，规模化后维护成本会上升。
区分这两种解释，不能只看请求量、抓取量或某个统计是否归零。请求量下降也可能是迁移后入口减少、内部链接变化、缓存策略不同或抓取节奏调整，不能单独证明字段处理正确。
用一组证据区分：字段职责是否唯一
要决定保留项，先给每个旧字段做一次职责盘点。可以按下面几个问题判断：
- 这个字段是否决定内容能否被正确筛选或排序？如果是，通常不能直接丢弃，除非新站有等价结构承接。
- 这个字段是否只影响展示样式？如果只影响样式，可以合并进模板或内容类型，不必逐条迁移。
- 这个字段是否只记录旧系统历史状态？如果新站不再依赖该状态做业务判断，可以标记为允许丢弃。
- 这个字段是否被多个模板或接口同时读取？如果是，保留项要优先处理，因为它影响面更大。
一个实际动作是：先选一类旧内容，把字段按“唯一职责”和“可替代职责”分开，再只迁移唯一职责字段。迁移后观察例外是否从“批量出错”变成“个别缺失”。如果例外明显收敛，说明保留项判断有效，下一步可以扩大同类内容；如果例外没有收敛，说明问题不在字段取舍，而在新站模型没有承接职责，应先补模型再继续迁移。
假设例子：一个旧字段该保留还是合并
假设旧系统里有一个“来源说明”字段，样本页面都能正常显示，但全量迁移后发现部分内容缺失。此时有两种处理：
- 若该字段只用于展示一行说明，且新站正文可以承接，就合并进正文，不单独保留字段。
- 若该字段还参与筛选、归档或权限判断，就不能只合并展示，必须保留为独立结构，否则后续筛选会漏内容。
这个例子的重点不是“来源说明”本身，而是判断字段是否只服务展示。只服务展示的字段可以合并；参与业务判断的字段不能因为样本正常就忽略。假设条件下，合并后页面可能看起来没差别，但筛选结果会变化，这就是规模化后才暴露的例外。
不能直接照搬的边界
样本成立但规模化后出现例外，通常说明样本没有覆盖字段为空、字段重复、字段格式不一致、字段被多个模板读取这几种情况。因此，不能把“样本页面能打开”当作迁移完成的标准。保留项决策应写明适用条件：只对职责唯一的字段优先保留；只对可替代的展示字段允许合并；只对不再参与业务判断的历史字段允许丢弃。
如果旧字段无法完整迁入，先不要追求一次全量保留。更稳妥的做法是先保留影响筛选、排序和关联的字段，再处理展示字段，最后处理历史痕迹字段。每一步都以例外是否收敛为下一步依据，而不是以页面是否暂时正常为依据。这样决定保留项，才能让 WordPress 优化在迁移后仍然可控。
