甘肃网站建设：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /71b56d039e3c.html
📄
甘肃网站建设：旧系统字段无法完整迁入时怎样决定保留项
先给出结论：不要按“字段是否好看”决定去留，而按“这个字段离开旧系统后还能不能独立成立”来分。能独立成立、且新站前台有明确展示位置或后台有明确使用者的字段，优先保留；必须依赖旧系统计算、关联或权限才能成立的字段，先做映射或导出留档，不直接迁入。下面用两种条件展开，并给出可执行动作。
条件一：字段有独立值，且新站有承接位置
判断标准是三条同时成立：字段的值本身是完整信息，不依赖其他表；前台或后台有一个明确的落点；有具体的人会看或用。比如旧站新闻里的“来源”“作者”“发布时间”，这三类通常在新站的文章模型里能找到对应位置，属于可以保留的字段。
实施动作上，先做一张字段对照清单，一行一个旧字段，列出旧字段名、示例值、新站目标字段、是否有落点。做完后抽样二十条真实旧数据，逐条试着填进新站目标字段。如果抽样中有超过一小部分填不进去，说明落点选错了，下一步应改落点或改字段，而不是继续全量迁移。
假设一个例子：旧系统有“区域标签”字段，值为“兰州”“天水”等。新站如果只做全省统一展示，这个字段没有前台落点，但它可以转成后台的分类或标签，供编辑筛选。此时保留是成立的，但保留的是“可筛选属性”，不是“前台可见文字”。这一步的取舍会直接影响后面批量迁移脚本的写法。
条件二：字段依赖旧系统计算或关联，不能单独迁入
典型情况是字段值由旧系统实时算出，或者必须关联另一张表才有意义。例如“累计访问次数”“会员等级”“关联订单号”这类字段，单独导出后在新站既无法继续更新，也没有对应的数据源。把它们硬迁进去，只会得到一批很快过期的数字。
对这类字段，处理方式是先导出留档，再决定是否在新站重建。留档可以用静态文件保存旧值，注明导出时间和口径。是否重建，取决于新站是否真的有对应的数据来源和使用者：如果没有，就不迁；如果有，就作为新功能单独开发，而不是当作迁移任务的一部分。
这里有一个容易做错的判断：请求量、抓取量或某个字段的调用次数归零，并不能单独证明这个字段没有价值。归零也可能来自旧系统停用、入口被移除、统计口径变化。要区分这些原因，可以对照旧系统的操作日志或人工记录，看是“没人用”还是“没入口可用”。这一步没做，后面的保留决定就缺少依据。
用一张表把决定固定下来
把每个字段归入四类，可以避免反复讨论：
- 直接迁：有独立值，新站有落点，有人用。
- 转换后迁：值需要拆分、合并或改格式才能用，例如把“省市区”合成一个地址字段。
- 只留档：依赖旧系统才能成立，新站无数据源。
- 不保留：既无落点，也无人使用，且留档成本高于价值。
分类完成后，先迁“直接迁”和“转换后迁”两类，并保留一份字段对照表。迁移后再抽查前台页面和后台列表，确认字段显示正常、筛选可用。如果抽查发现某字段大面积空白，应回到对照表检查是映射错误还是源数据本身缺失，而不是先改前台样式。
例外与适用条件
有几种情况不适合按上面的顺序走。旧系统仍在运行、只是部分内容退出时，不要急着导出全部字段，先确认哪些数据仍会被旧系统写入，避免导出后两边不一致。涉及用户隐私或合作方数据的字段，保留前要确认是否有继续使用的依据，不能因为“以后可能有用”就长期留存。
另外，如果新站的内容模型还没定，字段决定会被反复推翻。此时更稳的做法是先冻结模型，再做字段对照；模型未定时只做导出留档，不做正式迁移。这样即使后面模型调整，损失也只是一次映射工作，而不是一批已经写坏的数据。
