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 后还是发不出通知

常见原因不是权限问题，而是环境或配置缺失：

• 页面必须通过 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" 只代表浏览器允许你“尝试发送”，不代表系统、插件、网络或用户设置没拦住它。