网站搭建流程，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /77a079aca6b4.html
📄
网站搭建流程，旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“旧系统有没有这个字段”决定保留，而按“新站有没有页面、模板或业务流程真正消费这个字段”决定。一个字段只要没有明确落点，就先不迁；有落点但历史值缺失严重，则迁结构、不迁脏值。判断顺序是：先列出新站消费点，再评估旧值可用率，最后决定整字段迁移、部分迁移还是仅保留映射关系。
批量失败暴露的往往不是字段太多，而是消费点没对齐
常见矛盾是：抽样迁十几个页面都正常，字段一个不少；一旦放大到全量，就出现大量空值、乱码或长度溢出。这时容易得出两个相反解释。
- 解释一：旧数据质量差。字段本身设计没问题，只是历史录入随意，导致规模化后脏值集中暴露。
- 解释二：新站消费方式变了。同一个字段在旧站是自由文本，在新站却要参与筛选、排序或结构化展示，抽样时恰好没碰到这些用法。
两种解释对应完全不同的动作：前者要清洗数据，后者要改保留策略甚至改新站设计。区分它们不能只看报错数量，要看同一批数据换一种消费方式后是否还失败。
用一组可区分证据判断该保还是该舍
可以设计一个小对照：把同一字段分别放入“纯展示”和“参与筛选”两种模板，各跑一批样本。若纯展示正常、参与筛选大量失败，问题在消费方式，属于解释二；若两种方式都失败，且失败值集中在特定时间段或特定录入来源，才更接近解释一。
另一个证据是旧值的可解析比例。假设某字段共 1000 条记录，其中 620 条能解析为预期结构，380 条为空或格式不一。这个比例本身不能单独证明该字段该舍，因为空值可能只是旧站从未强制填写，而新站恰好需要它。更稳妥的做法是：先确认新站哪些页面、筛选器或通知流程会读取它，再决定是否值得为 620 条可用值保留整个字段。
保留项按消费强度分三档处理
把候选字段分成三档，比逐个争论更快。
- 强消费字段：新站有页面直接展示，或参与筛选、排序、权限判断。这类字段必须迁，且要迁结构；历史脏值单独放入备注或原值字段，不阻塞主流程。
- 弱消费字段：只在个别详情页出现，缺失不影响主流程。可以迁，但允许为空，不设必填校验。
- 无消费字段：新站没有任何模板、页面或流程读取它。即使旧系统里很完整，也先不迁，只保留旧系统到新字段的映射说明，方便日后追溯。
这里的实际动作是：先做一张“字段—消费点”对照表，每行写字段名、新站读取它的位置、缺失时的降级表现。做完这张表，保留项基本就确定了。它直接影响下一步：只有强消费字段才进入必迁清单，其余进入可选清单，避免迁移范围无限膨胀。
边界：抽样成立不等于全量成立
个别样本迁移成功，只能说明该样本的字段组合在新站有对应落点，不能证明全量可行。规模化后出现例外，通常来自三类边界：旧值长度超过新字段限制、旧值枚举与新站选项不重合、旧值依赖旧站才有的关联记录。遇到这些例外，不要为了“一个不漏”而放宽新站校验，那会把问题推迟到上线后。更合理的取舍是：强消费字段做值映射，映射不上的记录进入人工核对队列；弱消费字段允许截断或留空；无消费字段直接不迁。
如果迁移后某些字段的请求量或读取量归零，也不能单独证明删除正确，还要排除页面尚未上线、模板未接入、缓存未刷新等合理解释。决定保留项的依据始终是消费点是否存在，而不是迁移当下是否热闹。把这条原则写进迁移说明，后续新增字段时才有统一尺度。
