建站风格选择，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6fb41deb4c09.html
📄
建站风格选择，旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段新旧”或“谁说话更响”来定保留项，而要把每个字段还原成一条可核对的业务事实——谁在什么环节写入、谁读取、缺失后哪一步会停。能通过这条核对的事实保留，通不过的合并或放弃。样式层面的字段（颜色、间距、图标名）通常可以重做，业务状态字段一旦丢失往往无法在后期补回，这是取舍的基本方向。
同一个字段，为什么两个人说法相反
迁移评审会上常见的矛盾是：技术负责人说“这个字段三年没被读取过，可以删”，运营负责人说“每个订单都要看它”。两种说法可能都对，只是指的不是同一件事。技术方看到的是数据库里的读取日志，运营方说的是自己每天在后台列表里看到的那一列。如果列表页的展示值来自另一个缓存表或报表，原字段确实可能长期无人直接查询，但业务仍然依赖它。
另一种解释是字段被写入了但从未被读取，属于历史遗留；也可能它被外部系统通过接口读取，而站内日志看不到。区分这两种解释，不能靠回忆，要靠证据。
用三类证据区分“没人用”和“看不见但在用”
第一类证据是写入路径。找到所有会写这个字段的表单、接口、定时任务和导入脚本，记录触发条件。如果只有一次性的历史导入写过它，之后没有任何入口，它更可能是遗留字段。
第二类证据是读取路径，而且要跨出本站范围。检查对外接口文档、导出文件、报表订阅、第三方对接清单，以及人工复制粘贴的操作习惯。很多“没人读”的字段，实际消费者是财务或客服的导出表格。
第三类证据是缺失后果。假设这个字段在新系统里为空，列出会受影响的页面、流程和角色，并标注影响是“显示空白”还是“流程无法继续”。显示空白通常可以接受，流程中断必须保留或找到替代来源。
把三类证据写进同一张对照表，按字段逐行填写。当两个人的说法冲突时，表格里空着的那一格就是下一步要查的东西，而不是继续争论。
把分歧转成可核对项目的具体做法
可以按下面的顺序推进，每一步的产出都会决定下一步：
- 列出候选字段清单，只写字段名和一句话业务含义，不写技术类型。
- 为每个字段指定一名“事实责任人”，由最接近该业务环节的人担任，而不是由职位最高的人担任。
- 让责任人填写写入来源、读取来源、缺失后果三项。填不出的项目标为待查，不标为可删。
- 对待查项安排一次实际验证：在测试环境把该字段置空，走一遍相关流程，记录哪一步出现异常。
- 根据验证结果把字段归入保留、合并、放弃三类，并写明合并后的承接字段。
第四步是整段流程里最关键的动作。置空验证的结果会直接改变分类：如果流程照常走完，只是某处显示为空，可以降级为“可选保留”；如果出现报错、数据错位或人工无法判断状态，就必须保留或先补上替代字段，再谈样式调整。这个结果还会影响下一步的迁移排期——需要保留的字段越多，映射和校验的工作量越大，风格改版就应排在数据稳定之后。
一个假设例子：状态字段与展示字段的取舍
假设旧系统有一个“会员等级备注”字段，运营坚持保留，技术认为可删。核对后发现：它由客服手工填写，站内没有任何页面读取，但每月会导出给另一个团队用于人工分群。这种情况下，字段本身可以不在新站前台出现，但导出能力必须保留，否则下游工作会断。相反，另一个“主题色名称”字段虽然被页面读取，但新风格会整体替换配色体系，它的值不再有意义，放弃即可，只需记录旧值备查。
这个例子的判断依据不是字段数量，而是“谁在消费它”和“缺失后哪一步停”。同一套标准可以套用到所有争议字段上。
迁移期间风格决策应该让位到什么程度
数据字段的取舍会限制风格选择的空间。如果保留项里包含大量需要并列展示的状态和备注，页面结构就必须预留这些位置，此时不适合选择以极简卡片为主的风格；反过来，如果核对后确认大部分字段可合并，展示压力变小，风格上的自由度才真正提高。因此合理的顺序是先冻结保留项清单，再定版式与视觉方向，而不是先定风格再往模板里塞字段。
需要提醒的是，读取日志为零、导出记录为零这类现象，只能说明“在当前记录范围内没有观察到使用”，不能单独证明字段可以删除。日志未开启、读取走的是另一条链路、使用发生在记录范围之外，都是合理解释。把置空验证和责任人确认结合起来，才能让删除决定站得住脚。最终清单一旦确认，就应作为后续版式和视觉评审的共同依据，避免风格讨论反复推翻已经核对过的字段取舍。
