E5.17.4badge-state consistency设计
徽标出现的判定逻辑需要与实际状态严格一致
别名: 徽标与状态不一致 · stale unread · 假红点
概念解释
导航徽标是目的地内部状态的外溢。判定逻辑必须和真实状态一致（badge-state consistency）：里面没有未处理就不亮，里面还有就亮，数字对得上对象。不一致时，人进门找不到事，或门上没亮却漏掉了事。这不是习惯化（长期亮着让人麻木），而是每一帧的真假。
机制
徽标通常是缓存的聚合：未读表的计数、待办队列的长度、购物车行数。聚合若与源表分开写，两边就会分叉——已读回写了源，计数没减；推送把计数加一，源里却没有这条。用户以导航为真，进去对不上，就会把所有徽标降级为不可信。多端更易分叉：手机上已读，桌面导航还亮。聚合查询若被故意写松（「有过未读就一直亮」），假阳性会系统性地出现。
假阴性同样糟：过滤、归档、别人已处理，源已经空了，导航还要求人进去看。假阳性训练忽略；假阴性训练不再依赖导航，改用抽查，徽标作为选择线索就失业了。
边界
短暂的网络延迟可以让徽标晚一拍，但进入目的地时应立即以源为准纠正，不能让错误计数在会话里一直挂着。有意的「先乐观加一」必须在失败时回滚。权限只能看见部分对象时，徽标应按可见对象计，不能把不可见的未读也算上，否则进去对不上。演示数据、引导用的假未读一旦混进真实通道，会把一致性永久弄脏。
怎么落地
- 徽标只从与列表同一份源聚合，读、处理、删除走同一条写路径去减计数。
- 多端以源为权威，打开导航或进入目的地时拉一次对齐，不要各端长期各记各的。
- 进入后若列表为空仍亮着，或列表有未处理却不亮，当作缺陷而不是视觉问题。
- 验证：在一端处理一条，另一端导航应在下一次可见时灭或减。人为制造源与缓存分叉，界面应以源为准纠正。对照列表条数与徽标数字，对不上就修聚合，不要先改颜色。