快速建站：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /60e97720dcab.html
📄
快速建站：旧系统字段无法完整迁入时怎样决定保留项
先判断字段是否影响可逆操作：如果旧字段参与登录、订单状态或对外链接，就应保留或建立映射；如果只用于后台备注、统计标签或历史展示，且新站有替代记录方式，可以先不迁。缺少完整数据或权限时，仍可先导出字段清单、抽样比对、标记依赖，再决定保留、转换或暂缓，不能因为导出失败就认定字段无价值，也不能因为字段能导出就认定必须全部保留。
条件一：字段影响前台行为时，优先保留并做映射
判断依据不是字段数量，而是它是否改变用户看到的内容或能执行的动作。比如旧系统里“会员等级”决定价格显示，“文章状态”决定页面是否公开，“跳转地址”决定旧链接能否继续访问。这类字段一旦缺失，前台会出现错误价格、死链或权限混乱。
可执行的最小动作是：先列出字段名、旧值示例、新系统对应字段、缺失后的表现。若新系统没有同名字段，可以建立一张映射表，把旧值转成新值，例如旧状态“1/2/3”对应新状态“草稿/公开/归档”。映射表先在小范围数据上验证，确认前台行为一致后，再扩大到全量迁移。
这一步的结果会直接影响下一步：如果映射后仍出现权限或价格错误，就应暂停全量导入，回到字段清单补充例外规则；如果抽样验证通过，才进入批量处理。
条件二：字段只服务历史记录时，可以暂缓或转成只读附件
有些字段不参与前台逻辑，只用于运营备注、旧订单说明或早期统计。缺少完整数据或权限时，不必为了“完整”而阻塞上线。更稳妥的做法是把这类字段导出为只读文件，附在对应记录旁，而不是强行塞进新系统的主表。
选择依据是：该字段是否会被新流程继续写入。如果不会继续写入，只读附件足够；如果还会被编辑或查询，就应保留为独立字段，避免后续再次迁移。假设一个旧系统里有“客服备注”字段，新站没有对应输入框，但运营偶尔需要查历史备注，那么可以保留一个只读备注区，不参与新表单提交。
动作与结果：先导出备注字段并抽样核对，若发现备注中包含影响售后判断的内容，就把它标记为“需保留”；若只是重复的流程说明，就标记为“可归档”。这个标记结果决定它是进入新库还是进入附件库。
缺少权限时，用字段依赖图代替完整导出
没有数据库权限，不代表无法决定保留项。可以从页面、接口返回、导出文件和后台截图反向整理字段依赖。具体做法是：选一条典型记录，记录它在哪些页面出现、由哪个动作触发、缺失后哪个页面会报错。把字段与页面、动作连成依赖图。
依赖图能区分三种情况：一是字段缺失会导致页面无法打开，应优先保留；二是字段缺失只影响某条提示，可暂缓；三是字段缺失没有任何可见影响，可先不迁。这个判断不依赖完整数据，但结论有边界：依赖图只能说明当前观察到的路径，不能证明所有隐藏逻辑都已覆盖。因此，缺少权限时仍应保留原始导出文件或截图，供后续核对。
实施时先做小批量试迁，再决定全量策略
无论选择保留还是暂缓，都建议先用一小批记录试迁。试迁范围应包含边界值，例如最长文本、空值、特殊字符、已删除状态。试迁后检查三件事：前台是否正常显示，后台是否还能编辑，旧链接是否还能访问或正确跳转。
如果试迁发现某字段导致导入中断，先不要删除该字段，而是把它拆成“必填部分”和“可空部分”。必填部分进入主表，可空部分进入附件或日志。这样既能继续上线，又不会丢失判断依据。试迁结果若显示字段冲突集中在少数记录，就针对这些记录做人工映射；若冲突普遍存在，就应重新评估新系统字段设计，而不是反复清洗数据。
例外：字段涉及法律、财务或对外承诺时，不适用暂缓
如果字段与合同金额、发票信息、退款记录、版权声明或对外承诺有关，即使当前没有前台展示，也不应简单归档。此时应保留原始值、迁移时间和操作人，并确保新系统能追溯。缺少权限时，至少应导出只读副本并记录来源，不能以“新站用不到”为由丢弃。
另一个例外是旧字段被外部系统调用。比如旧站接口把某个字段传给订单系统或邮件系统，前台看不到，但停用后会影响下游。判断方法是查接口日志或调用方清单；若无法确认，就先把字段保留为兼容字段，观察一段时间后再决定是否下线。这个动作的结果会决定旧接口能否安全停用，而不是仅凭前台页面是否正常来判断。
