优化建站，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3d39fed39b28.html
📄
优化建站，旧系统字段无法完整迁入时怎样决定保留项
先不要按“字段重不重要”排序，而是按“这个字段是否还参与当前页面的可见输出、筛选或后续人工判断”来分。把旧系统导出的字段清单与现有模板、表单、查询条件和编辑流程逐项对照，凡是没有任何下游使用者的字段，即使过去填得很完整，也可以不迁；只要仍影响页面展示、筛选结果或人工核对，就必须保留或找到替代承载方式。
先把字段分成“有下游”和“只存过”两类
拿旧系统里一个具体内容类型作为对象，例如产品资料或文章页。导出全部字段名，再打开当前模板、列表页、筛选组件和编辑后台，逐个问：这个字段有没有被读取。有读取位置的，归入“有下游”；只在旧后台出现过、前台和编辑流程都不再使用的，归入“只存过”。
这一步的关键不是看字段名是否熟悉，而是看它是否改变页面结果。一个字段如果只用于旧版列表页的副标题，而新版列表已经改成摘要，那么它属于“只存过”。相反，一个用于地区筛选的字段即使显示得很隐蔽，只要筛选逻辑还依赖它，就属于“有下游”。
实际动作：为每个字段记录三件事——读取位置、是否参与筛选或排序、是否有人工复查用途。记录完成后，保留项和舍弃项会自然分开，下一步再处理无法直接对应的字段。
无法直接对应的字段，先判断能否合并或降级
字段无法完整迁入，常见原因不是字段本身没价值，而是旧系统允许一个字段承担多种用途。例如一个“备注”字段既写内部说明，又写对用户可见的补充信息。迁入时如果只能保留一个纯文本字段，就要决定它服务谁。
- 如果内容会出现在前台，优先保留为可展示字段，并另设内部备注；
- 如果内容只用于编辑核对，保留为后台字段，不进入前台模板；
- 如果内容同时承担筛选和展示，拆成两个字段，不要指望一个字段继续兼容两种读取方式。
这里的取舍依据是下游读取方式，而不是旧字段的填写量。填写量高只说明过去有人用，不说明现在还需要它参与输出。
用一条假设记录验证保留方案是否成立
假设旧系统里有一条产品记录，包含“型号”“旧分类”“地区”“内部备注”四个字段。新系统只能接收“型号”“地区”“备注”三个字段，旧分类没有对应位置。此时不要直接丢弃旧分类，而是先看它是否还参与前台筛选。
如果旧分类只用于旧版导航，而新版导航已按地区组织，那么旧分类可以并入备注，写成“原分类：××”，供人工复查。如果旧分类仍被某个筛选组件读取，就不能并入备注，必须保留独立字段或改写筛选逻辑。这个假设说明：同一个字段在不同读取条件下，保留方式不同，决定依据始终是下游是否还在用。
保留项确定后，先小批量迁入再复查
不要等全部字段映射完成才验证。先选一小批记录迁入，逐条打开前台页面、筛选结果和编辑后台，确认保留字段是否真的被读取、显示是否正确、筛选是否还能命中。若某个保留字段在前台没有输出，也没有筛选作用，就回到字段清单重新判断它是否应降级为后台备注。
动作与结果：小批量迁入后，如果发现某个字段只出现在后台编辑页，却没有任何前台或筛选读取，就把它从保留项移到备注或舍弃项。这个结果会直接影响下一批迁入的字段范围，避免把无人读取的字段继续带入新系统。
哪些现象不能单独证明保留项选对了
迁入后请求量下降、抓取量变化或某个页面不再被访问，都不能单独证明舍弃某个字段是正确的。请求量下降可能来自入口调整、抓取节奏变化或页面本身不再更新，不一定是字段取舍造成的。要判断保留项是否合理，应回到字段是否有下游读取、是否影响人工复查这两个可核对的依据上。
如果某个字段既没有前台输出，也没有筛选和人工用途，却因为“以后可能有用”被保留，就会增加迁入成本和后续维护负担。更稳妥的做法是把它写入一份待恢复清单，注明原字段名和可能用途，而不是强行塞进当前结构。这样既不影响本次迁入，也为将来确有需要时留下线索。
