无法清零的徽标会被永久忽略
别名: 清不掉的未读 · 角标残留 · stuck unread
概念解释
未读数字是一个能被处理行为关掉的信号。人做完该做的事，数字应回到零。若无论回复、已读、关掉通知，数字还在——幽灵会话、无法打开的条目、同步错误、永久活动的「有更新」——这个信号会被学会忽略，而且忽略会泛化到以后真正非零的时候。
这条谈的是通知未读作为可闭合信号。它不是红点控件「清不掉就会被无视」的视觉规格，尽管两者同源：坏掉的是「我能把它关掉」这份可控感。
机制
信号要被当调度线索，必须可关闭。可关闭教会人：零等于没事，非零等于有事。关不掉时，非零变成房间里的常亮灯，注意系统把它从「变化」降成「背景」。一旦降成背景，以后真的从 0 跳到 3 也挤不进变化检测——基线已经是亮着。
清不掉的常见来源不是用户懒，而是集合定义无法闭合：计入了没有详情页的对象、计入了别人的未读、计入了产品想保持「活跃」的营销位。人找不到对应项，就会试「点开应用碰运气」；几次之后停止尝试。
怎么研究
制造一个处理完所有可见项后仍非零的数字，观察后续几天里人对主屏数字的注视、点击和应用内搜索「未读」的行为是否下降。
自变量：残留原因（幽灵项 / 无详情 / 跨账号串数）、是否提供「标记全部完成」、残留值大小。 因变量：尝试清零的次数与放弃点、之后真实新到达的打开延迟、是否改用其他通道（邮件、再问同事）。
一次实验里的厌烦不等于永久忽略。忽略是学习，需要重复失败。产品侧可看「数字长期 >0 且会话内已无未读」的用户，其后续到达打开率是否低于数字能回零的用户。不要把「打开应用」当清零成功——打开后数字仍在，学习还在继续。
边界
有人把数字当「有这个应用」的装饰，从不追求零；不能用他们的习惯为残留辩护。共享账号上「别人的未读」不是幽灵，但当前操作者清不掉，体验与幽灵相同，需要按身份过滤。无障碍用户若只能靠数字知道有没有事，卡死的非零等于永久告警，伤害比视力用户更大。法律留存的已关闭工单可以进历史，不应再占待办数字。
怎么落地
- 保证存在一条用户可走完的路径让数字到零：处理完可见项，或明确的「全部标为完成」。
- 打不开、已删除、已过期的对象立即从计数剔除，不要等下一次全量同步。
- 找不到对应项时，不要把数字留着当催促；先修集合，必要时向用户承认并提供清零。
- 验证：处理列表里每一项后看主屏。不是零，就列出计数器还抓着哪些 ID，逐条删掉没有详情的。修完再用一个新到达看它能否从 0 亮到 1 再被处理回 0——回不来，信号已经死了。