黄山网站建设：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a979bb0a2f86.html
📄
黄山网站建设：旧系统字段无法完整迁入时怎样决定保留项
先给出结论：当旧系统的字段无法完整迁入新站时，保留项不应按“字段数量”决定，而应按“该字段是否仍驱动一个当前可验证的业务动作”来决定。若一个字段既没有前台展示需求，也没有后台筛选、导出或对接需求，它就应该进入归档而不是硬塞进新结构。下面用一个假设情境把决策过程走一遍。
假设情境：一次迁站中出现的字段冲突
假设黄山一家做本地线路服务的站点要从旧系统换到新系统。旧库里有约四十个自定义字段，其中一部分是早年做活动时加的，比如“集合点备注”“当日领队”“车辆编号”“旧版价格档位”。迁移时发现新系统的内容模型只允许有限的自定义字段，而且部分字段类型不兼容，例如旧系统用自由文本存的“价格档位”，新系统要求结构化数字。
这时常见的错误做法是：把旧字段全部拼成一段说明文字塞进“备注”里，表面上看数据没丢，实际上这些字段再也不能被筛选、排序或导出，等于把可用数据变成了死文本。另一个错误做法是只保留新系统自带的字段，把旧字段直接丢弃，结果运营几个月后发现某些历史订单核对不上。
判断保留项的第一个依据：字段是否还驱动一个动作
把每个待定字段拿出来，问一句：今天还有谁会因为看到这个字段而做出不同动作？
- 如果运营需要按“车辆编号”筛选当天行程，这个字段驱动的是调度动作，应保留并转成可筛选的结构化字段。
- 如果“集合点备注”只在旧活动期间用过，现在没有任何页面展示、没有筛选需求、没有对接需求，它驱动不了任何当前动作，应归档。
- 如果“旧版价格档位”只用于历史订单核对，那它属于历史留痕，应放进只读的历史记录区，而不是混进当前内容模型。
这个判断的关键是“当前可验证”。凡是只能靠回忆说“以后可能有用”的字段，默认不保留，因为迁移成本是现在付出的，而“以后可能有用”永远无法验证。
判断保留项的第二个依据：迁移后能否被检索和导出
保留不等于搬过去。一个字段如果迁入后无法被检索、无法被导出、无法在后台列表里显示，那它对新站没有实际价值。可以用一个简单的验证动作：
- 在新系统里为目标字段建一个临时测试条目，填入示例值。
- 尝试在后台按该字段筛选一次，再尝试导出一次。
- 如果筛选或导出失败，说明这个字段在当前结构里只是装饰，应重新考虑它是进入结构化字段、进入备注文本，还是直接归档。
这一步的结果会直接影响下一步：能筛选能导出的字段进入正式迁移清单；只能展示不能筛选的字段进入展示清单；两者都不满足的进入归档清单。三份清单分开处理，避免在迁移脚本里反复改口径。
一个注明假设的短例子：四十个字段如何收敛到十二个
继续上面的假设情境。把四十个字段按“驱动动作”和“可检索导出”两个维度过一遍后，可能得到这样的分布：十二个字段既驱动当前动作又可检索，进入正式迁移；九个字段只用于前台展示，进入展示清单；七个字段只用于历史核对，进入只读归档；剩下十二个字段两个条件都不满足，直接归档不迁移。
这个例子的数字只是用来说明比较方法，不代表任何真实项目的比例。真正有价值的是收敛过程：每砍掉一个字段，都要能说清它为什么不满足条件，而不是因为“字段太多看着乱”。
决策落地的顺序与需要避开的坑
建议按“先冻结旧库、再定清单、最后迁移”的顺序走。冻结旧库是为了在迁移期间不再产生新字段，否则清单永远定不下来。定清单时让运营和内容维护的人各确认一次，因为只有他们知道哪些字段每天在用。
需要避开的坑有三个：一是把不兼容字段强行转成文本备注，导致后续无法筛选；二是为了省事把历史字段全部丢弃，导致对账困难；三是把归档字段和正式字段放在同一张表里，让后台列表越来越长。归档字段应放在独立的只读区域，并保留原始字段名和原始值，方便日后追溯。
如果迁移后某类历史查询明显变多，说明当初的归档判断可能需要调整，此时再从只读区补迁也不迟；反之，如果某个保留字段上线后长期无人筛选、无人导出，它就是一个可以下一轮清理的信号。保留项不是一次定终身，而是随实际使用情况持续校正的结果。
