网站开发步骤，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /16bdf53f4ea0.html
📄
网站开发步骤，旧系统字段无法完整迁入时怎样决定保留项
先不要追求字段全量迁移。更可行的做法是：以你手上那份旧系统导出的字段清单为对象，按“新站是否已有等价承载方式、缺失后是否影响核心任务、能否在迁移后补齐”三条标准，把字段分成必留、可替代、可放弃三类，再为每一类写出对应的页面或数据结构动作。这样即使数据不完整、权限不足，也能先完成可执行的最小迁移方案，而不是卡在“等资料齐了再说”。
第一步：把旧字段清单转成可判断的三类标记
打开旧系统导出表或后台字段列表，逐行标注三个问题：这个字段是否直接对应新站的一个展示位置或一项业务判断？如果缺失，用户能否通过其他页面、其他字段或线下方式获得同等信息？迁移后是否还有机会通过人工补录、再次导出或接口补齐？
- 必留：缺失会导致核心流程断掉，例如订单编号、会员等级、已生效的服务期限。
- 可替代：信息仍可用其他方式表达，例如旧站用“备注”记录联系人，新站可用独立联系人字段承载。
- 可放弃：只服务旧后台内部统计、已失效状态或重复记录，且不影响用户任务和业务核对。
标记完成后，先处理必留字段的迁移方式，再为可替代字段写替代规则，最后把可放弃字段列入不迁移说明。这个顺序会直接影响下一步：必留字段决定数据表结构，可替代字段决定编辑流程，放弃字段决定清理范围。
第二步：用“最小可验证页面”确认必留字段是否真的必留
从必留字段中挑一个，假设它叫“服务到期日”，在新站先做一个只包含该字段的测试页面或测试区块。动作是：手工填入一条假设数据，检查页面是否能在列表、详情和后台编辑三处正常读取。结果会出现两种情况。
- 如果三处都能正常读取，说明该字段应进入正式迁移清单，下一步是确定它的来源和更新方式。
- 如果只有详情页能读取，列表和后台编辑无法使用，说明它可能不是必留字段，而是展示型补充信息，应降级为可替代或可放弃。
这个测试不依赖完整旧数据，也不需要数据库全量权限。它只验证字段在新结构里是否真的承担业务判断。不能由此推出“所有必留字段都能一次迁完”，只能说明这个字段值得优先安排。
第三步：区分“字段缺失”和“数据缺失”，避免误判保留项
旧系统字段无法完整迁入，常见原因有两类：一是新站没有对应字段，二是旧数据本身为空或权限不足看不到。两者处理方式不同。
- 字段缺失：旧系统有这一列，新站结构里没有。此时要决定新增字段、合并到已有字段，还是放弃。
- 数据缺失：字段存在但大量为空，或你没有导出权限。此时不要直接删除字段，而应保留结构，先迁移非空部分，并记录补录来源。
判断依据可以看导出文件：如果某一列有表头但多数行为空，属于数据缺失；如果导出文件里根本没有这一列，而旧后台页面能看到，属于字段缺失。对数据缺失的字段，下一步动作是标记“待补录”，而不是立即从保留项中移除。
第四步：给保留项写一条可执行的迁移规则
每确定一个保留项，就写一条规则，格式可以是：来源字段 → 目标字段 → 转换方式 → 缺失时处理。例如假设旧系统有“客户等级”字段，新站用“会员组”承载，转换方式是数值映射，缺失时默认放入“未分组”。
这条规则会决定后续开发动作：如果转换方式需要人工判断，就安排编辑流程；如果可以直接映射，就写入迁移脚本；如果缺失时无法默认，就暂停该字段的迁移，先补资料。规则写得越具体，越不容易在迁移中途反复改结构。
第五步：用“不迁移清单”收尾，而不是用“全量迁移”收尾
当必留、可替代、可放弃三类都标记完，并且每个必留字段都有迁移规则后，输出一份不迁移清单。清单里写清字段名、不迁移原因、是否影响用户任务、后续是否可能补录。这样即使旧系统权限不完整，你也能先上线新站的核心部分，把不迁移项作为后续迭代输入。
需要说明的是，旧系统里某个字段访问量低、导出记录少或近期没有更新，不能单独证明它应该被放弃。它可能只是旧入口深、统计未覆盖或权限限制导致看不到使用情况。保留项决策应回到业务任务和新站承载能力，而不是只看某一项统计是否归零。
