wordpress 空间，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5f5b4aee4d8a.html
📄
wordpress 空间，旧系统字段无法完整迁入时怎样决定保留项
先给结论：当旧系统字段无法完整迁入 WordPress 空间时，保留项不应按“字段在旧系统里是否重要”来定，而应按“这个字段在目标站点的哪个页面、由谁读取、缺失后会造成什么可核对后果”来定。如果某个字段找不到明确读取方，也没有页面承载它的展示位置，它就不该进入保留清单。反例是：如果旧字段是外部系统通过接口读取的业务标识，即便前台从不展示，也必须保留，否则迁移后对接会静默失败。
先区分“字段重要”和“字段有读取方”
多角色对同一事实理解不同，通常是因为大家说的“重要”不是同一件事。运营说某字段重要，可能指它曾用于筛选；技术说某字段重要，可能指数据库里有索引；编辑说某字段重要，可能指旧页面正文提到过它。这些都不等于迁移后仍有人读取它。
把分歧转成可核对项目，可以要求每个主张保留字段的人回答三个问题：谁读取、在哪个页面读取、缺失后哪一步会失败。答不出读取方的字段，先进入待定区，而不是直接删除。待定区的作用是让分歧显性化，而不是替谁做判断。
这里有一个实际动作：让每个角色各自列出自己日常操作中会用到该字段的步骤，再把这些步骤合并去重。合并后如果某字段只出现在一个人的描述里，且该描述无法对应到具体页面或接口，就可以把它降级为“仅存档，不迁入”。这一步的结果会直接决定下一步：进入保留清单的字段才需要设计 WordPress 空间里的存储方式，降级的字段只需保留旧系统导出文件。
用三种读取路径判断字段是否必须保留
字段的读取路径通常只有三类，判断标准也不同。
- 前台展示读取：访客能在某个页面看到它。判断依据是页面上是否有对应位置，以及去掉后页面信息是否残缺。这类字段通常需要迁入，但可以改变存储形式，例如旧系统里的独立字段合并进正文或自定义字段。
- 后台管理读取：编辑或运营在后台列表、筛选、导出中使用它。判断依据是迁移后是否还有同类操作。如果旧筛选流程本身要被废弃，字段也可以不迁。
- 程序接口读取：外部系统按固定标识取值。判断依据是接口契约是否仍然有效。这类字段即使前台完全不可见，也必须保留，并且要核对字段名、类型和空值处理方式是否与旧系统一致。
三种路径里，只有程序接口读取的字段最容易被误删，因为它没有页面痕迹。相反，前台展示字段最容易被过度保留，因为大家都能在旧页面上看到它，却忽略了新页面可能根本不需要这个信息。
把分歧写成可核对的项目，而不是继续讨论
当多个角色对同一字段有不同理解时，继续开会往往只是重复立场。更有效的做法是把每个字段写成一行可核对记录，至少包含：字段名、主张保留的角色、读取路径、对应页面或接口、缺失后的可观察后果、当前决定。这样讨论对象从“重不重要”变成“这一行是否成立”。
假设有一个旧系统字段叫“来源渠道”，运营认为必须保留，因为过去用它做月度统计；技术认为可以不迁，因为新站没有对应筛选；外部系统则可能通过接口读取它做归因。在这个假设里，如果外部接口仍有效，该字段必须保留；如果接口已停用且新站统计改由另一套标识完成，则可以不迁。这个例子只说明比较方法：先确认读取路径，再决定去留，而不是按角色话语权决定。
需要说明适用条件：这套方法适用于字段数量可控、能追溯到读取方的迁移。如果旧系统字段本身就是历史遗留、无人能说明用途，且没有任何接口依赖，那么更合理的动作是先整体导出存档，再在新站按当前需求重建字段，而不是逐个争论。
决定保留项后，下一步做什么
保留清单确定后，下一步不是立刻批量导入，而是先做一次字段映射核对。映射表要写清旧字段名、新字段名、类型转换规则、空值处理方式、默认值来源。对于程序接口读取的字段，还要确认迁移后字段名是否保持不变；如果必须改名，就要同步通知接口使用方，否则会出现数据写入成功但读取失败的情况。
完成映射核对后，再抽样验证。抽样时不要只看字段有没有值，而要看读取方能否按原路径取到值。如果前台展示正常但接口取值为空，说明问题不在导入，而在映射或权限。这个结果会影响下一步：是修正映射后重导，还是保留旧字段名并增加兼容层。
最后，把未保留字段的旧数据导出文件与保留清单一起归档，并注明决定依据和决定人。这样后续如果有人再问某个字段为什么没迁，可以直接核对当时的读取路径判断，而不必重新争论一遍。
