扁平化网页设计旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a8bac1c5cb74.html
📄
扁平化网页设计旧系统字段无法完整迁入时怎样决定保留项
先给结论：当旧系统的字段无法全部迁入新结构时，保留项不应按“字段是否重要”来投票，而应按“这个字段是否仍被某个明确动作或明确责任人使用”来筛选。凡是找不到当前使用者的字段，先进入隔离区，而不是直接删除；凡是有使用者但使用频率低的字段，优先考虑合并或降级为备注，而不是原样保留。
矛盾现象：字段删不掉，往往不是因为它有用
旧系统迁移时最常见的僵局，是业务方说“这个字段不能丢”，但问具体谁在用、上一次使用是什么时候，又答不上来。这里有两个截然不同的解释。
第一种解释：字段确实承载着仍在运行的下游逻辑，比如发票抬头、结算备注、售后工单编号，一旦缺失会导致流程断裂。第二种解释：字段只是历史习惯的残留，没人主动使用，但没人愿意承担“删掉它”的责任，于是它被当成安全选项保留下来。
这两种解释对应的处理方式完全相反。前者必须原样迁入并保证可检索，后者应当降级或归档。如果混在一起处理，结果通常是新系统字段越加越多，扁平化网页设计所追求的清晰层级被后台脏数据重新填满。
区分两种解释的证据：看动作，不看意见
要区分“真在用”和“只是不敢删”，可以收集三类证据，按优先级排列。
- 是否有下游动作读取该字段。例如导出报表、触发通知、对接结算。有读取方，字段就属于结构性保留项。
- 是否有明确责任人在近期查询过它。注意这里看的是查询记录，不是口头表态。口头说“可能会用”不构成证据。
- 缺失该字段时，是否有替代来源。如果同一信息在订单备注、客服记录或附件里也能找到，它就不必作为独立字段迁入。
一个可操作的判断动作：把候选字段列成清单，逐个标注“读取方、责任人、替代来源”三项。三项全空，进入隔离区；只有责任人、没有读取方，降级为备注；有读取方，进入保留项。这个动作的结果会直接决定下一步——保留项需要设计新字段类型和校验规则，隔离项只需要一份可导出的归档文件，两者的工作量差别很大。
假设例子：三个字段怎样走向不同结局
假设一个旧订单系统要迁入新的扁平化结构，候选字段为“客户昵称”“内部跟单员编号”“历史折扣说明”。
- “客户昵称”没有下游读取方，但客服会在沟通时查看，且有替代来源（客户主档）。处理方式：不单独建字段，合并进客户备注。
- “内部跟单员编号”被结算报表读取，属于结构性保留项。处理方式：原样迁入，并确认新系统的权限模型能否限制可见范围。
- “历史折扣说明”无人读取、无责任人、无替代来源，但删除可能引发争议。处理方式：进入隔离区，保留一份可检索的归档，不进入新系统主表。
这个例子的重点不是数字，而是比较方法：先确定读取方，再确定责任人，最后看替代来源。顺序颠倒会把“没人反对”误判成“有人需要”。
保留项确定后，扁平化结构要处理的是层级而不是数量
很多人把字段精简等同于字段越少越好，这在新结构里未必成立。扁平化网页设计强调的是信息层级清楚，而不是把所有信息压成一层。保留项确定后，真正要决定的是每个字段放在哪一层。
建议按使用场景分层：高频查询字段放在主视图，低频但必须存在的字段放在详情区，仅用于追溯的字段放在归档区。这样即使保留项数量没有大幅减少，前台呈现仍然保持扁平、可扫读。反过来，如果只做数量删减、不做层级划分，被保留下来的字段会挤在同一层，阅读负担反而更重。
需要说明的适用条件：这套方法适用于字段有明确使用记录的旧系统。如果旧系统本身缺少查询日志或权限记录，那么“无读取方”这一项就不能作为删除依据，只能作为隔离依据，先归档再观察。
什么时候应该放弃迁移，改为只读归档
如果一批字段既没有读取方，也没有责任人，而且旧系统本身已经停止写入，那么更合理的做法不是逐个迁入，而是整体转为只读归档。判断标准可以简化为两条：旧系统是否还在产生新数据；新系统是否需要在日常流程中查询这些字段。
两条都是否，就整体归档；只要有一条是，就回到前面的三项证据法逐项判断。这个决策会影响后续的接口设计、权限配置和页面结构，所以应在字段清单确认阶段完成，而不是等开发中途再回头讨论。
