如今JavaScript的Notification API是不是已经没有实用价值了？

你对相关规则的解读存在偏差：浏览器限制的是调用Notification.requestPermission()申请通知权限的时机必须是用户主动触发的交互事件（如点击、触摸操作），而非限制后续所有通知的发送时机。只要用户曾经主动授予过通知权限，你完全可以在页面打开时、甚至通过Service Worker在后台监听到状态变更时推送通知，完全不需要绑定实时用户交互。

你举的点击按钮当场弹通知的例子本身就是刻意造的极端反例，实际生产环境中这个API的常用场景包括：

• 即时通讯类网页：用户切换到其他标签页浏览时，收到新消息可以通过系统级通知提醒，不需要用户停留在当前页面
• 工具类站点：后台长耗时任务（文件上传、批量导出、代码构建、模型训练）执行完成时推送通知，用户不需要一直守在进度页等待
• 协作办公类应用：会议即将开始、收到新的审批申请、协作人@你时同步通知，避免错过待办
• 内容类平台：用户主动订阅的内容更新时推送提醒，不需要用户频繁手动刷新页面

要求权限申请必须在用户手势触发时发起，本质是为了遏制早期网页滥用通知的乱象：过去很多页面一加载就弹通知权限申请，用户还没搞清楚站点用途就被骚扰，严重影响浏览体验。这个规则只是要求站点先向用户明确说明通知的用途，用户主动触发交互（比如点击站点内的「开启消息提醒」按钮）后再申请权限，从源头减少垃圾通知骚扰。

你提到的文档说明如下：

注：上述示例中我们是响应用户手势（点击按钮）来触发通知的。这不仅是最佳实践——你不应该向用户推送他们未同意接收的垃圾通知——而且未来浏览器会明确禁止非响应用户手势触发的通知，例如火狐浏览器从72版本开始已经执行了这一规则。
这里描述的「非响应用户手势触发的通知」特指未获得用户事前授权的通知，以及页面首次加载无任何交互就发起的权限申请，完全不包含用户授权后正常业务场景下的通知推送。

你想要的「应用状态发生值得关注的变更时给用户发通知」的场景完全符合规则，实现步骤如下：

1. 在你的页面上设置一个明确的交互入口，比如标注为「开启状态变更提醒」的按钮
2. 监听该按钮的点击事件，在事件回调中调用Notification.requestPermission()申请通知权限
3. 拿到用户授权后，后续只要监听到符合要求的状态变更，直接构造new Notification()实例发送通知即可，不需要额外绑定用户交互
4. 如果需要页面关闭后也能推送通知，可以搭配Service Worker的Push API实现离线推送

内容的提问来源于stack exchange，提问作者Jordan