长治网页制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f6a72f56f05e.html
📄
长治网页制作：旧系统字段无法完整迁入时怎样决定保留项
先给结论：字段能否保留，不取决于它在新系统里有没有对应位置，而取决于它是否仍被真实业务读取或写入。如果某个字段只被旧页面展示、没有查询条件、没有下游接口、也没有人维护，优先退出；如果它参与筛选、统计、权限判断或对外承诺，即使新系统没有同名字段，也应先改写为新的承载方式再迁移。判断顺序是：先看调用关系，再看数据质量，最后看迁移成本。
先判断字段是“活数据”还是“历史痕迹”
旧系统里字段多，不等于都需要带走。把字段分成三类，处理方式会清晰很多。
- 被程序读取：出现在查询条件、排序、权限判断、接口返回或页面模板中。这类字段即使命名混乱，也要优先保留或改写。
- 只被人工查看：后台列表里显示，但没有任何程序依赖。可以只保留最近一段时间的数据，或转为备注字段。
- 无人使用：既没有查询入口，也没有维护记录，导出后长期无人打开。可以考虑退出，但退出前要留下归档说明。
一个实际动作是：把旧系统的表结构导出，逐个字段搜索代码库和模板目录。搜索结果为零，只能说明当前代码没有直接引用，不能直接证明字段无用，因为还可能被定时任务、报表脚本或外部接口间接使用。因此还要查一遍计划任务和接口文档，再决定是否进入退出清单。这个动作的结果会直接影响下一步：有调用关系的字段进入改写流程，没有调用关系的字段才进入归档或删除流程。
保留、改写、退出各自成立的前提
保留适用于字段仍有明确业务含义，且新系统有稳定承载位置。前提是数据质量可接受：空值比例、格式一致性、重复情况在可处理范围内。如果旧字段里混着多种格式，直接搬过去只会把问题带进新系统。
改写适用于字段价值还在，但旧结构已经不适合新模型。例如旧系统用单个文本字段存地址，新系统拆成省市区和详细地址。这时不是简单映射，而是要先定义拆分规则，再处理无法拆分的记录。改写的前提是业务方能确认新结构能满足后续查询和展示，否则改完还要再改一次。
退出适用于字段既无调用关系，也无合规保留要求，且迁移成本高于保留价值。退出的前提是已经完成归档，并且相关干系人确认不再需要在线访问。退出不是删除历史，而是把在线依赖降为零。
三种选择并不互斥。一个旧字段可以部分保留、部分改写、部分退出，关键是把规则写清楚，而不是在迁移脚本里临时判断。
用一组可区分的原因证据来定取舍
遇到争议字段时，不要靠感觉投票。可以要求提出保留的一方给出以下证据中的至少一项：
- 该字段出现在某个仍在使用的查询或报表中，并能指出具体入口。
- 该字段被外部系统通过接口读取，并能说明调用方和调用频率。
- 该字段涉及对外承诺、合同记录或审计要求，并能说明保留期限。
如果三项都拿不出来，字段进入退出候选。反过来，如果某项证据成立，就不能因为“新系统没有同名字段”而直接丢弃，而应进入改写评估。这里要注意：请求量、抓取量或某个统计指标归零，不能单独证明字段可以退出，因为还可能是采集方式变化、入口调整或统计口径改变造成的。需要结合调用日志和业务确认一起看。
一个假设的迁移判断例子
假设旧系统有一个“客户来源备注”字段，新系统的客户表没有对应列。可以这样比较：如果该字段只出现在旧后台详情页，没有任何筛选和报表使用，且最近一段时间没有新增内容，那么保留它的在线价值很低，可以导出归档后退出。如果该字段被销售报表按来源分组统计，那么即使新系统没有同名字段，也应先在新模型中增加一个受控的来源分类字段，再把旧备注按规则映射过去。
这个例子的重点不是结论，而是判断路径：先确认调用关系，再确认数据质量，最后确认迁移成本。假设调用关系成立而数据质量很差，正确动作也不是原样搬入，而是先清洗再映射。清洗结果会决定映射规则是否需要人工复核，人工复核的工作量又会决定是否值得在本次迁移中完成，还是分批处理。
把决定写成可执行的迁移规则
决定保留项之后，需要把结论落成规则，而不是留在会议记录里。每条规则至少包含：旧字段名、处理方式、目标位置、转换逻辑、异常处理方式、负责人。对于改写字，还要注明无法自动转换时进入人工队列；对于退出项，要注明归档位置和保留期限。
执行时先跑一遍只读比对：统计每个字段的非空数量、格式异常数量和映射失败数量。比对结果如果显示某个字段映射失败率很高，应先停下来检查规则，而不是继续导入。导入完成后，再抽查一部分记录，确认新系统中的字段能被正确读取和展示。只有这一步通过，才能把旧系统的对应入口下线。整个顺序是：定规则、跑比对、处理异常、抽查验证、再下线，任何一步的结果异常，都应回到上一步调整，而不是跳过。
