山西网页制作：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /995a5393ca95.html
📄
山西网页制作：旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“旧系统里有没有这个字段”决定保留，而要按“这个字段是否支撑当前页面的一个明确任务”决定。把待迁页面当作样本，逐个字段标注它在新页面上的用途、缺失后的可见后果和补录成本，只有同时满足“有当前用途、缺失会造成实质障碍、后续可维护”的字段才保留；其余字段宁可放弃，或用一段说明文字替代，也不要为了迁数据而把新页面结构撑坏。
先把一个页面拆成字段清单，而不是先看数据库
打开旧系统里最有代表性的一页，把页面上出现的每类信息写成一行：标题、副标题、正文段落、图片、附件、发布时间、作者、来源、标签、联系方式、价格说明、参数表等。然后在每行后面标三件事：它在新页面上对应哪个位置；如果这一项为空，读者会缺少什么；这项内容由谁在什么时间补录。这个动作的价值在于，它把“字段迁移”变成“页面任务迁移”。假设某旧页面有一个“所属科室”字段，但新页面已经用导航路径表达了归属，那么这个字段即使能迁入，也只是重复信息，保留反而增加录入负担。
两种常见做法各自成立的条件
第一种做法是尽量全量保留旧字段，适合旧字段数量有限、含义稳定、且新页面模板已经为它们预留了固定位置的情况。它的代价是页面变长、录入项变多，编辑容易在无关字段上消耗时间。第二种做法是只保留支撑当前任务的字段，适合旧系统字段含义混乱、大量字段长期为空、或新页面以阅读和转化为主要目标的情况。它的代价是部分历史信息会丢失，需要在迁移记录里写明放弃原因，避免以后被反复追问。
判断时看一个信号：如果某个字段在旧数据里长期为空，或者不同编辑对它的填法不一致，它就不适合作为保留项，更适合降级为正文中的一句自然描述。反过来，如果某字段虽然旧系统里填得少，但新页面的核心任务离不开它，例如服务范围、适用对象、办理材料，那就应当保留，并在新后台里设为必填或给出填写提示。这里的关键不是字段新旧，而是它是否承担了页面任务。
用缺失后果和补录成本做取舍
给每个候选字段打两个判断：缺失后果分“读者会误解”“读者无法行动”“只是少一点背景”三档；补录成本分“已有现成内容”“需要人工整理”“需要向他人索取”三档。优先保留“读者无法行动且已有现成内容”的字段；对“只是少一点背景且需要向他人索取”的字段，直接放弃或改为可选。这个排序能避免一种常见错误：为了迁一个几乎没人看的旧字段，去打扰业务人员补录，结果拖慢整个页面上线。
假设一个旧页面有“历史沿革”长文本和“当前办理地点”短文本两个字段。前者缺失只会让读者少一点背景，后者缺失会让读者无法行动。即使历史沿革在旧系统里写得很完整，也应优先保证办理地点准确迁入；历史沿革可以压缩成一句话放在正文末尾，或暂时不迁。这个假设说明的是判断方法，不是某个真实页面的处理结果。
把决定写成可执行的迁移规则
确定保留项后，不要停留在口头结论，写一张迁移对照表，至少包含旧字段名、新页面位置、是否保留、缺失替代方式、负责人。然后先迁一个页面做验证：检查新页面上字段是否出现在预期位置、空值是否导致版面错乱、编辑是否知道怎么填。如果验证发现某个保留字段在实际排版中造成大片空白，就回到对照表把它降级为正文描述，而不是继续加样式硬撑。这个动作会直接影响下一步：只有单页验证通过，才值得批量迁其余页面。
对于无法迁入又不适合直接删除的字段，可以统一放入一个“迁移备注”区域，仅供内部查看，不输出到前台页面。这样既保留了追溯依据，又不会让读者看到一堆无意义的旧字段。需要说明的是，抓取量或请求量下降并不能单独证明某个字段该删或该留，它还可能是页面结构变化、入口调整或统计口径变化造成的，判断仍要回到页面任务本身。
迁移后需要复核的三件事
- 保留字段是否都有明确的新位置，且编辑知道填写规则。
- 放弃字段是否记录了原因和替代方式，避免以后重复讨论。
- 抽样页面在手机和桌面宽度下是否因字段增减出现错位或空白。
如果这三项都通过，就可以按同一套规则处理剩余页面；如果某项不通过，先修规则再扩量，不要一边批量迁移一边临时补丁。字段取舍的目标不是把旧系统搬空，而是让新页面上的每一项信息都能被读者用上、被编辑维护得住。
