一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 协议去重与通知去重不是同一件事：一条状态更新可以合法重复处理，却不应重复打扰用户。多标签还可能同时收到同一事件，需要选出唯一展示者。
前端架构的核心不是目录层级，而是状态由谁拥有、事件能否重复执行、旧异步结果如何失效，以及卸载后监听器和资源是否真正归零。
设计时必须回答的问题
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 通知键由事件 ID、类型和实体版本组成，不能只用文案或发送者。
- 使用 BroadcastChannel 或共享存储协调多标签，前台活动标签优先展示。
- 对需要再次提醒的请求定义明确升级版本或冷却期，而不是永久吞掉。
通知去重保护的是用户注意力。稳定身份、多标签协调和可解释的再次提醒规则缺一不可，单纯时间防抖会漏掉真实事件。
边界情况不是附加项
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 两条不同文件都叫 report.pdf，按文案去重导致第二条通知消失。
- 浏览器通知与站内 toast 使用不同去重存储，同一事件仍提醒两次。
- 去重记录永不清理，长期占用存储并意外屏蔽未来复用 ID。
用证据确认它真的可用
验证时同时观察两端状态、持久化记录和可观测指标。单看某个按钮或一次接口响应，无法证明整个闭环成立。
- 三标签同时在线、一个前台、两个后台，事件只由正确标签提醒一次。
- 重放相同事件、新版本事件和同文案不同 ID，分别验证屏蔽与展示。
- 权限从允许变拒绝再恢复，站内提示与系统通知仍保持一致计数。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。