网站开发概述：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2509303514b7.html
📄
网站开发概述：旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段能不能迁”决定去留，而要按“这个字段当前是否还在支撑一个真实动作”决定。把候选字段分成三类——继续保留并迁入、改写后再用、随旧流程一起退出。判断依据不是字段数量，而是它是否仍被读取、被谁读取、缺失后会发生什么。
先区分“字段存在”和“字段被使用”
旧系统里大量字段是历史遗留：当年录入过，后来流程改了，没人再填，也没人再看。迁移前先做一次使用证据盘点，比直接问业务方“这个还要不要”更可靠。
- 读取证据：前台页面、后台列表、导出报表、对接接口里是否还出现该字段。
- 写入证据：最近一段时间是否还有新数据写入，还是只有存量老数据。
- 依赖证据：是否有计算、筛选、权限判断、对外通知依赖它。
三类证据都为空，才适合进入退出候选；只要有一类成立，就不能仅凭“迁移麻烦”把它删掉。反过来，如果某字段写入已停但读取仍在（例如老订单里的历史备注），它属于“冻结保留”，迁入后应设为只读，而不是继续开放编辑。
保留、改写、退出各自成立的前提
这三条路线不是按优先级排序，而是各有适用条件。选错方向的代价通常比字段本身更大。
原样保留
成立前提是：字段语义在新系统里仍然准确，且没有与新结构冲突。典型情况是名称、编号、创建时间这类含义稳定的字段。原样保留的动作是映射到新表同义字段，并核对长度、格式、空值规则。结果是迁移脚本可以批量执行，人工复核量最小。
改写后再用
成立前提是：旧字段承载的信息仍有价值，但它的结构不再适合新流程。例如旧系统把“省市区”塞在一个文本字段里，新系统需要拆成三个结构化字段。此时不能直接搬，而要先定义拆分规则，再对无法解析的存量数据单独标记。动作是写转换规则并抽样验证，结果会决定后续是自动转换还是需要人工清洗队列。
随旧流程退出
成立前提是：该字段对应的业务动作已经取消，且没有对外承诺或合规留存要求。退出不等于立刻删除，稳妥做法是先归档到冷数据表并停止写入，观察一个业务周期。如果期间没有任何读取需求，再执行物理清理。这个动作的结果直接影响下一步：若观察期内出现读取，说明它应回到“冻结保留”，而不是继续删除。
用一个假设例子说明取舍过程
假设某旧内容系统有一个“合作方联系人”字段，新系统不再维护合作关系，改为统一的作者信息。盘点发现：该字段近一年无新写入，但导出报表仍在读取，且部分历史文章页脚仍展示该联系人。
此时三种处理都成立，取决于约束：若报表只是内部留档，可将字段迁入作者表的备注区并标记“历史合作”；若页脚展示仍需保留，则必须原样迁移展示逻辑，不能只迁数据；若合作方已明确要求下线展示，则进入退出流程，先隐藏展示、保留数据，再决定是否归档。可见同一个字段，因读取方不同，结论完全不同。
决定保留项时最容易踩的两个坑
第一，把“迁移难度”当成“保留价值”。难迁的字段往往结构复杂、信息密度高，反而更值得先评估读取方。第二，用总量判断代替逐项判断。迁移后请求量或抓取量下降，并不能单独证明删对了——也可能是页面结构变化、入口调整或抓取节奏变化带来的，需要结合读取日志和业务反馈一起看。
可执行的动作是：先列字段清单，逐项标注读取方、写入状态和依赖关系，再按上面三类打标。打标完成后，保留项进入映射表，改写项进入转换规则，退出项进入归档观察队列。这个顺序能让后续的迁移脚本、人工清洗和上线复核都有明确输入，而不是在上线前才发现某个字段被误删。
