请在 2 天内给出评审意见。
界面与交互 · 反馈与临时层
通知Notification
铃铛入口加角标驱动的通知列表：未读靠文字和加粗表达，可逐条标已读、移除或批量清空，会留下来直到用户处理。
通知中心实验台：角标怎么跟着你变
亲手点「收到新通知」模拟系统事件到达，看铃铛角标和列表怎么变；逐条「标为已读」看物件从加粗未读转成常重已读；「全部标为已读」让角标归零但记录保留；「清空通知」进入空态；点铃铛折叠/展开。
第 0 步：铃铛是入口（点铃铛展开/折叠通知中心）。点主操作「收到新通知」模拟一条系统事件到达，看铃铛角标和列表怎么变；逐条「标为已读」「移除」，或「全部标为已读」「清空通知」。通知会留下来，不会自己消失。
通知列表 · 按时间倒序
评审林晓邀请你评审「首页改版」未读 构建构建 #218 已通过未读 main 分支部署完成，预览已生成。
评论周然在「登录流程」提到了你已读 @你 这里的空态要不要补一句说明？
通知中心开着：3 条通知，2 条未读。对照：未读数等于铃铛角标，不靠红点独撑。原因：角标是「有新内容」的提醒，不是错误色。下一步：点「收到新通知」模拟一条系统事件到达，看角标和列表怎么变；或逐条「标为已读」。
从刚才的操作里提炼
你在实验台上看到的就是 notification 的核心；下面只是把它命名清楚。
- 铃铛入口 + 角标驱动：未读数显示在铃铛角标上，标已读或清空时角标实时减一——角标是「有新内容」的提醒，不是错误色。
- 通知会留下来：列表项不会自己消失，只能被标已读、移除或清空。实验台里不点不动它就一直留着，这点和 Toast 几秒消失完全不同。
- 未读不靠红点：未读项标题加粗、左侧 ink 边条、带「未读」文字；已读项常重、边条变浅、带「已读」文字。颜色只加强，字重和文字承担含义。
- 按时间倒序：「收到新通知」时新条目插到列表最上面、时间标「刚刚」，旧的往下排。
- 逐条 + 批量：每条可单独「标为已读 / 移除」；面板顶部提供「全部标为已读」「清空通知」两个批量动作，分别在没未读、没通知时禁用。
- 空态友好：清空后面板显示「暂无通知」并说明新通知会去哪里，不让用户猜是否真的清掉了。
什么时候用 notification
从「要不要留下来、要不要立刻处理」判断，并和相邻反馈组件分清边界。
- 用：异步、系统或协作事件的告知——评论回复、@提及、审核结果、构建状态、任务分配、系统维护公告。
- 用：需要用户在方便时查看、未读能被提醒、记录可回看的影响；用
role="status"或aria-live让辅助技术感知新通知。 - 区分 Toast：Toast 是已完成的即时反馈、几秒自动消失；通知是要留下、可回看、由铃铛角标提醒的列表项。
- 区分 Alert：Alert 是页内持续可见的重要提示横条，承载当前页需要用户知晓的事实；通知在通知中心里收着，按列表组织、可清空。
- 区分 Popconfirm：Popconfirm 是针对某次危险操作的轻量确认气泡、用完即关；通知是事件告知，不要求立刻决策。
- 不用：成功保存这类瞬时反馈（→ Toast）、整页结果（→ Result）、必须立刻阻断的决策（→ Modal）。
怎么用：从铃铛到空态的最短路径
让通知能被看到、被处理、被清空，且全程不靠颜色独撑。
- 给入口与角标：铃铛按钮带未读数角标；角标是数字不是红点，未读 0 时角标归零或隐藏。
- 定列表结构：每条有标题、正文、来源、时间和已读状态；新通知按时间倒序插到顶部。
- 给处理动作：单条「标为已读 / 移除」；批量「全部标为已读 / 清空通知」；动作改变物件本身（字重、文字、边条），角标随之更新。
- 给空态与反馈：清空后显示空态文案和下一步入口；状态变化写进
aria-live，不只靠视觉。 - 给键盘与焦点：铃铛可 Tab 到达、展开/折叠；列表内按钮可操作；折叠时角标提醒不丢。
正反例：同一个通知中心，只改未读怎么表达
目标都是让用户知道有几条未读、能逐条或批量处理。差别只在未读是否靠文字和加粗、清空是否有空态。
铃铛显示未读数；列表项有标题、来源、时间和「未读 / 已读」文字；点一条标已读，物件变常重、左侧边条变浅，角标 -1；清空后显示「暂无通知」和下一步入口。
角标只是红点，色盲和读屏都不知道有几条；未读和已读只靠颜色区分；清空后没有空态文案，用户不确定是否真的清掉了，也不知道新通知会去哪里。
快速自测
团队空间里「你被分配了一项新任务」要让用户之后还能回看，最合适放在哪？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。