sharedworker不能直接显示通知或申请权限，但可作为多窗口通知调度中枢，统一处理去重、可见性校验、节流及降级：通过业务id缓存、permission与visibilitystate双校验、客户端注册/注销管理，确保合规前提下轻量可控地推送通知。
Shared Worker 本身不能直接显示通知，也不能申请通知权限，但它能成为多窗口通知的“调度中枢”——统一判断要不要发、发给谁、什么时候发、是否重复。关键不在“创建通知”，而在“控制通知节奏”。
通知去重的核心逻辑是时间窗口+业务标识
用户打开 3 个标签页，同时收到“订单已支付”消息，不该弹出 3 次。Shared Worker 要做的，是把这类请求归一化处理：
- 每个通知请求必须带唯一业务 ID（如 notify-id: "order-8892"）和可选时间戳
- Worker 内用 Map 缓存最近 60 秒内已处理过的 ID，命中即跳过
- ID 不宜只用 URL 或 title，推荐组合：类型 + 关键参数（如
"payment:" + orderId） - 避免用 Date.now() 做 key——不同页面时间可能有毫秒差，应由 Worker 统一分配或标准化
只推给真正需要的页面：权限 + 可见性双校验
不是所有页面都该收到通知。Shared Worker 需维护各端口的状态：
- 页面首次连接时发送
{ type: "register", clientId: "tab-abc", permission: "granted" } - Worker 存储
Map<clientid port permission visibilitystate></clientid>，并监听document.visibilitychange同步状态 - 发通知前，只筛选 permission === "granted" 且 visibilityState === "visible" 的端口
- 若无可见页面，可暂存通知载荷，等任一 tab 切回前台后触发（通过 port.postMessage 推送）
防刷屏与降级兜底不可少
去重不是一劳永逸，还要应对边界情况：
- 不依赖
setTimeout延迟发送——Worker 切后台后定时器会暂停，应由页面自己控制展示时机 - Safari 16.4 以下或旧版 Chrome 中 Shared Worker 静默失败，需检测：构造后发测试消息，1 秒未响应即降级为 localStorage 时间戳去重
- 页面关闭时主动发
{ type: "unregister", clientId }，Worker 清理对应条目，防止内存泄漏 - 服务端推送频率过高时，Worker 可叠加节流（如 5 秒内同类型最多 1 条），而非简单丢弃
它不替代 Notification API，也不绕过用户授权，而是让多个标签页在合规前提下，共享一套轻量、可控、不打扰的通知节奏。
