云南网站设计：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ebb97c350aa9.html
📄
云南网站设计：旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段在新系统里有没有对应位置”决定保留，而要先判断这个字段是否还在驱动一个必须继续完成的任务。做法是拿一个你手头最典型的资料页或详情页，把字段逐个标成“任务必需、展示有用、仅存档”三类，再决定迁移、合并还是导出留存。下面用这个对象走一遍可执行流程。
先选一个页面作为判断对象，而不是先看字段清单
旧系统的字段表往往有几十上百条，单看清单很难判断哪条重要。更可靠的做法是打开一个真实页面，例如一条产品资料或一篇旧公告，把它当作样本。假设这条资料页包含：标题、摘要、正文、作者、发布时间、审核人、内部编号、旧分类、附件、联系备注、浏览量。
把这条页面拆成三类：任务必需指缺了它页面就无法被正确使用，比如标题、正文、附件；展示有用指缺失不影响使用但会降低信息完整度，比如作者、发布时间；仅存档指只对内部追溯有意义，比如内部编号、审核人、联系备注。这一步的产出是一张三列表，而不是一份“全部保留”的愿望清单。
两种做法各自的成立条件与代价
面对无法完整迁入的字段，通常只有两条路：一是把字段合并进现有结构，二是把字段导出为独立存档。它们不是优劣关系，而是适用条件不同。
- 合并进现有结构成立的条件：字段仍会被前台读者看到，或仍参与筛选、检索、排序。代价是你要接受语义被压缩，例如把“审核人”和“作者”合并成一个“责任人”字段后，内部追溯会变模糊。
- 导出为独立存档成立的条件：字段只服务于内部核对、历史追溯或对外证明。代价是它不再出现在页面上，后续想查必须多走一步打开存档文件。
如果强行把“仅存档”字段也塞进页面结构，常见结果是编辑界面越来越长、填写越来越慢；如果反过来把“任务必需”字段也丢进存档，页面就会缺内容。判断依据是：这个字段的读者是外部访客还是内部同事。
用一条规则把每个字段落到具体动作
对样本页里的每个字段问三个问题，按顺序回答，先命中的先执行：
- 缺了它，页面还能被正常阅读或使用吗？不能，则归入迁移保留。
- 它会被访客看到，或会被用来筛选、排序吗？会，则归入合并进现有结构，并记录合并前后的对应关系。
- 以上都不是，则归入导出存档，同时在字段说明里注明“不再进入新系统”。
以样本页为例：标题、正文、附件走第 1 条；作者、发布时间走第 2 条，可以合并进统一的“来源信息”区域；内部编号、审核人、联系备注走第 3 条，导出成一份可检索的存档文件。这个动作的直接结果是：新系统的编辑界面只保留前两类，旧字段仍有据可查。
迁移后必须做一次反向抽查
决定保留项只是第一步，真正影响下一步的是抽查结果。迁移完成后，从旧系统随机挑几条记录，用新系统打开对应页面，逐项核对：任务必需字段是否完整、合并字段是否还能读出原意、存档文件是否能按旧编号找到记录。
如果抽查发现某个“展示有用”字段其实经常被访客引用，就把它从存档提升回页面结构；如果发现某个“任务必需”字段在新系统里根本没人维护，就要重新评估它是否真的必需。这一步的意义在于，保留项不是一次定死的，而是根据抽查证据调整。
把决定写进字段说明，避免下一轮返工
最后把三类字段和对应动作写进一份字段说明：字段名、旧系统含义、处理方式、新位置或存档位置、负责人。假设“联系备注”被归入存档，就在说明里写明它不再出现在页面、查询入口是存档文件。这样后续编辑或开发接手时，不需要重新猜一遍当初为什么删或为什么留。
当字段无法完整迁入时，决定保留项的核心不是技术能否实现，而是这个字段是否还对应一个真实任务。先选样本页、再分三类、再抽查调整，这套顺序能让取舍有依据，也能让下一步的维护成本变得可预期。
