马鞍山网站建设：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /00713ea10e32.html
📄
马鞍山网站建设：旧系统字段无法完整迁入时怎样决定保留项
先按字段做一次三分：能原样迁入的保留，语义仍成立但结构要变的改写，业务上不再被使用的退出。判断依据不是字段名像不像，而是这个字段今天是否仍被查询、展示、计算或对账使用；只要有一项在用，就不应该直接删。
先判断字段是“数据”还是“业务状态”
旧系统里很多字段看起来只是文本，实际承担状态机的作用。例如一个 status 字段可能同时表示审核进度和发布状态，迁入时如果只保留字符串，后续流程就无法继续推进。
- 只用于展示的历史文本，通常可以保留为备注或归档字段。
- 参与查询、筛选、排序的字段，需要在新结构中保留可索引的等价列。
- 参与计算或对账的字段，必须保留原始值，不能只保留计算后的结果。
- 被多个模块共同写入的字段，要先确认写入方，再决定保留在哪一侧。
实际动作：把旧表每个字段的读取方和写入方列出来。如果某个字段只有写入没有读取，它大概率可以退出；如果读取方超过一个，保留优先级应提高。这一步的结果会直接决定后面是改写结构还是放弃迁移。
保留的条件：字段仍有下游依赖
保留下来的前提是存在明确的下游依赖，而不是“以后可能有用”。可核验的证据包括：页面上仍在渲染该值、后台仍在按它筛选、报表仍在统计它、接口仍把它返回给调用方。
假设一个场景：旧系统的客户表里有一个“客户来源”自由文本字段，新系统改成了枚举值。如果销售报表仍按这个字段分组，就不能直接丢弃，而应保留原始文本并新增一个映射后的枚举列，两者并存一段时间。这样做的代价是表结构变宽，收益是历史统计口径不断裂。
如果字段只出现在已下线的页面或已停用的导出模板里，保留的收益就很低。此时更合理的做法是把它归入迁移日志，而不是塞进主表。
改写的条件：语义还在，但结构不再匹配
改写适用于字段的业务含义仍被需要，但旧结构无法直接映射的情况。典型是“一个字段塞了多个值”，例如旧系统用逗号分隔的标签，新系统要求独立关联表。
- 确认旧值的分隔规则是否稳定，是否存在转义或空值混用。
- 确认拆分后是否会产生重复项，重复项是否需要去重。
- 保留一份原始值，便于拆分错误时回溯。
- 先在小批量数据上验证拆分结果，再决定是否全量执行。
改写的风险在于不可逆。如果拆分规则本身不明确，例如同一个分隔符在不同记录里含义不同，那么改写会制造出错误数据。这种情况下，保留原始字段并标记为“待人工确认”比强行拆分更稳妥。
退出的条件：字段既无读取方也无合规留存要求
退出不是删除，而是不再进入新系统的主数据模型。判断退出需要同时满足两个条件：没有活跃读取方，且没有外部留存要求。
如果字段涉及合同、财务凭证或需要配合审计的记录，即使当前没有页面展示，也不应直接退出。此时应保留在归档表中，并记录归档时间和原因。反之，如果字段只是早期表单的临时备注，且没有任何导出或统计引用它，退出的成本最低。
实际动作：对准备退出的字段做一次反向查询，确认没有接口、报表或定时任务引用。如果发现引用，就回到保留或改写分支；如果没有，再执行退出。这个检查的顺序不能颠倒，否则容易出现上线后才发现数据缺失。
用一份字段决策表固定结论
把每个字段的结论写成一行，至少包含：字段名、当前读取方、是否参与计算、建议处理、处理依据。处理列只允许填保留、改写、退出三种之一，避免出现“先放着”的模糊状态。
这份表的作用不是追求一次判断全对，而是让后续变更可追溯。当某个字段被改写后出现异常，可以回到表中查看当时的依据，判断是依据本身错了，还是执行环节出了问题。字段迁移的取舍最终服务于业务连续性，而不是让新旧结构看起来一致。
