庆阳网站开发，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /45bb978ca191.html
📄
庆阳网站开发，旧系统字段无法完整迁入时怎样决定保留项
先定一条硬规则：新站上线后必须能独立完成业务闭环的字段优先保留，只是让历史页面看起来更完整的字段可以暂缓。字段能否迁入，不取决于旧库里有没有值，而取决于它是否参与当前的表单提交、订单流转、权限判断或对外展示承诺。把这条规则写进迁移清单，再让业务、编辑和技术三方分别标注，分歧就会从“我觉得重要”变成“它对应哪一步动作”。
两种条件对应两种取舍
当旧字段仍被前台表单、接口或人工流程读取时，它属于运行依赖，应进入第一批迁移。判断依据是：去掉它之后，现有用户能否完成一次完整提交或查询。若不能，就保留，并在新库中给出明确类型和必填规则。实施动作是给每个字段标注来源表、目标表、是否允许空值、由谁负责核对。核对结果直接决定下一步：有值且必填的字段先迁，有值但选填的字段可以后迁，无值又无流程依赖的字段进入待废弃清单。
当旧字段只出现在历史详情页、旧版后台或已停用的统计报表中时，它属于展示遗留，不必强求结构完整。此时可保留其文本快照，或只保留在新站不参与查询的归档表里。若强行把这类字段并入主表，常见结果是新表单出现大量无意义空项，编辑每次发布都要面对不该填的输入框。选择快照还是归档，取决于是否还需要按该字段筛选：需要筛选就建独立归档表，不需要筛选就存成页面附注。
把分歧转成可核对的字段清单
多个角色对同一字段的理解经常不同。运营认为“客户来源”必须保留，技术认为它只是旧表单的一个下拉项，编辑则觉得它影响文章归类。处理方式不是开会争论，而是把字段拆成四个可核对项：字段名、当前使用位置、缺失后的业务后果、责任人。任何一项填不出来，就说明该字段暂时没有保留依据。
- 使用位置：前台表单、后台列表、接口返回、历史页面、统计导出，至少要指出一个具体位置。
- 缺失后果：无法提交、无法筛选、无法对账、页面显示空白，四类后果对应不同优先级。
- 数据形态：纯文本、枚举值、关联编号、附件路径。形态不同，迁移成本不同。
- 责任人：谁能在上线后确认该字段是否正常，谁就参与验收。
完成这张清单后，先做一次小范围试迁：只选二十条真实旧记录，按清单逐字段对照。若试迁后发现某字段在新站没有任何读取入口，就把它从第一批移出。这个动作的结果会影响后续排期：读取入口多的字段先做映射，读取入口少的字段合并到归档批次。
例外：字段本身没价值，但它的值有约束
有些字段不能因为“没人看”就删除，因为它的值参与唯一性判断或关联关系。例如旧系统中的区域编号，前台可能不再展示，但订单归属、配送范围或权限范围仍可能依赖它。此时保留的不是字段的显示位置，而是它的取值约束。实施动作是把该字段转为内部编码，不出现在编辑界面，只在新站逻辑中参与判断。
假设一个旧站有“客户等级”字段，新站不再展示等级，但历史折扣记录按等级计算。若直接删除，旧订单的折扣依据就断了。此时应保留等级编码，并把它挂在订单归档记录上，而不是重新放回客户主表。这个例子只说明判断方法：先看值是否被其他记录引用，再看它是否需要被人工编辑。两者答案不同，保留方式也不同。
决定保留项之后，先验证再冻结
字段清单确定后，不要立刻冻结全部结构。先让新站跑通三条路径：新用户提交、老用户查询、后台编辑发布。每条路径都检查保留字段是否出现、是否可空、是否影响下一步。若某字段在三条路径中都不出现，就把它移入观察区，而不是继续留在主表。观察区的字段不参与新表单，只保留只读查询，等一个完整业务周期后再决定是否彻底归档。
最后要接受一个现实：旧系统字段无法完整迁入时，不存在让所有人都满意的保留方案。能成立的做法是让每个保留项都能回答“它支撑哪一步动作”，让每个放弃项都能回答“它缺失后由什么替代”。把这两个答案写进迁移记录，后续换人维护时才有依据继续判断，而不是重新吵一遍。
