衡水网站开发旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a1c00b6e9722.html
📄
衡水网站开发旧系统字段无法完整迁入时怎样决定保留项
决定保留哪些旧字段，不能只看字段里有没有数据，而要看这个字段是否还承担业务动作。如果它只用于展示，可以退出；如果它参与计算、审批、对账或对外承诺，就必须保留或改写。先做字段级盘点，再用“样本成立、规模例外”的方式验证，最后才决定保留、改写或退出。
先区分字段的三种角色，再谈去留
旧系统字段大致分三类：第一类是业务状态字段，例如订单状态、审核结果、合同编号，它们决定下一步能做什么；第二类是展示字段，例如简介、标签、备注，删掉只影响页面观感；第三类是历史留痕字段，例如操作人、变更时间、旧编号，它们不参与新流程，但可能被审计或对账引用。
保留项优先从第一类里选。展示字段可以退出，留痕字段可以改写为只读附件或归档表。判断依据不是字段名，而是“谁在什么动作里读它、写它、依赖它”。如果一个字段只被旧页面读取，新站没有任何流程引用，它就不该占用主表结构。
样本成立但规模化出现例外时，先看例外来自哪里
假设你抽了二十条旧记录，字段A都能正常映射到新结构，于是决定保留。上线后却发现批量导入时大量记录在字段A上失败。这时不要立刻推翻保留决定，先分清例外来源：
- 数据本身不完整：旧系统允许空值，新结构要求必填。这是迁移规则问题，不是字段该不该留的问题。
- 取值口径变了：旧字段存的是自由文本，新流程需要枚举值。这属于改写，不是退出。
- 业务已经不用了：字段还在表里，但近期的业务动作都不再写入。这可以考虑退出主流程，转为归档。
样本成立而规模例外，通常说明抽取样本时偏向了大客户、老账号或结构完整的记录。规模化的例外不是字段无价值，而是迁移规则没有覆盖边界情况。此时正确动作是补规则、补映射表，而不是删字段。
保留、改写、退出各自成立的前提
保留成立的前提是：字段仍被新流程读写，且旧值能直接映射，不需要转换口径。保留时要把字段的必填、空值、长度和字符集一并确认，否则会在导入阶段反复报错。
改写成立的前提是：字段承载的业务含义还在，但存储形式需要变化。例如旧字段把“省市区”写在一段文本里，新结构要求拆成三个字段。改写要额外定义拆分规则和无法拆分时的兜底值，并明确兜底值由谁确认。
退出成立的前提是：字段不再参与任何业务动作，且没有对外承诺、审计或对账依赖。退出不等于直接删除，可以先转为只读归档，保留查询能力，等一个完整业务周期后再决定是否彻底移除。这个动作的结果会直接影响下一步：如果归档后仍有人查询，说明退出判断过早；如果无人查询，才具备彻底移除的条件。
用一个假设例子说明决策顺序
假设旧系统有一个“客户来源备注”字段，早期由销售手填，现在新流程改为下拉选择渠道。抽样检查时发现大部分记录都有值，于是最初决定保留为文本字段。规模化导入后，出现大量超长文本和无法归类的描述。
按上面的顺序处理：先确认这个字段是否还驱动业务动作。如果新流程只把它当参考信息，那就改写为“历史备注”只读字段，不参与筛选和统计；如果新流程要用它做渠道归因，那就必须建立旧文本到新枚举的映射表，并为无法映射的记录设置“待人工确认”状态。前一种做法成本低，后一种做法会影响报表口径，需要业务方先确认归因规则。
这个例子的关键不是字段本身，而是它在新流程里是否还有下游依赖。有依赖就改写，无依赖就归档，依赖不清就先冻结，不要急着删。
把决定写成可复查的记录
字段去留容易在多人协作中反复。建议为每个争议字段记录四项内容：旧字段名、当前是否有业务动作引用、迁移规则、以及决定保留或退出的依据。复查时只看这四项，不重新争论字段名好不好听。
如果某项统计在迁移后归零，也不能单独证明删除正确。归零还可能来自采集口径变化、页面入口调整或导入批次未完成。要结合业务动作是否仍被触发来判断，而不是只看数字。把决定和依据写下来，下一次遇到同类字段时才有可复用的判断标准，而不是每次重新拍板。
