广西网站开发：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /59674effc6bd.html
📄
广西网站开发：旧系统字段无法完整迁入时怎样决定保留项
先给一个可执行的结论：当旧库字段无法完整迁入新站时，不要按“字段新旧”或“数据量大小”决定去留，而要先确认每个字段是否仍在支撑一个可验证的业务动作。若某字段只被历史报表引用、没有任何前台或流程依赖，即使数据量很大也可以不迁；反之，一个只有几十条记录的字段，只要还参与下单、审批或对账，就必须保留并单独设计映射。下面针对广西本地项目常见的迁移取舍展开。
先判断字段是否还在业务链上，而不是看它有多旧
旧系统往往积累了多年字段，其中一部分是早期试验留下的，一部分是后来业务扩展补上的。判断保留项时，可以按三个问题逐一过筛：
- 这个字段被谁写入、被谁读取？如果只有后台管理员手工填过，前台从未展示，也没有接口调用，它大概率是历史包袱。
- 它是否参与金额、权限或状态流转？涉及价格、库存、审核状态、会员等级的字段，即使记录很少，也不能直接丢弃。
- 它是否被外部系统引用？如果旧站曾向财务、短信或物流系统推送过该字段，迁移前要先确认对方是否仍按旧结构接收。
在广西的网站开发项目中，常见情况是旧库里有“备注”“来源渠道”“业务员编号”这类字段，看似零散，但可能仍被线下对账使用。此时正确动作不是先删，而是导出该字段最近一段时间的非空记录，交给业务方确认是否仍在使用。若业务方确认已停用，再标记为不迁；若仍在使用，则进入下一步映射设计。
无法完整迁入时，保留项要按“可重建”和“不可重建”分开
字段无法完整迁入，通常有两种原因：一是新库结构不支持旧字段类型，二是旧数据本身存在大量空值或格式混乱。此时可以把保留项分成两类：
- 不可重建字段：例如合同编号、原始订单号、外部对账流水号。这类字段一旦丢失，后续无法通过其他数据推导出来，必须优先保留，哪怕需要在新库中单独建一张映射表。
- 可重建字段：例如由订单金额和税率计算出的含税价、由注册时间推导出的会员年限。这类字段可以在新站中按规则重新生成，不必强行迁移原始值。
假设一个旧站有“客户等级”字段，但新站已经改为按累计消费自动计算等级。此时旧等级值属于可重建字段，可以只迁移累计消费金额，等级由新规则生成。但如果旧等级曾用于人工审批折扣，且新规则无法覆盖历史折扣，那么这个字段就变成不可重建，需要保留原始值并注明来源。
一个反例：字段本身不重要，但它锁定了历史权限
有一种情况会让上面的结论失效：字段看起来只是普通标记，却承担了权限判断。比如旧系统中“是否已审核”字段不仅控制前台展示，还决定某些用户能否下载附件。如果只迁移附件表而丢掉该字段，新站可能对所有用户开放下载，造成权限泄露。此时不能按“字段是否被前台读取”来判断，而要检查旧代码中所有引用该字段的条件分支。动作上，可以搜索旧系统代码和数据库视图，列出该字段参与过的判断逻辑；若发现任何权限、状态或流程分支，就应把它列为不可重建字段，并在新站中设计对应的权限规则，而不是简单复制一个布尔值。
决定保留项后，下一步是写映射表并做一次小范围回灌验证
确定保留项后，不要直接全量迁移。先写一份字段映射表，至少包含：旧字段名、新字段名、是否必填、转换规则、空值处理方式。然后选取一小批数据回灌到新站，检查三件事：前台展示是否正常、后台流程是否走通、外部接口是否报错。如果回灌中发现某个保留字段在新库中无法写入，就回到映射表调整规则，而不是临时在代码里写死。这个动作的结果会直接影响下一步：只有小范围回灌通过，才值得安排全量迁移；否则应先修复映射规则，避免全量迁移后产生难以回滚的脏数据。
哪些字段可以明确不迁
在满足以下条件时，可以考虑不迁：该字段最近一段时间没有新增非空值；没有任何前台页面、后台流程或外部接口引用它；业务方书面确认不再需要历史值。三者同时成立时，不迁的风险较低。但只要有一条不成立，就应保留或至少保留只读备份，而不是直接删除。对于广西网站开发中常见的旧站迁移，保留一份旧库只读副本通常比在迁移中反复争论更省事，也方便后续核对。
