桂林网站开发，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b22196e166ac.html
📄
桂林网站开发，旧系统字段无法完整迁入时怎样决定保留项
先不要按“字段数量”决定保留项，而要先确定每个字段在旧系统里承担的业务动作。把待迁移页面或数据表当作审计对象：逐字段标注它是否参与查询、展示、权限、结算或对外接口。只要某个字段被下游流程读取，即使内容稀疏也应优先保留；只用于内部备注、且没有下游读取的字段，才适合合并或丢弃。这样得到的保留清单，比“新系统能放多少列”更接近真实需要。
先建立字段证据表，而不是直接勾选保留
打开旧系统后台的字段管理页或数据库表结构，复制出字段名、类型、是否必填、默认值、最近一次被读取的位置。对每个字段补三列：谁在用、用在哪一步、缺了会怎样。例如一个“客户来源备注”字段，如果只在旧后台详情页显示，没有导出、筛选或接口调用，它的迁移优先级就低；如果它被用于生成对账单或推送到外部系统，则必须进入保留项。
这里有一个常见反常现象：字段内容为空的比例很高，团队就想直接删掉。但空值多不等于字段无用。它可能是因为旧系统没有强制填写，而不是业务不需要。此时应查该字段是否出现在查询条件、导出模板或接口返回中。若出现过，保留字段结构并允许空值，比删除后让下游报错更稳妥。
用“读取路径”区分保留、合并与丢弃
把每个字段的读取路径写清楚，通常只有三类：
- 保留：被页面展示、被筛选、被导出、被接口读取，或被权限规则引用。这类字段应在新系统中保持可读，必要时可改类型但不可丢语义。
- 合并：多个字段只在同一展示位置出现，且没有独立查询或统计需求。例如旧系统把“备注一”“备注二”分开存，但前台始终拼接展示，可以合并为一个长文本字段，同时保留原字段名到新字段的映射记录。
- 丢弃：没有下游读取、没有历史查询需求、且内容可由其他字段推导。丢弃前应导出原始值留档，而不是直接删除旧表。
动作上，先对每个字段打上这三类标签，再统计各类数量。如果“保留”类字段超过新系统单表可接受范围，不要硬塞，而应把低频但必须保留的字段拆到扩展表或键值存储中。这个动作的结果会直接影响下一步：拆分后，迁移脚本需要多一次关联写入，测试重点也要从“字段是否存在”转为“关联查询是否返回正确结果”。
遇到类型不兼容时，先做语义映射再决定取舍
旧系统字段无法迁入，很多时候不是字段本身多余，而是类型不兼容。例如旧系统用自由文本存“面积”，新系统要求数值加单位；旧系统用多选文本存“服务区域”，新系统要求关联地区表。此时不要因为转换麻烦就删除字段，而应判断该字段是否参与计算或筛选。
假设一个桂林本地服务类网站，旧系统有一个“可服务区域”文本字段，内容形如“秀峰区、象山区”。新系统要求地区为结构化选项。若该字段只用于详情页展示，可以保留原文并另存一份结构化结果；若它被用于筛选或匹配，则必须完成结构化映射，否则筛选结果会漏掉部分记录。这里的假设是：该字段确实被下游筛选读取。若没有读取，保留原文即可，不必强行拆成地区表。
类型转换后要核对两件事：空值是否被错误转成默认值，以及超出新类型范围的值是否被截断。截断会静默丢数据，比迁移失败更难发现。
用一组可核对的证据判断“删了也没事”是否成立
团队常说“这个字段没人用”，但需要证据。可以按以下顺序核对：
- 在旧系统代码或模板中搜索字段名，确认是否有读取点。
- 在导出记录、接口日志或下游系统中搜索字段名，确认是否被外部消费。
- 询问实际使用旧后台的岗位，确认是否有手工依赖，例如复制该字段到表格。
- 若以上都没有，再检查该字段是否被权限、统计或报表引用。
如果搜索请求量、抓取量或某个统计值归零，不能单独证明该字段可以删除。归零还可能是因为统计口径变化、日志未采集、访问被限制或该功能已下线但数据仍有历史价值。需要结合读取路径和岗位确认，才能下结论。
形成可执行的保留清单与迁移顺序
最终清单应包含：字段名、旧类型、新类型、处理方式、映射规则、验证方式。迁移顺序建议先迁保留类字段，再迁合并类字段，最后处理丢弃类字段的留档。每完成一类，就用旧系统的一条真实记录做对照，检查新系统读取结果是否一致。
如果保留项过多导致新系统查询变慢，优先把不参与筛选的字段移到扩展表，而不是删除。这样既保住历史数据，也不影响主流程性能。下一步的测试重点应放在关联读取和空值处理上，而不是只看字段是否出现在页面上。
