一站式建站旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3258b39765ef.html
📄
一站式建站旧系统字段无法完整迁入时怎样决定保留项
结论先行：当旧系统字段无法完整迁入时，默认应保留“前台可见、且新系统有明确承接位置”的字段；其余字段先冻结在只读归档里，而不是硬塞进新库。这个判断只在样本量小、字段语义清晰时成立；一旦出现同名不同义或跨表拼接字段，就不能照搬。
先判断字段属于哪一类，再决定去留
把待迁移字段分成三类，处理方式不同：
- 展示字段：标题、正文、主图、分类名。这类字段通常必须保留，因为直接影响前台可读性。
- 关联字段：作者、标签、关联产品。要看新系统是否已有等价结构，有则映射，没有则先降级为文本。
- 过程字段：审核状态、旧版本号、内部备注。多数不必进新库，但应留在归档表里备查。
实际操作时，先导出旧表结构，给每个字段标注“前台是否可见”和“新系统是否有对应字段”。两个条件都满足的进入首批迁移清单；只满足一个的先挂起。这样做的结果是：迁移范围缩小，但不会在改版后才发现前台缺内容。
一个会让结论失效的反例
假设旧系统里有一个名为“区域”的字段，前台显示为“华东”，但数据库里存的是数字 3，真正的文字在另一张字典表里。单看一个样本，把 3 直接迁过去似乎没问题；规模化后，新系统没有对应字典，前台就会出现一串数字。
这就是不能照搬的边界：字段名相同不等于语义相同。当字段依赖旧系统的字典表、枚举值或拼接逻辑时，保留项判断必须回到数据本身，而不是看字段名。此时正确做法是先还原字典关系，再决定是保留数字加一张映射表，还是把文字直接写入新字段。
用“影响面”而不是“数量”排序
面对几十个待定字段，按数量排优先级容易误判。更可靠的做法是估算每个字段的影响面：
- 该字段出现在多少个前台页面模板里；
- 缺失后是否导致页面无法正常展示；
- 是否有其他字段可以临时替代。
影响面大的字段优先保留，即使它看起来只是“备注”。影响面小的字段可以延后，哪怕它数量多。这个排序的结果会直接影响下一步：优先保留项需要安排映射和校验，延后项只需登记在归档清单中。
给出一个可执行的决策顺序
把上面的判断收束成一个动作序列：
- 先冻结旧库，停止写入，导出结构与样本数据。
- 按“前台可见 + 新系统有承接位置”筛出首批保留项。
- 对依赖字典或拼接的字段，单独还原语义后再决定。
- 其余字段写入只读归档表，记录原字段名、原表名和样本值。
做完这一步，下一步不是继续迁字段，而是拿首批保留项跑一遍前台页面，确认没有空白或错位。如果前台正常，再处理第二批；如果出现异常，回到字段语义判断，而不是扩大迁移范围。
保留项定下来之后要做什么
保留项确定后，立刻做两件事：一是为每个保留字段写一条映射说明，注明来源表和目标字段；二是把归档表放在可查询的位置，供后续人工核对。这样即使某个字段暂时没迁，也能在需要时找回原值。整个过程不依赖某个特定系统是否提供自动迁移功能，只依赖字段语义是否被正确理解。
