你以为点了”忽略”就是永久拒绝？今天 Chrome 155 把通知权限这件事彻底扳过来了

每次打开一个新网站，第一件事就是弹出一个全屏通知授权弹窗——这个体验，从 Chrome 155 开始彻底改变了。

以前：要么立刻点，要么永久拒绝

旧版 Android Chrome 的通知授权弹窗是一个强制阻塞的全屏模态框。用户要么当场点”允许”或”屏蔽”，要么就被这个弹窗卡住。这个设计催生了一个行业问题：用户在第一秒还没来得及了解网站价值的时候，就被要求做决定——结果多数人直接点拒绝，或者被弹窗烦到直接关掉页面。

与此同时，很多网站只要用户一进首页就弹通知请求，不管用户是否真的需要。这导致通知授权率极低，用户对通知推送的印象也普遍负面。

Chrome 155 做了什么

从 Chrome 155（稳定版 2026 年 9 月 23 日发布）开始，Android 版 Chrome 的通知授权弹窗改为非阻塞横幅：

• 出现在网址列附近，不遮挡主要内容
• 只有一个”允许”按钮，其他选项收到设置菜单里
• 用户继续浏览，不点任何按钮，横幅会自动消失

关键区别在这里：超时消失的横幅，不等于用户拒绝了通知权限。超时后，用户代理返回的权限状态是 default（未决定），而不是 denied。

旧行为（Chrome 154 及之前）：
用户无视弹窗 → Notification.requestPermission() → ‘denied’（永久拒绝）
网站此后无法再请求权限

新行为（Chrome 155+）：
用户无视横幅 → Notification.requestPermission() → ‘default’（暂未决定）
用户可随时在 Site Controls 重新开启

Site Controls：绕过了弹窗，之后还能再订阅

Chrome 155 在网站控制界面（Site Controls）新增了一个”通知”入口。只要网站曾经触发过一次通知请求，无论用户当时有没有做决定，之后都可以在 Chrome 地址栏旁边的网站控制图标里随时开启通知。

这意味着：用户可以在下完单、看完文章、搜完航班之后，回到网站再决定是否要开通知——而不是被一个一进首页就弹出的弹窗绑架了决定权。

代码需要改：不能只靠 requestPermission 的回调

这是开发者最需要关注的部分。旧代码通常这样写：

Notification.requestPermission().then(permission => {
  if (permission === 'granted') {
    subscribeToPushNotifications(); // 订阅成功
  }
  // granted → 做订阅，denied/default → 不做
});

在 Chrome 155 里，这个模式在超时场景下就失效了：用户忽略了非阻塞横幅，requestPermission() 的 Promise 会以 ‘default’ 完成（不是 ‘denied’），网站不会收到任何通知。但用户之后可以在 Site Controls 里手动开启——而这段代码不会再自动触发订阅。

正确做法：监听权限状态变化，而不是只看 requestPermission() 的返回值：

// 1. 先请求权限（新版横幅会自然超时消失，不影响用户体验）
Notification.requestPermission().then(permission => {
  if (permission === 'granted') {
    subscribeToPushNotifications();
  }
  // 如果是 'default'，说明用户暂时没做决定，不要在这里放弃
});

// 2. 监听用户在 Site Controls 里的后续操作
navigator.permissions.query({ name: 'notifications' }).then(permissionStatus => {
  permissionStatus.onchange = () => {
    if (permissionStatus.state === 'granted') {
      subscribeToPushNotifications(); // 用户后来手动开启了
    }
  };
});

行业背景：通知疲劳是真实问题

Google 内部数据显示，用户对新版轻量提示的理解程度与旧版相近，但摩擦显著降低。多数用户不愿意在第一秒决定，是因为他们还不确定这个网站值不值得订阅通知——这本身就是一个合理的用户行为。

这也意味着：靠强制弹窗获取通知权限的老路走不通了。网站需要提供足够的上下文，让用户在实际使用场景中自己判断是否需要通知——比如电商在订单完成后提示、物流在发货后提示、内容网站在用户读完几篇相关文章后提示。

落地建议

1. 立即行动：检查通知订阅代码是否只依赖 requestPermission() 返回值，如果是，加入 navigator.permissions.query 监听
2. 迁移时机：现在（Chrome 155 刚发布，用户正在逐步升级）
3. 用户体验设计：不要在首屏加载时弹通知请求，等用户完成至少一个有意义的行为之后再提示
4. 测试方式：在 Android Chrome 155 上访问任意启用了通知的网站，观察新横幅行为；Site Controls 里的”通知”入口需要网站先触发一次请求才会出现