益阳网页制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c0c7f8e24fc8.html
📄
益阳网页制作：旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段数量”决定保留谁，而要先判断旧字段属于哪一类——有业务含义、必须继续参与查询或展示的字段，以及只在旧系统内部流转、新站没有对应承接位置的字段。前者优先保留并重建结构，后者可以归档为只读记录，不必强行塞进新页面。判断依据是字段是否影响用户可见信息、订单或线索的完整性，以及后续编辑是否还需要它。
条件一：字段仍参与前台展示或业务查询，优先保留并重建
当旧字段会出现在产品参数、文章属性、联系方式或分类筛选中，它就不只是历史数据，而是新站的信息骨架。此时保留的方式不是原样复制，而是先在新系统中找到对应承载位置：能并入现有字段的合并，需要独立展示的新建字段，只用于筛选的放入分类或标签体系。
实际动作可以这样安排：导出旧数据后，先列出每个字段的“前台出现位置”和“后台编辑频率”。如果某个字段在旧站前台可见，且编辑人员每周仍会改动，就把它列入必留项。完成迁移后，用一条真实记录回填新站，检查前台是否正常显示、后台是否可编辑。这个动作的结果会直接影响下一步：能正常回填的字段进入批量迁移，无法回填的字段转入人工映射清单，而不是直接删除。
假设例子：产品规格字段的取舍
假设旧系统有“材质”“厚度”“适用场景”三个规格字段，新站模板只预留了两个规格位。若“适用场景”同时用于前台筛选，就不能因为模板位不够而丢弃；可以把“材质”和“厚度”合并为一条规格说明，把“适用场景”保留为独立筛选项。这个例子只用于说明比较方法：先看字段是否影响用户筛选，再看它能否被合并表达。
条件二：字段只在旧系统内部流转，转为归档或只读记录
如果旧字段只被旧后台的某个统计页面调用，前台从未展示，新站也没有对应查询需求，那么强行迁入只会增加编辑负担。更合理的做法是保留原始导出文件，在新站中不建立可编辑字段，必要时以只读备注或附件形式留存。这样既不影响新站结构，也避免编辑人员面对一堆无人维护的空字段。
实施时先做一次“调用方排查”：搜索旧模板、旧接口和旧后台页面，确认该字段是否还被其他程序读取。若没有任何前台或接口依赖，就把它标记为归档项。归档后不再进入新站字段列表，但导出文件按业务类型命名并保留。这个动作的结果是缩小迁移范围，让开发和编辑的注意力集中在真正影响使用的字段上。
决定保留项时，用三个问题代替凭感觉勾选
- 用户能否感知？ 前台可见、影响筛选或影响联系方式的字段，保留优先级最高。
- 编辑是否还会维护？ 如果没人会再更新，迁入后只会变成脏数据，适合归档。
- 新站是否有承接位置？ 有对应字段或分类体系的，直接映射；没有的，先判断能否合并，再决定是否新建。
这三个问题的作用是给保留项排序，而不是要求所有字段都找到位置。排序后先迁移第一优先级，再处理可合并项，最后处理归档项。每完成一批，就用一条记录验证前台展示和后台编辑，验证结果决定下一批是否继续。
例外：字段涉及历史凭证或对外承诺时，不适用“简化迁移”
有些字段虽然前台不展示，却可能涉及历史订单凭证、服务期限或对外承诺记录。这类字段不能因为“新站用不到”就删除，而应保留原始数据并注明来源。此时保留项的决定权不在页面模板，而在业务负责人。实际动作是把这类字段单独列出，交由业务方确认留存期限和查看权限，再决定是放入只读归档还是新建内部记录。这个动作的结果会影响后续的数据清理范围：未确认前不删除，确认后再按结论处理。
迁移完成后，还要检查旧字段的“空值率”和“重复率”。如果某个字段大量为空，或同一含义被拆成多个相似字段，说明它本身在旧系统中就缺乏稳定维护。此时即使它曾经重要，也应先合并再迁移，而不是把混乱原样带入新站。空值或重复现象只能说明旧数据质量需要处理，不能单独证明某个字段应该删除。
