宿迁网站开发，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8520381e32c7.html
📄
宿迁网站开发，旧系统字段无法完整迁入时怎样决定保留项
先给结论：字段保留与否，不取决于旧库里有多少条数据，而取决于这个字段在新站上是否还有明确的展示位置、录入责任人和使用场景。三者缺一，即使数据完整也应列入舍弃候选；三者齐备但历史值残缺，则应保留字段结构、清洗后部分迁入，而不是整列丢弃。下面用两种条件展开判断，并给出可执行的动作和例外。
条件一：字段有承接页面和后续录入人，优先保留并部分迁入
判断一个字段该不该留，先看新站有没有它的落点。比如旧系统的“客户来源备注”字段，如果新站的详情页、列表筛选或后台检索里根本不会出现，那它迁进来也只是躺在数据库里；反过来，如果新站的表单、详情页或导出报表需要它，就属于有承接页面。
再看录入责任人。字段迁入后，后续由谁填写、谁维护、多久更新一次，必须能说清楚。没有责任人的字段会迅速变成空列，迁入的历史数据也很快过期。具体动作是：把候选字段逐一对照新站的原型页面和表单，能指到具体位置的打勾，指不到的放入待定区。
这个动作的结果会直接影响下一步：打勾的字段进入清洗流程，待定区的字段先冻结，不急着删，也不急着迁。这里有一种与直觉相反的情况值得注意——旧系统里数据量最大的字段，往往不是最该保留的。数据多只说明过去录得多，不说明现在还有人用。要区分这两种解释，可以抽查最近一段时间的记录，看该字段是否仍在被填写；如果近期新增记录里它长期为空，那“数据量大”更可能是历史遗留，而不是持续需求。
条件二：字段无展示位置或已有替代来源，整列舍弃更省成本
当字段在新站既没有页面承接，其信息又已经由别的字段覆盖时，保留它只会增加迁移清洗量和后续维护负担。例如旧系统单独存了一个“联系人职务”，而新站的联系人模块已经用标签或分类承担了同样的区分作用，那么重复保留两处只会让录入人不知道该填哪个。
舍弃不等于直接删库。稳妥的动作是先导出该字段的完整备份，记录字段名、类型和大致记录数，再在新站上线后观察一段时间。如果确实没有任何页面、报表或检索需要它，就可以确认舍弃；如果中途发现遗漏，还能从备份里补回。这个动作的结果是：舍弃决策变得可回退，而不是一次性不可逆。
需要提醒的是，请求量、抓取量或某张表的行数归零，不能单独证明舍弃正确。这些现象还有别的合理解释，比如统计口径变了、采集脚本停了、页面暂时没被访问。判断依据仍应回到展示位置、责任人和使用场景这三条。
用一组可核对的证据区分“该留”和“该舍”
与其凭印象争论，不如把证据摆出来。可以按下面的清单逐项核对，每一项都要求能指出具体位置或具体人：
- 该字段在新站的原型页面或表单里，能否指出确切位置；
- 该字段是否被列表筛选、导出报表或检索功能引用；
- 迁入后由哪个角色负责后续填写和更新；
- 最近一段时间的新增记录里，该字段的实际填写情况；
- 是否已有其他字段或标签覆盖了同样的信息。
前三条指向“保留”，第四条用于判断历史值是否值得清洗，第五条指向“舍弃”。如果前三条成立、第四条显示近期仍有填写，就保留并完整迁入；如果前三条成立、第四条显示近期基本为空，就保留字段结构但只迁入可清洗的部分；如果第五条成立，无论数据量多大都优先舍弃。
一个注明假设的短例子
假设某旧系统有“备注”和“来源渠道”两个字段，备注记录数远多于来源渠道。按数据量直觉，似乎该优先保备注。但核对后发现：新站详情页没有备注的展示位置，也没有人负责后续填写；而来源渠道会被用于列表筛选和月度导出，且运营岗明确会继续录入。按上面的证据清单，结论应是舍弃备注、保留来源渠道，并把备注整列备份留存。这个例子只用于说明比较方法，不代表任何真实项目的数据情况。
实施顺序与例外处理
确定保留项后，建议按这个顺序推进：先冻结字段清单，再对保留字段做值域和格式清洗，然后分批迁入并抽样核对，最后在新站上线后回看一次实际使用情况。每一步的结果都会影响下一步——清洗中发现大量无法解析的值，就要回头确认该字段是否真的还有展示位置；抽样核对发现对不上，就要先解决映射规则再继续迁入。
例外情况主要有两类。一类是合规或存档要求必须原样保留的字段，即使新站不展示也不能删，此时应单独归档而不是混入业务表。另一类是字段本身保留、但值需要重新编码，比如旧系统的分类编号在新站换了体系，这时保留字段结构、重新映射取值即可，不必连历史编号一起搬。把这两类例外提前标出来，可以避免在迁移中途反复改方案。
