Notification.requestPermission()必须由用户手势（如click）触发，否则立即返回"denied"且不弹窗；需先检测"Notification" in window和Notification.permission状态，仅在"default"时调用，并绑定到按钮点击事件。
Notification.requestPermission() 必须在用户手势触发的上下文中调用
浏览器明确禁止在页面加载、setTimeout、DOMContentLoaded 或后台任务中直接调用 Notification.requestPermission() —— 这会导致 Promise 立即以 "denied" 拒绝，且不弹窗。只有真实用户操作（如点击、触摸）才能触发权限请求。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把请求逻辑绑定到按钮的
click事件，而不是页面初始化时自动执行 - 避免封装成“自动请求”工具函数，除非它严格校验
event.isTrusted === true - 移动端注意：
touchstart有时不可靠，优先用click；iOS Safari 对非主窗口（如 iframe）的请求完全屏蔽
判断 Notification API 是否可用及当前权限状态
不是所有环境都支持 Notification，比如某些 WebView、旧版 IE、禁用通知的隐私模式（如 Firefox 的“增强跟踪保护”启用时会屏蔽 Notification.permission 读取）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 先检查
"Notification" in window，再检查Notification.permission !== "default"避免重复请求 -
Notification.permission可能为"granted"、"denied"或"default"；只有"default"才应发起请求 - 不要依赖
permission的初始值做业务判断——它可能被浏览器缓存但实际失效（例如用户在系统设置里关闭了网站通知），需结合后续发送测试通知是否成功来验证
Chrome 和 Edge 中 permission=“granted” 但通知不显示的常见原因
即使权限已获准，new Notification() 仍可能静默失败，尤其在桌面端 Chrome/Edge 上。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 确保页面协议为
https://（http://localhost 除外，但生产环境必须 HTTPS） - 检查浏览器地址栏是否有“禁止通知”图标（锁形图标旁的小铃铛），手动重置该站点权限
- 调用
new Notification("test", { ... })后监听notification.onerror，而非只看构造函数是否抛错 —— 失败通常不抛异常，而是静默丢弃 - 避免在
service worker外部直接发通知；若用showNotification()，必须在 SW 内调用，且注册的 SW 已激活
如何优雅降级并引导用户手动开启通知
当 requestPermission() 返回 "denied"，或用户关闭弹窗后不再提示，浏览器将永久拒绝后续请求。此时无法再次触发原生弹窗，只能靠 UI 引导。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 对
"denied"状态，提供跳转系统设置的链接：Chrome 是chrome://settings/content/notifications，但更通用的做法是展示图文指引（因各平台路径不同） - 检测到
permission === "default"但用户未响应弹窗（例如快速切走页面），可延时 1–2 秒后检查状态，若仍是"default"，视为用户取消，改用轻量提示（如 toast）说明“已跳过，可在浏览器设置中开启” - 避免连续弹出多个请求按钮；一次失败后，至少间隔 24 小时再提示，否则易被用户标记为骚扰
