new Notification() 需满足权限已授权、HTTP(S) 环境、用户手势触发三条件，否则静默失败；Notification.permission 初始为 "default"，必须在点击等用户交互中调用 requestPermission() 并 await 结果；本地 file:// 或非 localhost HTTP 页面不可用；title 必须非空字符串，icon 必须是可 fetch 的绝对 URL；requireInteraction 在 Chrome 有效但 iOS 无视；tag 控制通知覆盖逻辑；onclick 回调需立即绑定且页面需活跃可见；iOS Safari 不支持该 API；权限被拒后应降级为 Toast 或 title/favicon 提示，不可重试请求。
直接用 new Notification() 是行不通的——权限没拿到、环境不满足、调用时机不对，三者只要占一个，通知就静默失败，连错误都不会抛。
Notification.requestPermission() 为什么没反应
最常见原因是：在页面加载时自动调用，比如写在 window.addEventListener('load', ...) 或脚本顶部。Chrome 和 Edge 会直接忽略这种“无用户手势”的请求，返回 "denied" 或卡在 "default" 状态不动。
- 必须绑定到明确的用户交互事件上，例如按钮点击、键盘按键（
keydown）、甚至拖拽释放（drop） -
Notification.permission初始值永远是"default"，不是"granted"，别靠猜 - 调用
Notification.requestPermission()后必须用await或.then()拿结果，轮询或延时判断都不可靠 - 本地
file://协议下整个 API 不可用；HTTP 页面（非 localhost）也会被浏览器直接禁用
new Notification() 报错或图标不显示
new Notification(title, options) 看似简单，但几个字段一错，通知就残缺或根本不出：
-
title必须是非空字符串，传undefined或null会抛TypeError -
icon值必须是可被浏览器直接 fetch 的绝对 URL（如https://example.com/icon.png），相对路径在部分浏览器中解析失败，file://图标一律无效 -
requireInteraction: true能阻止通知自动关闭，但桌面 Chrome 会把它钉在系统托盘，iOS 完全无视该选项 -
tag不是装饰用的——相同tag的新通知会替换旧通知；留空则每次都是独立通知，容易堆满
点击通知没跳转或回调不执行
notification.onclick 回调只在当前页面上下文中运行，且依赖页面处于“活跃可见”状态：
立即学习“前端免费学习笔记（深入）”；
- 回调必须在
new Notification()实例创建后立即绑定，不能等通知弹出后再去查 DOM 或重绑 - 如果用户切走标签页、最小化浏览器、或页面被后台冻结（尤其移动端），
onclick可能完全不触发 - 回调里做
window.focus()+window.open()是常见做法，但需注意弹窗拦截策略——必须在同一次用户手势链路内完成 - iOS Safari 不支持
NotificationAPI，"Notification" in window直接返回false，别试图兼容
权限被拒绝后怎么保底提示
用户点“阻止”之后，Notification.permission 永远变成 "denied"，再调 requestPermission() 也没用。这时候硬推通知只会失效，得降级：
- 检测到
permission === "denied"时，立刻改用页面内 Toast（DOM + CSS 动画）或alert()提示关键操作结果 - 对非关键消息（如“已保存”），可用
document.title闪烁 + favicon 动态切换，成本低、100% 可见 - 别在降级逻辑里反复尝试
requestPermission()，用户反感且浏览器可能进一步限制
真正难的不是写那几行代码，而是搞清权限状态流转、环境约束和用户行为链路——漏掉任意一环，通知就消失在空气里。
