WordPress搬家：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2eacb0ca81d3.html
📄
WordPress搬家：旧系统字段无法完整迁入时怎样决定保留项
先给有条件的结论：如果旧字段对应的内容在新站仍有明确用途，且能在新结构里找到稳定归属，就保留并迁移；如果只是旧系统历史遗留、没有前台展示或后续维护价值，就放弃并记录。判断依据不是字段数量，而是字段是否承载当前业务动作。若旧字段只用于一次性统计或已下线功能，即使数据完整也不应保留，否则会拖慢迁移和后续维护。
先判断字段是否还影响前台展示或后台操作
把旧系统字段逐个过一遍，问两个问题：这个字段的值是否出现在用户可见页面？这个字段是否参与编辑、审核、筛选或导出流程？两个答案都是否，基本可以列入放弃项。只要有一个答案是肯定的，就进入保留评估。
假设一个旧站有“作者别名”“来源机构”“内部编号”三个字段。作者别名用于前台署名，保留；来源机构只在旧后台统计里用过，前台不展示，放弃；内部编号用于和外部系统对账，但新站不再对接该系统，放弃。这个例子说明，字段的历史存在不等于当前必要。
实际动作：在迁移前做一张字段去向表，列出旧字段名、前台是否使用、后台是否参与流程、新站对应字段或替代方案。做完这张表，下一步才能决定是原样迁入、合并进现有字段，还是直接丢弃。
保留项要区分“原样迁入”和“并入新字段”
保留不等于照搬。旧系统的字段结构往往和新系统不同，能原样迁入的通常是独立、单一用途、格式稳定的字段，例如纯文本的副标题、来源说明。需要并入新字段的，常见于旧系统把多个信息塞进一个字段的情况，例如“备注”里同时有联系人、电话和日期。
选择条件可以这样分：如果旧字段在新站有独立展示位置，且编辑人员会继续单独维护，就原样迁入；如果旧字段只是补充说明，新站已有更合适的字段承载，就并入并保留原文，不再单独建字段。代价是并入后无法按旧字段单独筛选，但后台结构更干净。
反例：如果旧字段虽然看起来是备注，但被旧系统用于触发邮件通知或权限判断，就不能简单并入。此时要先确认新站是否还需要同样逻辑，需要则保留独立字段并重建触发条件，不需要则先停用再迁移，避免迁移后出现无意义的空字段。
放弃项要留下可追溯记录，而不是直接消失
决定放弃的字段，不要只从迁移脚本里删掉。把旧字段名、放弃原因、判断人、判断日期写进迁移记录。这样做的实际作用是：上线后如果有人问“为什么旧站某个信息不见了”，可以快速回答，而不是重新翻旧数据库。
如果旧字段数据量不大，可以导出为一份离线存档，标注“不迁入新站”。这不影响新站结构，也为后续审计留下依据。注意，存档不等于新站要保留字段，两者不要混为一谈。
下一步动作：完成字段去向表后，先在小范围测试迁移，检查保留字段是否在前台和后台都正常显示，并入字段是否丢失原文，放弃字段是否确实没有影响任何页面。测试结果会直接影响是否调整保留清单，而不是直接全量迁移。
什么时候应该推翻“保留有用字段”的结论
如果旧字段的数据质量很差，例如大量为空、格式混乱、重复率极高，那么即使它理论上还有用途，也不值得原样迁入。此时更合理的做法是：只迁移能清洗出有效值的部分，其余放弃，并在新站用新的录入规则重新积累。
另一个反例是旧字段涉及已下线业务。比如旧站有“活动报名批次”字段，但活动已经结束且不再举办，保留它只会让编辑界面多一个永远不填的输入框。这种情况下，放弃比保留更符合当前维护需要。
因此，结论要加一个前提：保留项必须同时满足“当前有用”和“数据可用”。缺少任何一个，都应重新评估，而不是因为字段存在就默认迁移。
把决定落到一次可回退的迁移动作
最终动作可以按这个顺序执行：先冻结旧字段清单，再标记保留、并入、放弃三类；然后只对保留和并入字段写迁移规则；迁移后抽查前台页面和后台编辑界面；最后把放弃字段的存档和判断记录归档。这样做的结果是，下一步无论是继续迁移剩余内容，还是回退调整，都有明确依据。
如果抽查发现某个被放弃的字段其实仍在前台某处被调用，就把它从放弃改为保留，并重新跑一次该字段的迁移。这个回退动作本身，就是字段决策是否正确的验证方式。
