计数需与实际待处理项一致
别名: 未读计数 · 待办一致 · badge count integrity
概念解释
通知系统的数字承诺的是还有几件待处理的事，不是「曾经推过几次」或「应用想被打开的次数」。计数应与人打开后真正能处理的对象一一对应：一条未读会话、一张待审、一笔要确认的扣款。对不上——把已读、已过期、纯展示的状态同步也算进去——数字就不再是待办，而是打开诱饵。
这条写的是未读语义。它不规定红点表示存在、数字表示数量这种控件词汇，那是另一层表面。
机制
人把主屏上的数字当队列长度。队列长度能指导要不要现在打开、打开后扫几眼就能清空。长度掺进不可处理项，预期变成「打开也清不掉」或「打开发现没那么多事」。前者训练人忽略数字，后者训练人把数字当骗点击。两种都会让真的待办失去调度价值。
一致性是跨表面的。通知栏摘要说 3、应用内收件箱说 1、主屏数字说 12，人无法知道该信哪一个。三个数字必须是同一套待处理集合的投影，而不是三套独立计数器。
怎么研究
把人放进「主屏数字 → 打开应用 → 处理」的闭环，对比数字与可点待办对象数，记录第一次不一致之后数字还被不当作调度信号。
自变量：计数是否含已读、是否含过期、是否含应用内已消费的状态；多表面是否共用一个集合。 因变量：数字与可处理项的差、打开后的落空率、后续对数字的注视或点击是否下降。
实验室一次任务测不出「以后不看数字」。需要重复几天，或看产品里数字长期非零用户的打开率。不要用打开次数当健康——虚高计数可以抬高打开，同时毁掉数字作为待办的功能。
边界
「未读」和「未处理」不是同一集合：邮件里已打开但未回复仍可能是待办。产品必须声明计数的是哪一种，并在界面里用词一致。协作收件箱按人计会和按会话计冲突，需要选定一个单位并让打开后的列表按同一单位排。离线期间可以暂时不准，但回前台的第一次绘制就应收敛，不能把同步延迟展示成新的待办。
怎么落地
- 只把「打开后列表里点得着、做得出下一步」的对象计入。已读、已过期、纯展示同步全部排除。
- 主屏数字、通知栏摘要条数、应用内未处理列表共用一个数据源。
- 单位写清楚：是会话还是条。混用会让「3」在不同表面表示不同东西。
- 验证：记下打开前的数字，打开后数真正可处理的对象。差不为零就改计入规则，而不是改字体。连续一周数字非零却没有任何可处理项，这枚数字已经不是待办。