商洛网站制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1460adafec70.html
📄
商洛网站制作：旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段在旧系统里重不重要”决定去留，而要按“字段在新站上有没有承接页面、承接动作和后续维护人”决定。对每个字段做一次三分法——能落到新页面上并有人维护的保留，只能落到后台但无前台出口的暂存，既无出口又无维护人的归档不迁。下面以你手里的一份旧系统导出表为对象，逐步走完这个判断。
第一步：把字段按“前台出口”而不是按名称分类
旧系统的字段名往往带业务含义，比如“客户等级”“备注”“来源渠道”，但新站能不能用，取决于它有没有对应的展示位置或筛选入口。做法是打开新站已定稿的页面原型，逐个字段问一句：这个值会出现在哪个页面的哪个区域，或者会参与哪个筛选、排序、表单回填。
- 有明确出口：例如“服务区域”会出现在案例列表的筛选条件里，保留。
- 只有后台出口：例如“内部对接人”，前台不展示，但运营要在后台查，暂存。
- 没有任何出口：例如旧系统里为某次活动临时加的“批次号”，新站没有对应活动页，归档。
这一步的动作结果直接决定下一步：只有进入“保留”和“暂存”两类的字段，才值得花时间做数据清洗；归档类字段连清洗都不必做，直接留一份原始导出文件即可。
第二步：用“空值率”和“唯一值数量”判断清洗成本
分类之后，不要立刻全量导入。先对保留和暂存字段各抽一小段数据，看两个指标：空值占比，以及唯一值有多少种。空值高、唯一值又多的字段，通常意味着旧系统里填写随意，迁进来只会污染新站。
假设一张旧表有 500 条记录，其中“详细地址”字段有 300 条为空，剩下 200 条里出现 180 种不同写法。这个字段如果直接迁入，前台展示会大面积留白，后台筛选也几乎无效。此时合理动作是先做标准化映射，把能归并的写法合并成有限几个区域值，再决定是否保留原字段。反过来，如果“所属区县”空值很少、唯一值只有几个，清洗成本低，可以优先保留并直接用于筛选。
这里的判断依据是：空值率决定前台是否难看，唯一值数量决定后台是否可用。两个指标都差的字段，即使业务上重要，也应先暂存而非直接上线。
第三步：区分“迁移”和“重建”，避免把旧结构硬搬
很多迁不进去的字段，问题不在数据本身，而在旧系统把多个信息塞进了一个字段。例如旧系统只有一个“联系方式”字段，里面混着电话、微信、邮箱。新站如果分成三个独立字段，直接迁入必然失败。
这时要做的不是找工具强行映射，而是先在新站结构里确认：这三个信息是否真的都需要独立展示和独立维护。如果只有电话需要前台点击拨打，微信和邮箱只是备用，那就只保留电话字段，其余内容放进一个“其他联系方式”的备注字段暂存。动作结果是：新站字段数量减少，导入失败率下降，后续编辑也不用面对一个含义混杂的输入框。
判断标准可以写成一句可执行的话：一个字段只承担一个前台用途，承担不了就拆，拆完没人维护就并回暂存。
第四步：给每个保留项指定维护人和更新触发条件
字段能不能长期活下去，取决于有没有人负责更新。迁移方案里应给每个保留字段写清两件事：谁维护，以及什么情况下需要改。
- 维护人：具体到岗位，例如“内容编辑在发布新案例时填写服务区域”。
- 触发条件：例如“服务区域调整时，同步更新筛选选项和已有案例的对应值”。
如果某个字段找不到维护人，也没有明确的更新触发条件，它大概率会在上线三个月后变成一堆过期数据。此时更稳妥的处理是把它从保留降为暂存，前台不展示，只在后台保留查询能力。这个降级动作不会让新站缺内容，反而减少了长期维护负担。
第五步：用一份“保留项决定表”收口，而不是继续争论
把前面的判断落到一张简单表里，每行一个字段，列出：新站出口、空值率、唯一值数量、维护人、最终处理（保留／暂存／归档）。这张表不需要复杂工具，用你现有的表格软件即可。
收口时的规则是：出口明确且维护人明确的进保留；出口明确但维护人不明的进暂存；出口不明的直接归档。按这个规则走完，你会发现真正需要完整迁入的字段通常远少于最初设想。少迁不是损失，而是把有限的编辑精力集中在能被用户看到、能被运营更新的字段上。决定表一旦定稿，后续的导入脚本、表单设计和后台权限都以此为准，不再逐条重新讨论。
