遵义网页设计，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cf7855dc52cc.html
📄
遵义网页设计，旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“旧系统里有没有这个字段”决定保留，而要按“新站上线后，这个字段是否仍参与用户判断、业务流转或后续对账”来决定。若字段只服务旧后台的查询习惯，迁入新站往往只会增加维护负担；若字段在订单、会员、预约、售后等链路中仍被读取，就必须保留，并明确由谁在新系统中维护。判断顺序是先看下游依赖，再看历史追溯，最后才看展示需要。
条件一：字段仍被下游流程读取，保留并补齐映射
当旧字段会进入订单、支付、库存、客服工单、短信通知或对账文件时，它就不是展示字段，而是流程字段。这类字段不能只看新页面是否需要显示，而要看新系统里是否还有代码、接口或人工流程会读取它。假设一个旧站用 member_level_code 区分会员等级，新站改成了 member_tier_id，如果订单折扣仍按等级计算，就必须保留等级映射，而不是把旧字段直接删掉。
实际动作是列出字段的下游读取方：先查接口调用、定时任务、导出报表和客服查询脚本，再查页面模板。结果会影响下一步：若发现仍有三个下游读取方，就应在新库中保留等价字段或建立映射表；若只有一个旧页面模板读取，且该页面即将下线，则可以把字段归入归档范围，不必进入新站主表。
例外是字段本身已失效但历史数据仍需追溯。此时可以只保留归档查询，不进入新站日常编辑界面。这样既不影响新站维护，也能在需要时还原旧记录。
条件二：字段只服务旧后台习惯，归档而不迁入主表
有些字段是旧系统为了内部筛选、临时备注或早期统计而加的，新站上线后没有页面、接口或人工流程继续读取。这类字段如果全部迁入，会让新后台表单变长、校验变复杂，编辑人员也容易填错。判断依据不是“以后可能有用”，而是“现在有没有明确的读取方”。
假设旧站有一个 old_banner_order 字段，只用于旧首页轮播排序，新首页已改为按发布时间排序。若没有其他模块读取它，就可以把字段和数据一起归档到只读表，不进入新站主表。实际动作是先冻结旧字段的写入，再观察一个发布周期内是否有人查询；若无人查询，下一步就从新站编辑界面移除，只保留归档导出。
例外是字段涉及财务、合同、售后凭证或监管留存。即使当前没有页面读取，也应保留可查询的归档记录，并明确保存期限和访问权限。此时“不迁入主表”不等于“删除”，而是换一种更安全的存放方式。
用一张依赖清单替代逐字段争论
团队争论某个字段要不要留时，容易陷入“这个字段以前很重要”或“新站看起来不需要”的循环。更有效的做法是给每个争议字段建一行依赖清单，只填可验证的信息：
- 读取方：页面模板、接口、定时任务、人工报表、客服查询脚本。
- 写入方：旧后台、新后台、导入程序、第三方回调。
- 缺失后果：无法下单、无法对账、无法查询历史、仅影响展示。
- 替代方案：能否用新字段推导、能否从归档表查询、能否人工补录。
填完后，保留项自然分成三类：必须进入新站主表的流程字段、只进入归档表的追溯字段、可以删除的无效字段。这个动作的结果会直接影响迁移脚本的范围：主表字段需要写映射和校验，归档字段只需要导出和索引，删除字段则要在迁移报告中记录原因，避免后续被误认为遗漏。
迁移后要验证的是读取结果，不是字段数量
字段迁入完成不等于决策正确。下一步应验证下游读取是否正常：用一条旧数据走完订单、查询或对账流程，确认新字段能返回等价结果。若读取失败，先判断是映射缺失、类型不兼容还是权限问题，再决定补映射还是回退字段。若读取成功但新后台无人维护，则要补默认值或自动生成规则，否则字段会逐渐变成空值。
需要说明的是，抓取量、请求量或某个统计归零，不能单独证明字段可以删除。它也可能是页面未发布、权限未开放或统计口径变化造成的。要结合读取方清单和实际业务流程判断，而不是只看一个指标。
把决定写进迁移记录，减少反复
最终应输出一份字段处置表，逐项写明保留、归档或删除，并标注依据和负责人。对保留项，写清映射规则和维护入口；对归档项，写清查询方式和保存条件；对删除项，写清替代方案和确认人。这样做的结果不是让迁移一次完美，而是让后续出现问题时能快速定位是哪个决定造成的。若新站上线后才发现某个归档字段仍被读取，可以按记录恢复归档查询或补建映射，而不必重新猜测旧系统结构。
