移动网站建设，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ba2b38f937f2.html
📄
移动网站建设，旧系统字段无法完整迁入时怎样决定保留项
先不要按“字段总数”做取舍，而要先按“这个字段在新移动端页面里是否还有承接位置”分类。旧系统里存在、但新结构中没有对应展示或调用位置的字段，通常应退出；仍被列表、详情、筛选或表单引用的字段，才进入保留或改写讨论。判断依据不是字段新旧，而是它是否参与当前移动端的信息表达和后续维护。
先确认字段是否还有承接位置
把旧字段逐个对照新移动网站建设的页面结构，结果只有三类：有明确落点、需要换一种形式表达、没有落点。第一类进入保留候选，第二类进入改写候选，第三类直接退出迁移范围。这里的关键证据是页面模板和调用关系，而不是字段在旧库里的重要性描述。
一个可操作的检查动作是：打开新移动端的主要模板，标出每个可见区域由哪些字段驱动。若某字段找不到驱动它的区域，也没有被筛选、排序或详情逻辑引用，就把它列入退出清单。这个动作的结果会直接缩小保留项范围，避免把迁移变成“能搬就搬”。
保留、改写与退出的适用前提
保留：字段在新页面有稳定位置
只有当字段在新移动端有固定展示位置、且内容维护者能持续提供该字段时，保留才成立。若字段只是偶尔出现在旧页面，新页面没有对应区域，强行保留会制造空值或占位内容，反而增加后续清理成本。
改写：字段含义仍在，但表达方式要换
旧字段如果承担的是分类、备注或附加说明作用，而新移动端把它合并进标签、摘要或折叠区，就适合改写。改写的前提是你能说明新旧表达之间的对应关系，例如旧字段“补充说明”改为详情页的折叠段落。若对应关系说不清，改写会变成二次猜测。
退出：没有承接位置且无人维护
退出不是删除历史数据，而是不纳入新移动网站建设的内容模型。适用条件是：该字段在新模板无落点、无调用、无维护责任人。退出后要记录它曾存在，以便日后核对，而不是静默丢弃。
用一组可区分原因的证据做决定
当团队对某个字段争执不下时，可以按下面这组证据判断，而不是凭感觉投票：
- 该字段是否出现在新移动端至少一个模板的可见区域；
- 该字段是否被筛选、排序、搜索或详情逻辑调用；
- 该字段是否有明确的内容维护人，以及更新频率是否可说明；
- 该字段缺失时，用户是否还能完成主要浏览或提交动作。
如果前两项都为否，后两项也无法给出肯定回答，退出比保留更合理。如果第一项为否、第二项为是，说明它可能只服务于后台逻辑，应改写为不直接展示的配置项，而不是当作可见内容保留。
一个注明假设的短例子
假设旧系统有一个“门店补充说明”字段，新移动端详情页只保留门店名称、地址和营业时间。若该补充说明没有在新模板中出现，也没有被筛选调用，且没有专人更新，那么它应退出迁移。若运营仍需要用它区分服务范围，就可以改写为详情页折叠区的一段说明，并指定维护人。两种选择的分界，不是字段本身好不好，而是新页面是否还需要它承担表达任务。
决定之后要做什么
完成分类后，先输出一份保留、改写、退出清单，再把清单交给模板和内容维护两端确认。确认结果会影响下一步：保留项进入字段映射，改写项进入模板调整，退出项进入历史记录。若确认过程中发现某个退出项其实被筛选逻辑调用，就把它移回改写项，而不是直接恢复为保留项。这样处理，迁移范围会随证据收敛，而不是随争论反复扩大。
