网站设计流程旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /97b31fd07fcc.html
📄
网站设计流程旧系统字段无法完整迁入时怎样决定保留项
结论先给：如果旧字段仍被至少一个现行业务流程读取，或迁移后无法从其他数据重建，就应保留并进入新结构；如果字段只服务于已停用的展示模块、可由主数据推导，或长期为空且无人能说明用途，就应弃用。判断依据不是字段数量，而是它是否承担业务含义。只要出现“字段虽无人主动使用，却被外部接口按固定位置解析”的情况，上述结论就失效，必须把接口依赖纳入保留清单。
先区分字段的三种角色，而不是先看新旧
旧系统字段无法完整迁入时，最容易犯的错是按表结构逐个搬运。更有效的做法是先给字段分角色：
- 业务字段：订单状态、合同编号、结算金额等，被流程或报表直接读取，必须保留。
- 展示字段：旧模板里的角标、临时标签、活动文案，只影响前端外观，通常可在新结构中重建或弃用。
- 技术字段：自增主键、旧路径、同步标记、校验位，只有在外部系统仍按它对接时才需要保留。
把字段归入哪一类，直接决定下一步动作：业务字段进入新模型并做映射校验；展示字段先确认新页面是否还需要同义信息；技术字段则要追问“谁在读取它”。如果没人能回答最后一个问题，先不要删，而是标记为待观察，等接口日志或调用方确认后再处理。
保留项要满足可验证条件，而不是凭感觉
决定保留一个字段前，至少满足以下一项：
- 有明确的读取方，例如结算流程、客服查询或对外接口。
- 字段值无法从其他字段推导，删掉后会造成信息永久缺失。
- 监管、对账或合同要求必须留存原始值。
反过来，满足以下条件可以考虑弃用：字段长期为空且无人能说明业务用途；字段可由主数据、时间戳或状态机推导；字段只被已下线的旧页面引用。这里的关键动作是做一次字段用途访谈并留下记录：谁读、何时读、读不到会怎样。记录结果会直接影响下一步——有读取方的字段进入迁移映射表，无读取方的字段进入弃用候选，而不是直接删除。
一个注明假设的短例子
假设某旧系统有“客户等级”和“历史折扣码”两个字段，新系统只保留会员等级。若客服在下单时仍按历史折扣码核对优惠，则折扣码必须保留，哪怕它看起来只是旧营销遗留；若折扣码只用于早已停用的活动页，且优惠金额已写入订单记录，则可以不迁。这个例子的判断点不是字段新旧，而是“删掉后哪个动作会失败”。数字只用于说明比较方法：可以统计字段非空率和近一段时间的读取次数，但非空率低不等于可删，因为低频字段可能恰好对应高价值业务。
会使结论失效的反例：外部接口按位置解析
有一种情况会让“无人使用即可弃用”的判断失效：外部接口并不按字段名读取，而是按固定位置或固定长度解析旧数据。此时字段在内部可能无人主动查询，但一旦缺失，对方系统会解析错位或直接失败。遇到这种情况，不能只看内部使用记录，而要先确认对接方、解析规则和容错方式。若无法确认，保留原字段并做兼容输出，比直接删除更稳妥。这个反例说明：保留项决策必须同时覆盖内部流程和外部依赖，不能只做单侧判断。
下一步动作：先出映射表，再决定删留
把候选字段整理成一张映射表，至少包含旧字段、角色分类、读取方、是否可推导、处理结论五列。处理结论只允许三种：保留并迁移、保留但仅归档、弃用。完成这张表后，下一步不是马上开发，而是让业务、客服和技术对接人各确认一遍读取方。确认结果会改变迁移范围：若某字段被追加为业务字段，就要补映射校验；若被降为归档字段，就不进入新界面，只保留查询能力。这样做的结果是，删留决定有据可查，后续返工也会减少。
