通知失败筛选与诊断连续性审计
结论
事件中心的通知搜索与送达状态筛选已经从“只过滤当前 20 条”下沉到服务端完整范围。接口在分页前统一执行搜索、阅读状态和送达状态过滤，因此列表、总数、页码与空状态使用同一份结果，不再出现“当前页 0 条、总数仍为 9 条、却提示继续翻页”的矛盾。
生产存储也不再把通知统一映射为“已送达”：数据库中的 failed 会保留为失败，其余站内通知按可见投递结果归一为已送达。失败详情明确说明当前只提供诊断与刷新，不会自动重发；事件、收件人和服务商证据继续保留，并提供关联事件入口。后端尚无通知重发接口和幂等键，因此本轮没有伪造不安全的“重试”动作。
交互步骤与证据
-
失败筛选基线（不健康）
选择“仅发送失败”后，旧实现只过滤当前页，页面同时显示“本页 0 条”和“共 9 条”，但分页已经是1/1。
-
完整范围失败筛选（健康）
同一桌面尺寸下，服务端返回完整范围的真实结果：空状态、共 0 条 · 本页 0 条和1/1完全一致，并提供“查看全部通知”恢复入口。
-
移动端恢复入口（健康）
390 × 844 下，搜索、阅读状态、送达状态与恢复入口保持单列可触达，没有横向滚动或被固定导航遮挡。
-
完整范围搜索（健康）
搜索“氢”由服务端返回 1 条结果，列表与共 1 条 · 本页 1 条同步，证明搜索不是当前页二次过滤。
-
前后视觉对照（健康）
相同 1440 × 900 状态下，对照确认总数与空状态的逻辑断层已消失。
验证
- 事件中心专项：43 项通过。
- Web 正式套件：78 个测试文件、508 项通过。
- API：
go test ./...全量通过。 - 生产构建：TypeScript、Vite 构建与发布资产门禁通过。
- 浏览器：1440 × 900 桌面、390 × 844 手机真实本地前后端联调通过。
无障碍与证据边界
- 搜索框、阅读状态、送达状态、恢复按钮和分页保留可访问名称；移动端主要触控目标可完整触达。
- 当前 Mock 数据没有真实服务商失败样本，所以截图证明的是完整范围筛选、可信计数和恢复入口；失败详情的“只读诊断、不会重发”、关联事件与刷新动作由组件回归测试覆盖。
- 本轮未执行屏幕阅读器或真实键盘全流程测试，不能把 DOM 语义检查等同于辅助技术验收。