网站开发入门指南：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /08cd16bfa22c.html
📄
网站开发入门指南：旧系统字段无法完整迁入时怎样决定保留项
先给出结论：当旧系统字段无法完整迁入时，决定保留项的依据不是字段在旧库里是否重要，而是它在新站上是否仍对应一个可执行的动作。如果某个字段只用于旧后台的检索、排序或内部备注，而新站前台没有任何页面、表单或流程会消费它，那么即使它承载了大量历史数据，也不应优先保留。反过来，一个字段在旧库里可能只是普通文本，但新站需要用它触发通知、生成列表或控制权限，就必须进入保留清单。
矛盾现象：字段数量对不上，往往不是迁移工具的问题
常见的情况是：旧系统导出后字段总数明显多于新系统可建字段数，于是团队开始反复调整迁移脚本、改数据类型、拆分表，仍然对不上。这时通常有两种解释。
第一种解释是结构差异：旧系统把同一业务对象拆成多个字段，例如把“联系人”拆成称呼、姓氏、名字、中间名、后缀，而新站只用一个姓名字段。字段数量减少并不等于信息丢失，只是表达方式变了。
第二种解释是消费端消失：旧系统里某些字段是给已停用的模块、旧版页面或不再维护的报表用的。新站没有对应模块，字段自然无处安放。此时继续保留它，只会增加录入负担和后续维护成本。
两种解释都会表现为“字段迁不进去”，但处理方向完全相反。前者需要做映射和合并，后者需要做删除或归档。
区分两种解释的证据：看字段有没有下游动作
要判断某个字段属于结构差异还是消费端消失，可以逐个字段追问三个问题，并记录答案：
- 谁写入它：是前台用户提交、后台人员录入，还是系统自动生成？如果只有旧系统自动生成，而新站没有对应生成逻辑，它大概率属于消费端消失。
- 谁读取它：列出所有会读取该字段的页面、接口、导出文件或通知模板。一个都列不出来，就不应进入保留项。
- 不保留会破坏什么：是破坏前台展示、破坏内部审批，还是仅仅让某份历史报表无法还原？只有前两类才构成保留理由。
一个可操作的验证动作是：在迁移前，先给每个候选字段标注“读取方”。标注完成后，把读取方为空的字段单独放一列。如果这一列占字段总数的比例很高，说明主要矛盾是消费端消失，而不是迁移工具能力不足。这个结果会直接改变下一步：不再继续调脚本，而是先和业务方确认哪些历史数据只需归档、不需进入新库。
保留项清单的排序依据：动作优先于完整
确定要保留的字段后，还需要决定优先级。建议按下面的顺序排列，而不是按旧库字段顺序或数据量大小：
- 会阻断流程的字段：缺少它，用户无法提交表单、订单无法流转、权限无法判断。这类字段必须第一批迁入。
- 会改变页面输出的字段：缺少它，列表页、详情页或搜索结果会出现空白或错误。这类字段需要确认新站的模板是否真的使用它。
- 只用于查询和统计的字段：缺少它，历史分析不方便，但不影响当前业务运转。可以延后，或只保留在归档文件中。
- 只用于内部备注的字段：如果新站没有对应的备注展示位置，可以直接放弃，或合并进一个通用的备注字段。
这个排序的实际作用是：当迁移窗口有限时，团队知道先做哪一批。完成第一批后，再验证前台流程是否跑通，跑通后再决定第二批是否值得投入。每一步的结果都会影响下一步的范围，而不是一次性把所有字段都塞进新库。
一个假设例子：合并字段时怎样避免误判
假设旧系统有“客户等级”和“客户标签”两个字段，新站只规划了一个“客户分组”字段。直接合并可能出错，因为两者的读取方不同：等级可能控制折扣，标签可能只用于内部筛选。
此时可以这样处理：先确认新站是否有折扣逻辑。如果有，等级必须保留，并映射到新站的分组或独立字段；如果新站没有折扣逻辑，等级就降级为历史归档。标签则看新站是否有按标签筛选的页面，没有就放弃。这个判断不依赖字段在旧库里的数据量，而依赖新站的实际动作。假设新站确实有折扣逻辑，那么保留等级字段后，下一步要验证的是折扣计算是否使用了正确的值；如果验证发现折扣只对部分客户生效，就说明映射规则还需要补充条件，而不是继续增加字段数量。
决定之后要留下可复查的记录
无论最终保留哪些字段，都建议留下一份简短记录，写明每个被放弃字段的名称、放弃理由和归档位置。这样做不是为了形式，而是为了在后续有人问“某个历史数据为什么查不到”时，能快速回答是归档了、合并了，还是从未迁入。记录中不需要写搜索量或增长比例，只需要写清楚判断依据。当新站上线后如果发现某个流程缺少数据，这份记录能帮助定位是当初判断错误，还是新需求本来就不在旧系统范围内。结尾要说明的是：保留项的决定标准始终是下游动作，而不是旧字段的绝对数量；先确认读取方，再排序，再迁移，才能避免在无法完整迁入时反复返工。
