网站建设规划：旧系统字段迁不完整时先冻结哪一批
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /590f7f0be78b.html
📄
网站建设规划：旧系统字段迁不完整时先冻结哪一批
先冻结“有独立检索价值且新系统有承载位置”的字段，其余字段进入观察池，而不是按旧表结构整列搬迁。判断依据不是字段数量，而是每个字段能否在新页面类型中找到落点，以及它是否参与站内检索、筛选或结构化展示。迁移前先拿一张旧表做样本，逐字段标注去向，再决定保留、合并还是丢弃。
先判断字段是内容还是附属信息
旧系统的字段往往混着两类东西：一类是页面正文的一部分，比如产品参数、服务范围、适用人群；另一类是记录管理用的附属信息，比如内部编号、录入人、旧分类路径。前者迁入后用户能直接看到，后者迁入后通常只增加维护负担。
可执行动作：打开旧系统的一条记录，把每个字段按“用户可见”“仅后台可见”“两者都有”标记。结果会影响下一步——只有“用户可见”或“两者都有”的字段才进入保留候选；“仅后台可见”的字段先不迁，除非新系统有对应的审核或追溯需求。
用三个问题区分保留项和可丢弃项
面对一个具体字段，按顺序问：
- 这个字段是否影响用户做决定？ 例如价格区间、规格、适用条件会影响，录入时间通常不影响。
- 新系统有没有对应的展示位置？ 如果新页面类型里没有这个区域，强行保留只会变成无人维护的孤儿数据。
- 缺失它会不会造成内容不完整？ 如果删掉后正文仍然成立，它可以进入观察池；如果删掉后页面失去核心信息，就必须保留。
假设一个旧产品表有“型号”“尺寸”“旧站栏目路径”“录入人”四个字段。按上述顺序，“型号”和“尺寸”进入保留项，“旧站栏目路径”可用于重定向映射但不作为页面展示字段，“录入人”先丢弃。这个假设只说明比较方法，不代表任何真实系统的迁移结果。
把保留项写成新系统的字段映射表
决定保留哪些字段后，不要直接开始导入。先写一张映射表，每行包含旧字段名、新字段名、是否必填、缺失时的处理方式。映射表的作用是暴露冲突：两个旧字段可能对应同一个新字段，或者一个旧字段在新系统里需要拆成两个。
实际动作：拿十条样本记录填这张表。如果超过三条记录出现同一字段无法映射，说明问题不在数据，而在新页面类型设计。这时应先调整新系统的字段结构，再继续迁移。反之，如果只是个别记录缺失，可以按“缺失时留空并标记待补”处理，不阻塞整体迁移。
出现“迁移后检索量下降”时先别归因于字段丢失
一个反常现象是：字段迁完后，某些旧页面的站内检索或外部访问下降。此时不能直接断定是丢字段造成的。还有几种合理解释：旧 URL 没有正确对应新地址；新页面的标题和摘要没有继承旧字段；旧字段虽然保留，但被放进了折叠区域或图片中，检索系统无法读取。
区分方法：先抽查下降页面在新系统中的实际输出，确认保留字段是否出现在 HTML 文本里，而不是只存在于后台。再检查旧地址是否指向了内容最接近的新页面。只有排除了地址和输出位置问题，才回到字段保留决策本身。请求量或抓取量归零不能单独证明某个字段该留还是该删，它只能提示需要进一步核对。
给无法立即决定的字段设一个退出条件
总有一些字段既不是明显有用，也不是明显无用。对这类字段，不要无限期保留，而是给它一个退出条件：例如“连续两次内容更新都没有被编辑使用，就删除”或“新页面模板确定后仍无展示位置，就转为后台备注”。
这样做的结果是：迁移不再依赖一次性的完美判断，而是把不确定项变成后续可执行的动作。下一步是确定谁负责在什么时间点检查这些条件，并把检查结果写回映射表，避免同一批字段在每次改版时被反复讨论。
