Notification.permission 是唯一可靠、同步获取通知权限状态的属性，返回 "granted"、"denied" 或 "default"；该值只读且不自动更新，需用户手势触发 requestPermission()，且 HTTPS 环境为必要前提。
Notification.permission 是唯一可靠、同步获取当前通知权限状态的属性，其他方式（如监听 permission 事件或尝试发送通知再捕获错误）都不能准确反映真实权限值。
怎么读取当前通知权限状态
直接访问全局 Notification.permission，它返回字符串："granted"、"denied" 或 "default"。注意：该值是只读的，且不会自动更新——用户在系统设置里改了权限，页面不刷新的话它仍保持旧值。
-
"granted"：已允许，可立即调用new Notification() -
"denied"：被拒绝，调用Notification.requestPermission()不会弹窗，且始终返回Promise.resolve("denied") -
"default"：未请求过，或用户关闭了弹窗（非点击“禁止”），此时调用requestPermission()才会触发浏览器权限提示
requestPermission() 调用时机和限制
必须由用户手势（如 click、tap）触发，否则 Chrome/Firefox 会静默拒绝并抛出 DOMException: The user gesture is required。不能在页面加载、setTimeout 或 fetch 回调中直接调用。
- 推荐放在按钮点击事件里：
document.getElementById('notify-btn').addEventListener('click', () => { Notification.requestPermission().then(status => { if (status === 'granted') { new Notification('Hello!'); } }); }); - 不要重复调用：多次调用
requestPermission()不会再次弹窗，第二次起 Promise 直接 resolve 当前状态 - 移动端 Safari 对此 API 支持有限（iOS 16.4+ 才支持前台通知，且需开启「网站通知」开关）
为什么检查 permission 后还是发不出通知
常见原因不是权限问题，而是环境或配置缺失：
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
立即学习“前端免费学习笔记（深入）”；
- 页面必须通过
https提供服务（localhost除外）；http下Notification构造函数直接报错TypeError: Notification is not defined - 浏览器标签页处于后台时，部分通知可能被系统节流或静音（尤其 Chrome），但构造函数本身仍成功
- 用户在系统级关闭了该网站的通知（例如 macOS 的「通知中心」设置里关掉了 Safari 的某站点），此时
permission仍是"granted"，但通知不显示——这是浏览器/系统行为，前端无法检测 - 某些广告拦截插件（如 uBlock Origin）会劫持
Notification构造函数，导致实例创建失败或无效果
如何判断通知是否真的被用户看到
不能。API 没有提供“是否展示成功”或“是否被用户点击”的可靠钩子。notification.onclick 只在用户点击时触发，但前提是通知已成功发出并渲染；而 notification.onshow 在 Chrome 中基本不可靠，在 Safari 中不支持。更现实的做法是：记录 new Notification() 是否抛出异常，并结合埋点统计按钮点击率与后续用户行为，间接推测触达效果。
真正容易被忽略的是：权限状态和实际展示能力之间存在断层——permission === "granted" 只代表浏览器允许你“尝试发送”，不代表系统、插件、网络或用户设置没拦住它。
