cms系统选择：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /caf2f0212d5b.html
📄
cms系统选择：旧系统字段无法完整迁入时怎样决定保留项
先给出结论：当旧字段无法完整迁入时，不要按“字段数量”决定保留项，而应按“这个字段是否仍驱动一个页面动作”来筛。你手上不需要完整数据库权限，只要拿一个仍可访问的旧页面或一份导出的字段清单，就能把保留项分成必留、可合并、可丢弃三档，并据此判断新系统要开哪些字段、要不要改内容录入流程。
先取一个旧页面作为样本，而不是先看全表
缺少完整数据或权限时，最容易犯的错是等一份“全量字段表”再动手。更可行的最小动作是：挑一个内容最全、引用字段最多的旧页面，把该页面实际渲染出来的字段逐个抄下来，再和后台字段列表对照。两者的差集就是第一份可疑清单。
这一步能得出的结论有限：它只能说明“这个页面上哪些字段真的被用到”，不能说明其他页面的情况，也不能说明某字段是否被接口或外部调用。因此样本要选引用最广的那类页面，比如详情页或产品页，而不是首页。
用三个问题判断一个字段的去留
对清单里的每个字段，依次问：
- 它是否影响页面上某个可见或可操作的结果？例如决定排序、决定是否显示某模块、决定跳转目标。若只是描述性文字且已并入正文，通常可合并。
- 它是否被其他字段或流程引用？例如某字段的值被用于拼接标题、生成列表分组。这类字段即使当前不直接显示，也应先保留并标记依赖关系。
- 丢掉它之后，编辑是否要改用别的方式补录？如果答案是“要手工写进正文”，那它不是可丢弃，而是需要在新系统里换一种承载方式。
三个问题都答“否”的字段，才进入可丢弃档。只答“当前没显示”的，先放可合并档，不要直接删。
把字段分成三档后，动作顺序会变
分档的意义不是分类本身，而是决定下一步先做什么。假设你手上有一个旧产品页，字段包括“型号”“短描述”“长描述”“排序值”“关联配件”“旧分类ID”。按上面的问题筛一遍：
- 必留：型号（用于标题和筛选）、关联配件（影响页面模块）、旧分类ID（可能影响列表归属）。
- 可合并：短描述与长描述，若新系统只有一个正文字段，可把短描述并入正文开头，但要先确认列表页是否单独调用短描述。
- 可丢弃：排序值，若新系统已改为按发布时间或手动拖拽排序。
这个假设例子的关键不在结论，而在动作：先确认“短描述是否被列表页调用”，再去决定合并还是新开字段。这个确认动作会直接改变新系统的字段设计——如果列表页要用，就必须保留一个独立摘要字段；如果不用，合并能减少编辑负担。
权限不足时，用可观察结果代替字段定义
拿不到字段注释或数据库结构时，不要猜字段含义，改看它的可观察结果。具体做法是：改一个字段的值，看页面上哪里发生变化；或者对比两个内容相似但该字段不同的页面，看差异出现在哪。缺少修改权限时，只做后者。
这里要说明一个常见误判：某个字段在页面上没有输出，不等于它无用。它可能只被后台流程、导出脚本或外部接口使用。反过来，页面上出现的文字也不一定来自独立字段，可能由模板拼接生成。因此“页面没显示”只能作为降级依据，不能单独作为删除依据。
如果连对比样本都拿不到，最小动作是记录该字段的名称、出现位置和疑似用途，标记为“待确认”，而不是替它下结论。待确认项应集中在一处，等拿到更多样本或权限后再统一处理。
决定保留项之后，先改录入规则再改系统
保留项确定后，下一步不是马上配置新系统，而是先写一版新的录入规则：哪些字段必填、哪些由模板自动生成、哪些内容写进正文即可。这份规则会暴露两个问题：一是新系统字段是否够用，二是编辑习惯是否需要调整。
如果规则里出现“同一信息要在两个字段重复填写”，说明字段设计还没收敛，应先合并或改为自动生成，再进入迁移。这个动作的结果会直接影响迁移工作量：重复字段越多，迁移时的清洗和核对成本越高，后续也更容易出现两处内容不一致。
最后提醒一点：字段保留项的决定应能追溯到具体页面或具体流程。凡是说不清“它影响哪个页面动作”的字段，先放待确认档，而不是凭字段名听起来重要就保留。这样即使数据不完整，你也能得到一个可执行、可复核的处理方案。
