株洲网站设计：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9e10d89f3fd8.html
📄
株洲网站设计：旧系统字段无法完整迁入时怎样决定保留项
结论先给：当旧库字段无法完整迁入新站时，保留项不应按“字段是否重要”来定，而应按“新站前台或后台是否有真实消费方”来定。有消费方的字段迁移，没有消费方的字段归档留存，只有两端都成立才值得为它改动新数据结构。下面先说明这个判断成立的三个前提，再给出会让它失效的反例，最后给出可执行的下一步。
先确认三个前提，否则判断会跑偏
第一，新站已经确定内容模型，字段清单不再随页面改版频繁变动。第二，旧系统仍可读，能在迁移期间反复回查原值，而不是迁完就关库。第三，业务方能说清每个字段在旧站里由谁填写、被谁查看。三条缺一条，保留项的决定就会从“按消费方判断”退化成“按印象争论”。
满足前提后，把旧字段按消费方分成三组处理：
- 前台直接渲染：出现在列表、详情、筛选或结构化数据里，必须迁，且要确认新模板有对应输出位。
- 后台运营使用：不对外显示，但编辑、客服或审核流程依赖它，迁入后台字段或备注区即可，不必进前台模型。
- 无消费方：既不在前台输出，也不参与任何后台流程，只留在旧库快照中，不进入新站。
这三组的处理动作不同，成本差别很大：第一组要改模板和接口，第二组通常只加一个后台字段，第三组只需保留一份可查询的旧数据副本。
真正决定取舍的是消费方，不是字段数量
很多团队把“字段多”当成迁移难点，实际上难点在字段与新页面结构是否对得上。一个旧站有八十个字段，如果其中六十个只被旧后台的某个统计页读取，而该统计页在新站已取消，这六十个就没有迁移价值。反过来，一个看起来边缘的字段，比如“来源备注”，如果客服在新站仍要按它筛选工单，它就必须迁。
判断时可以问一句：如果这个字段在新站为空，谁会先发现问题？能指出具体角色和具体页面，就保留；答不上来，就先归档。这个问法比打分表更省时间，也更难被“以后可能有用”搪塞过去。
一个会让上述结论失效的反例
假设旧系统的字段值本身不可信：同一字段在不同年份由不同人填写，格式不统一，甚至存在互相矛盾的值。此时“有消费方就迁”会失效，因为迁过去的数据无法直接使用，前台渲染出来反而是错的。这种情况下要先做值域清理，再决定保留项；如果清理成本高于重新采集，正确动作是只迁字段结构、不迁历史值，让新站从上线后重新积累。
另一个失效情形是字段承担法律或对账用途，比如合同编号、开票信息。这类字段的保留不由前台是否需要决定，而由留存义务决定，应单独列出，不放进上面的三组里讨论。
下一步动作：先做一张字段去向表，再动模板
具体做法是导出一份旧字段清单，逐行填四列：字段名、前台是否输出、后台是否有角色使用、无消费方时的归档位置。填完后只对“前台输出”那一列打勾的字段改动新站模板和接口，其余先不动。这样做的直接结果是迁移范围被压缩到可验证的一小部分，你可以先用这批字段跑通一次完整的前台展示，确认无误后再处理后台字段。
如果第一轮跑通后发现某个被归档的字段其实有消费方，回补成本也仅限于加一个后台字段，而不是重做内容模型。这个顺序把风险留在可回退的一侧。假设旧站有一百二十个字段，按上述方法可能只有二十多个进入前台迁移，其余分入后台与归档；这个数字只是说明比较方法，实际比例取决于你的页面结构和运营流程，需要按清单逐项确认。
