通化建站旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /412454a7b7c5.html
📄
通化建站旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段新旧”决定去留，而要按“这个字段是否还在驱动一个可验证的业务动作”来决定。把待迁字段逐个放到一张判断表里，用近三个月的实际数据、页面调用位置和人工操作记录三项证据交叉核对，能通过两项以上的优先保留，只能通过一项的进入观察队列，三项都拿不出的直接舍弃并留档。下面用你手上任意一个旧页面或一张旧数据表作为对象，走一遍可执行流程。
先分清“字段消失”是数据问题还是调用问题
迁移后字段看起来没了，常见有三种互不相同的解释：一是源库本身该字段长期为空；二是字段有值，但新模板没有对应的输出位置；三是字段被合并进了另一个复合字段，只是名称变了。这三种情况的处理方式完全不同，误判会导致你保留一堆永远不显示的死字段，或者删掉仍在被后台调用的关键项。
区分方法很直接。取源系统中该字段最近三个月的记录，统计非空比例；再在旧站前台搜索该字段的典型值，看是否有页面实际渲染出来；最后查一次调用日志或模板引用，确认是否有程序在读取它。三项证据分别对应“有没有数据”“有没有展示”“有没有被程序依赖”。
- 非空比例高、前台可见、有程序引用：核心字段，必须完整迁移并做映射校验。
- 非空比例高、前台不可见、无程序引用：可能是历史录入遗留，先抽样确认是否有人工导出使用。
- 非空比例低、前台可见：说明它只在少数页面起作用，按页面重要性单独判断。
- 三项都弱：进入待删清单，但不要立即物理删除，先停用并记录。
用一张判断表把保留项分成三档
把候选字段列成表，每行一个字段，列固定为：字段名、源系统非空比例、前台调用页面数、是否有导出或人工流程依赖、迁移成本、处置档位。处置档位只设三档，避免讨论发散。
- 保留并映射：有明确展示位置或业务动作依赖，迁移后必须逐条核对数量与抽样值。
- 保留但降级：仍有参考价值，但不再作为前台主展示，可放入详情页折叠区或仅后台可查。
- 停用留档：无展示、无调用、无人工依赖，导出为静态文件保存，新系统不再建同名字段。
这里有一个取舍要点：迁移成本高的字段，如果只是“以后可能有用”，应归入停用留档而不是保留降级。因为“可能有用”无法在迁移后验证，会长期占用维护注意力，而留档文件同样能在需要时找回。
假设例子：一个旧的产品参数表
假设某旧表有“产地备注”字段，近三个月非空比例约三成，前台只在两个老页面出现，后台没有导出流程。按上表它属于保留但降级：迁入详情页折叠区，不进入列表筛选。迁移后抽查二十条，若发现前台展示数量与源库非空数量差异明显，说明映射规则有遗漏，此时应先修正映射再继续迁下一批，而不是先删字段。
哪些“反常结果”其实不代表字段该保留
迁移后有时会出现与直觉相反的现象：某个字段在新站搜索里完全搜不到，但后台记录数却是满的。这通常不是字段重要性的证据，而是索引或展示层没接上。反过来，某字段搜索请求归零，也不能单独证明它无用，可能只是新导航把用户引到了别的入口。判断时要回到“是否有业务动作依赖”，而不是看单一统计的升降。
可核对的动作包括：客服或销售是否按该字段筛选客户、编辑是否按该字段组织栏目、外部对接方是否按该字段取值。只要有一个动作成立，字段就应保留并映射；三个动作都不成立，才考虑停用。这一步的结果会直接决定下一步：保留项进入映射校验，停用项进入导出留档，两条线分开推进，避免边迁边删造成不可回溯。
执行顺序与回退边界
建议按“先冻结字段清单，再迁移，再校验，最后停用”的顺序走，且每一步都保留可回退的中间产物。
- 冻结清单：把三档处置写成一份名单，注明每档的判断依据，改动需记录原因。
- 迁移：先迁保留并映射项，再迁保留但降级项，停用项只导出不建字段。
- 校验：对保留并映射项核对总条数与随机抽样值；对降级项核对详情页是否可查。
- 停用：确认导出文件可打开、可检索后，才在新系统中移除对应入口。
如果校验阶段发现某字段的实际调用量远高于清单预估，应把它从降级档提回映射档，并重跑一次该批次的校验。这个动作会改变后续批次的迁移范围，因此不要等全部迁完再统一修正。
把决定落到一个可交付的结果上
最终你需要的不是一份“感觉该留”的清单，而是一份带档位、带依据、带校验方式的字段处置表，加上一份停用字段的静态导出文件。判断标准始终是业务动作是否依赖，而不是字段看起来是否完整。按这个流程走，保留项有据可查，停用项可回溯，迁移范围也不会因为个别字段的争议而反复扩大。
