如何网站制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /720dab61f654.html
📄
如何网站制作：旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“新系统能不能放”决定保留项，而要按“这个字段离开旧系统后，是否仍有人会读、会改、会用来做判断”来决定。把每个字段标成保留、合并、转备注、归档四类，再为每一类写清迁移后的读取位置和责任人。这样做的直接结果是：新库字段数可能减少，但页面不会出现空值，编辑也不会在后台找不到旧信息。
先拿一个页面做样本，而不是先看整张表
旧系统字段多，往往是因为历史上不同栏目共用一张表。此时从整表出发，会陷入“字段名相似但含义不同”的争论。更可行的动作是：挑一个访问量中等、字段覆盖较全的详情页，把它在旧后台的编辑界面截图或抄成清单，逐个字段问三个问题：前台是否显示、编辑是否手动填写、是否被用于筛选或排序。
假设某旧文章表有“来源”“责任编辑”“审核状态”“推荐位”“过期时间”五个字段。若前台只显示来源和责任编辑，审核状态仅用于内部流程，推荐位由运营在另一处设置，过期时间早已无人维护，那么保留项就应收缩为来源和责任编辑，审核状态转为新系统的发布状态，推荐位不迁，过期时间归档。这个假设说明的是判断方法，不是某个真实项目的结论。
保留、合并、转备注、归档：四类各自的代价
保留的代价是迁移脚本要处理空值和长度差异；合并的代价是原字段的区分度消失，以后无法按旧口径筛选；转备注的代价是信息还在但不可检索；归档的代价是编辑日常看不到，需要时得去旧库或导出文件里查。
- 保留：适合前台仍展示、编辑仍会改、且旧值有明确含义的字段。动作是确认新字段类型和默认值，再做一次抽样比对。
- 合并：适合两个字段表达同一件事、只是历史命名不同。动作是先写一条映射规则，再检查合并后是否有值被覆盖。
- 转备注：适合偶尔要查、但不参与展示和筛选的字段。动作是把字段名和值拼成一段可读文本，附在记录末尾。
- 归档：适合已停止维护、且没有业务读取的字段。动作是导出独立文件并记录导出时间，不塞进新库。
这四类不是按字段数量分配，而是按读取行为分配。一个字段如果只有你一个人觉得“以后可能有用”，优先归档而不是保留。
用一条可执行规则处理拿不准的字段
拿不准时，不要投票，做一次小范围验证：取二十条旧记录，把候选字段导出，交给实际会使用它的人，让他们完成一次真实任务，例如核对一篇文章的来源或找出某位编辑处理过的内容。如果他们在没有该字段的情况下仍能完成任务，就归入归档或转备注；如果任务因此中断，就保留。
这个动作的结果会直接影响下一步：保留项进入字段映射表，转备注项进入附加文本模板，归档项进入导出清单。三类分开后，迁移脚本的复杂度会下降，因为不再需要为每个字段都写兼容逻辑。
假设例：一个“旧标签”字段的去留
假设旧系统有一个“标签”字段，存的是逗号分隔的自由文本，新系统使用独立标签表。若直接保留为文本，前台无法按标签聚合；若强行拆成标签表，又会遇到同义、错字和空值。此时可先保留原文本作为备注，同时只把出现频率高、写法稳定的标签写入新标签表。下一步是让编辑在发布时确认标签，而不是在迁移时一次洗净。
迁移后要检查什么，才能确认决定没有留下暗坑
检查不是看字段有没有全部搬过去，而是看三个位置：前台页面是否出现空白或错位；后台编辑是否还能找到旧信息；按旧字段做的筛选或报表是否仍能得出接近的结果。若某个字段被归档，要确认没有页面或流程仍在读取它。若某个字段被合并，要确认合并规则不会把两个不同含义的值压成一个。
如果发现前台出现空值，先判断是字段未迁入，还是模板仍引用旧字段名。前者回到保留项清单补迁，后者改模板引用。这个顺序能避免把模板问题误判为数据问题。迁移完成后的字段清单应保留一份，写明每个旧字段的最终去向，方便以后有人问起时直接查，而不是重新翻旧库。
