建站入门教程：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cf41efb9d02a.html
📄
建站入门教程：旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“旧系统里有没有这个字段”决定保留，而要按“这个字段在新站上有没有独立任务”决定。一个字段如果只服务于旧后台的编辑习惯、旧模板的排版占位，或与另一个字段永远同步，就可以退出；如果它承担筛选、权限、计价、对外承诺或历史追溯中的任意一项，就必须保留，哪怕新系统暂时只能把它塞进备注或自定义字段。判断顺序是先列出字段的读取方，再决定保留、改写或退出，最后才处理数据搬运。
先找字段的读取方，而不是先看字段名
旧系统字段迁不完整，最常见的原因不是数据量，而是字段之间存在旧系统特有的耦合。比如一个“所属分类”字段，在旧站里既用于导航，又被模板拿来控制侧栏广告，还被编辑当作归档标签。到了新站，这三件事可能由三个不同机制承担。此时如果只把字段值搬过去，导航会乱，广告位会错，归档也会失真。
可执行的动作是：对每个候选字段，列出它在旧站被哪些地方读取，包括页面模板、查询条件、后台筛选、导出报表、对外接口和人工流程。读取方只有一个，且新站已有替代机制，这个字段就进入退出候选；读取方有两个以上且职责不同，就要先拆分职责，再决定保留哪一部分。这个动作的结果会直接改变下一步：拆分后往往只剩一个真正需要迁移的值，迁移量比预想小得多。
保留、改写、退出各自成立的前提
保留适用于字段仍承担独立任务，且新系统有对应容器。例如订单号、发布时间、作者署名、状态标记。这类字段即使新系统字段类型不同，也应保留语义，必要时用自定义字段承接。前提是你能说清谁在什么场景下读取它；说不清读取方的字段，不要因为“删了可惜”而保留。
改写适用于旧字段把多个职责压在一起，而新站要把它们分开。典型情况是一个“备注”字段里混着内部说明、对外提示和操作日志。改写的前提是你能按来源或格式把它们切开，例如按前缀、按录入人、按时间分段。切不开时不要硬拆，先整段保留为只读存档，等有明确读取需求再处理。
退出适用于字段只服务于旧模板排版、旧后台筛选习惯，或与另一个保留字段永远同值。退出的前提是：新站没有任何页面、查询、导出或人工流程需要它。退出不等于删除数据，可以把原值留在离线备份里，但不再进入新站结构。这样做的结果是新站字段表更短，后续编辑和迁移的判断成本都会下降。
用一个假设例子看清取舍边界
假设旧站有一个“推荐等级”字段，取值是一到五。旧模板用它控制首页排序，编辑用它标记重点内容，运营导出报表时也按它筛选。新站首页排序改由编辑手动置顶，重点内容改由标签控制，报表则可以直接按标签统计。此时“推荐等级”的三个读取方都有替代，唯一还依赖它的是历史报表的同比对照。于是合理做法不是整体保留，而是把历史值导出为只读存档，新站不再保留该字段。反过来，如果新站首页排序仍要按等级自动计算，这个字段就必须保留，并且要确认新系统能否按同样规则读取。
这个例子的关键不是等级本身，而是读取方是否被替代。替代不完整时保留，替代完整时退出，部分替代时改写。判断依据来自读取方清单，而不是字段在旧系统里的重要感。
迁移前先做一次小范围试搬
决定保留项之后，不要直接全量导入。先选一小批记录试搬，观察三件事：保留字段的值是否完整到达；改写字段的拆分规则是否稳定；退出字段是否真的没有页面或流程报错。试搬结果会暴露两类问题：一类是字段类型不兼容，例如旧系统允许多值而新系统只接受单值；另一类是隐藏依赖，例如某个模板仍按旧字段名查询。
发现隐藏依赖时，处理顺序是先改读取方，再改字段。读取方改完仍需要该字段，才把它加入保留清单；读取方改完不再需要，就把它移入退出清单。这个顺序能避免为了迁就一个旧模板而保留整批无用字段。
无法判断时的暂存策略
如果某个字段的读取方暂时查不清，不要把它塞进主结构，也不要直接丢弃。可以建立一个临时存档区，按原样保存字段名和值，并在新站中不对外读取。暂存的前提是标注来源和暂存原因，避免半年后没人知道它为什么存在。后续如果出现明确读取需求，再从存档区提取并正式建字段；如果一直没有需求，存档区可以整体下线。这个策略的代价是多一层存储和一次判断，但比错误保留或错误删除更容易收拾。
最终判断标准可以压缩成一句话：字段在新站有没有独立任务，有就保留，任务被拆开就改写，任务消失就退出。先确认读取方，再试搬小批数据，最后才全量迁移，这样即使旧系统字段无法完整迁入，也不会把混乱带进新站。
