网站搭建中，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /af4fee427695.html
📄
网站搭建中，旧系统字段无法完整迁入时怎样决定保留项
先按“字段是否仍影响当前业务动作”分两档：仍被下单、审批、结算、通知或对账依赖的字段，应优先保留并补建映射；只用于历史备注、已停用流程或无人查询的字段，可以归档而不迁入主库。判断依据不是字段数量，而是字段停止迁移后，哪个具体动作会失败、由谁在什么时间发现。
先区分两类字段：驱动动作的与只留痕的
驱动动作的字段一旦缺失，业务流程会在某个节点卡住。例如会员等级字段决定结算折扣，缺失后订单金额可能算错；工单状态字段决定下一步流转，缺失后任务会停在错误队列。留痕字段则相反，它只解释历史，不参与当前判断，比如旧系统里某次手工调整的原因备注。
可核对的证据包括：在旧库中统计该字段最近一段时间是否仍被写入；抽取若干条记录，看它在当前流程里是否被读取。如果写入早已停止、读取只发生在人工翻查，它更接近留痕字段。反过来，写入频率低但每次读取都触发动作的字段，不能因为“数据少”就丢弃。
两种条件下做不同选择
条件一：字段仍被下游系统或人工决策依赖
此时应保留字段，但不必原样照搬。先确认它在旧系统中的含义、取值规则和空值含义，再决定新库中用什么类型承接。若旧字段是自由文本而新流程需要枚举值，可先迁入原始文本，另建一个规范化字段，等映射规则稳定后再切换读取来源。动作上，先在测试库导入一批样本，跑一遍依赖该字段的流程，记录哪一步报错、报错信息指向哪个字段。这个结果决定下一步是补映射表，还是回到业务方确认取值口径。
条件二：字段只服务已停用的流程或无人查询的历史记录
此时可以不迁入主库，改为整表归档，保留只读查询能力。前提是确认没有接口、报表或定时任务仍在引用它。做法是先在旧系统侧记录该字段的最后写入时间和引用它的任务清单，再在归档库中保留原始结构。若之后有人需要，可从归档中按主键回查，而不是让主库长期背负无用字段。这个动作的结果是主库结构更干净，但代价是跨库查询变慢，需要提前约定回查流程。
用可核对的证据区分“没人用”和“暂时没人用”
查询量归零、写入停止、报表不再引用，都不能单独证明字段可以删除。合理解释还包括：统计口径只覆盖了部分入口；字段在月末结算或年度审计时才被读取；某个下游任务因故障暂停，恢复后仍会写入。要区分这些解释，可以交叉核对三件事：旧系统的访问日志是否覆盖全部应用账号；依赖该字段的任务是否处于启用状态；业务方能否说出最近一次使用它的具体场景。三项都指向“不再使用”，归档才更稳妥。
一个注明假设的短例子
假设旧订单表有一个“线下备注”字段，新系统不再提供该输入框。若客服在处理退款时仍会翻查这条备注来判断责任，就属于条件一，应保留为只读字段并接入客服查询页；若该备注只用于已下线的门店自提流程，且近一年无人查询，则属于条件二，可整表归档。这里的数字仅用于说明比较方法，不代表真实统计。
实施时的例外与回退
- 涉及金额、税务、合同或审计的字段，即使当前无人主动查询，也应先保留原值，待合规确认后再决定归档范围。
- 字段之间存在计算关系时，不能只保留结果字段而丢弃来源字段，否则后续无法复核。
- 若迁移窗口很短，可先迁入全部字段，上线后再按实际读取记录分批归档，用真实访问证据替代事前猜测。
- 每次归档前保留一份可回滚的旧库快照，并记录归档字段清单和责任人，避免日后无人能解释某列为何消失。
决定保留项的关键，不是字段看起来重不重要，而是停止迁移后哪个动作会失败、谁能发现、多久能修复。先跑样本、再定映射、最后归档，才能让迁移结果可核对、可回退。
