Notification.permission === "granted" 是权限可用的唯一可靠信号，但它只读不可赋值；必须由用户手势（如click）触发requestPermission()，否则抛NotAllowedError；三种状态需区分处理："granted"可直接发通知，"denied"需引导用户手动开启，"default"才可合法请求权限。
Notification.permission === "granted" 是权限可用的唯一可靠信号，但它本身不触发任何操作，也不能被赋值修改。
为什么不能一加载就调用 Notification.requestPermission()
浏览器会直接拒绝——控制台报 NotAllowedError: The request is not allowed，权限卡在 "default" 状态不动。
- 必须由真实用户手势触发：
click、keydown（且有输入）、submit回调内调用才有效 - 包裹在
setTimeout、Promise.then或异步函数里，哪怕只延迟 0ms，也会丢失事件上下文，等同于自动调用 - iOS Safari 完全不弹窗，调用后立刻 resolve 为
"denied"，不会给用户选择机会
Notification.permission 的三种状态怎么区分处理
它只是个只读快照，不是开关。不同状态对应完全不同的后续动作：
-
"granted"：可立即执行new Notification(...)，无需再请求 -
"denied"：用户点过“阻止”，此时再调用requestPermission()无效，还可能被浏览器屏蔽后续提示；应引导用户手动去chrome://settings/content/notifications（或其他浏览器对应路径）开启 -
"default"：用户还没选，等价于没权限，但可以合法调用requestPermission()—— 这是唯一该调用的时机
HTTPS 要求和图标兼容性容易被忽略
即使权限是 "granted"，通知也可能根本不出现在桌面。
立即学习“前端免费学习笔记（深入）”；
- 除
localhost外，必须走 HTTPS，否则new Notification()抛错或静默失败 -
icon参数必须是完整 URL（不能是相对路径），且建议尺寸 ≥ 192×192px；部分安卓浏览器对.webp图标支持差，优先用.png -
tag不只是 ID，相同tag的新通知会替换旧通知而非叠加，适合做状态更新（如未读数）
最常出问题的地方不是代码写错，而是把 permission 当成可设置的开关，或者在非用户手势上下文中尝试请求权限——这两个点一旦踩中，整个流程就卡死，且没有明显报错提示。
