JS如何实现通知？Notification API-js教程-PHP中文网

浏览器实现桌面通知需先请求用户权限，再调用Notification API显示通知；必须在用户授权后才能发送，且最佳实践是在用户有明确意图时再请求权限，避免一进入页面就弹出，以提升授予权概率，同时可通过tag实现通知替换、actions添加交互按钮，并结合Service Worker实现离线推送，但需注意跨浏览器兼容性、系统级通知限制及防止通知滥用导致用户反感，最终在保障用户体验的前提下提升消息触达效果。

js如何实现通知？notification api

JavaScript实现通知主要依赖浏览器提供的

Notification API

登录后复制

。它允许网页在用户许可的情况下，向桌面发送系统级别的通知消息，即使浏览器处于后台或最小化状态也能触达用户。这对于需要即时提醒、消息推送的应用场景来说，是个非常实用的功能。

解决方案

要实现一个基本的桌面通知，你需要处理两个核心步骤：请求用户权限，以及创建并显示通知。

首先，检查浏览器是否支持

Notification API

登录后复制

。虽然现代浏览器基本都支持，但做个判断总归是稳妥的：

if (!('Notification' in window)) {
    console.warn('当前浏览器不支持桌面通知');
    // 可以提供备用方案，比如页面内消息提示
    return;
}

登录后复制

接下来是请求用户权限。这是最关键的一步，因为未经用户同意，任何通知都无法显示。我个人觉得，这个权限请求的时机和方式，直接决定了用户是否会接受你的通知。最好的做法是，在用户明确表示需要通知（比如点击了一个“开启通知”按钮）之后，再发起请求，而不是页面一加载就弹出来。

function requestNotificationPermission() {
    // 检查当前权限状态
    if (Notification.permission === 'granted') {
        console.log('用户已授予通知权限。');
        return Promise.resolve();
    }

    if (Notification.permission === 'denied') {
        console.warn('用户已拒绝通知权限。');
        // 可以在这里提示用户如何在浏览器设置中重新开启
        return Promise.reject('Permission Denied');
    }

    // 如果是 'default' 或其他状态，则请求权限
    return Notification.requestPermission().then(permission => {
        if (permission === 'granted') {
            console.log('用户已授予通知权限。');
        } else {
            console.warn('用户拒绝了通知权限。');
        }
        return permission;
    });
}

登录后复制

当权限被授予后，你就可以创建并显示通知了。一个通知通常包含标题和一些可选的配置项，比如通知内容、图标、点击行为等等。

function showNotification(title, options = {}) {
    requestNotificationPermission().then(permission => {
        if (permission === 'granted') {
            const defaultOptions = {
                body: '这是一条来自网页的通知。', // 通知主体内容
                icon: '/path/to/your/icon.png', // 通知图标
                image: '/path/to/your/image.png', // 通知内的图片
                badge: '/path/to/your/badge.png', // 徽章图标，主要用于移动设备
                tag: 'my-unique-notification-tag', // 标签，用于替换旧通知
                renotify: true, // 新通知是否应该重新提醒用户（即使tag相同）
                silent: false, // 是否静音
                requireInteraction: false, // 是否需要用户点击才能关闭
                data: {
                    url: 'https://example.com/some-page' // 关联数据，可以在点击事件中获取
                }
            };

            const finalOptions = { ...defaultOptions, ...options };
            const notification = new Notification(title, finalOptions);

            // 监听通知的点击事件
            notification.onclick = function(event) {
                console.log('通知被点击了！', event);
                // 可以在这里打开一个新页面或切换到相关标签页
                if (finalOptions.data && finalOptions.data.url) {
                    window.open(finalOptions.data.url, '_blank');
                }
                notification.close(); // 点击后关闭通知
            };

            // 监听通知的关闭事件
            notification.onclose = function() {
                console.log('通知被关闭了。');
            };

            // 监听通知的错误事件
            notification.onerror = function() {
                console.error('通知显示出错。');
            };

        } else {
            console.warn('无法显示通知，因为权限未授予。');
        }
    }).catch(error => {
        console.error('请求通知权限失败:', error);
    });
}

// 示例：点击按钮显示通知
// <button onclick="showNotification('新消息！', { body: '您有3条未读消息。', icon: 'https://cdn-icons-png.flaticon.com/512/732/732223.png' })">显示通知</button>

登录后复制

浏览器通知的权限管理与用户体验？

权限管理是桌面通知的生命线，直接关系到用户对你网站的信任度和留存率。我个人觉得，很多网站在这方面做得并不好，一上来就粗暴地弹出一个权限请求，用户往往不假思索就拒绝了，甚至会产生反感。

核心在于“用户意图”。当用户明确表示出对接收通知的兴趣时，比如他们点击了一个“订阅通知”按钮，或者在完成某个任务后，你询问他们是否希望收到后续进展通知时，才是请求权限的最佳时机。这种“按需请求”的方式，能极大提高用户授予权限的概率。

你需要处理

Notification.permission

登录后复制

的三种状态：

```
granted
```
登录后复制
：用户已授权。可以直接显示通知。
```
denied
```
登录后复制
：用户已拒绝。此时无法再通过
```
requestPermission()
```
登录后复制
再次请求，除非用户手动在浏览器设置中更改。你应该给用户提供明确的指导，告诉他们如何重新开启。
```
default
```
登录后复制
：用户尚未做出选择。这是你调用
```
requestPermission()
```
登录后复制
时会弹窗的状态。

用户体验不仅仅是权限弹窗本身，还包括你发送通知的内容、频率和时机。频繁的、无关紧要的通知会导致“通知疲劳”，用户最终会选择屏蔽甚至卸载你的应用。相反，及时、有价值、个性化的通知能增强用户粘性。思考一下，用户真正想知道什么？是订单状态更新，还是新邮件提醒，亦或是某个特定事件的进展？把精力放在这些有实际价值的信息上，通知才能真正发挥作用。

桌面通知的高级功能与实际应用场景？

Notification API 不仅仅是弹个窗那么简单，它还提供了一些高级功能，让通知更具交互性和实用性。我尤其喜欢

actions

登录后复制

和

tag

登录后复制

这两个属性，它们让通知变得“活”起来。

交互式通知（Actions）：你可以在通知中添加按钮，让用户直接在通知上进行操作，而无需打开网页。比如，一个新消息通知可以有“回复”和“标记已读”两个按钮。

如知AI笔记

如知笔记——支持markdown的在线笔记，支持ai智能写作、AI搜索，支持DeepseekR1满血大模型

查看详情

showNotification('新邮件', {
    body: '来自张三的邮件：关于项目进度的讨论。',
    icon: '/path/to/mail-icon.png',
    actions: [
        { action: 'reply', title: '回复', icon: '/path/to/reply-icon.png' },
        { action: 'mark-read', title: '标记已读', icon: '/path/to/read-icon.png' }
    ],
    data: { messageId: '12345' }
}).then(notification => {
    notification.addEventListener('actionclick', event => {
        console.log(`用户点击了动作：${event.action}`);
        if (event.action === 'reply') {
            // 打开回复界面
            window.open(`/compose?replyTo=${event.notification.data.messageId}`, '_blank');
        } else if (event.action === 'mark-read') {
            // 调用API标记邮件已读
            console.log(`标记邮件 ${event.notification.data.messageId} 为已读`);
        }
        notification.close();
    });
});

登录后复制

通知的替换与更新（Tag）：

tag

登录后复制

属性非常有用。如果你发送多个逻辑上相同的通知（比如同一个聊天会话的新消息），你可以给它们设置相同的

tag

登录后复制

。这样，当新的通知到来时，它会替换掉之前带有相同

tag

登录后复制

的通知，而不是堆叠显示，避免了通知栏的混乱。

renotify

登录后复制

属性则控制替换时是否再次发出声音或震动。

Service Worker 与推送通知：这是桌面通知最强大的应用场景之一。结合

Service Worker

登录后复制

和

Push API

登录后复制

，你的网站可以在用户关闭浏览器后，仍然接收到服务器发送的推送消息，并在后台触发通知。这意味着你的应用可以实现真正的离线消息推送和后台任务提醒，极大地扩展了通知的能力范围。例如，一个电商网站可以在用户下单后，即使关闭了页面，也能在商品发货时收到通知。这通常涉及服务器端发送推送消息，Service Worker 接收并处理这些消息，然后调用

self.registration.showNotification()

登录后复制

来显示。

实际应用场景非常广泛：

即时通讯：新消息提醒、@提醒。
任务管理：截止日期提醒、任务分配通知。
电商物流：订单状态更新（发货、签收）。
新闻媒体：突发新闻推送、订阅内容更新。
日历/日程：会议提醒、事件通知。
金融：股价变动、交易提醒。

跨浏览器兼容性与潜在挑战？

尽管

Notification API

登录后复制

已经相当成熟，但在实际开发中，仍然会遇到一些兼容性和其他挑战，需要开发者去应对。我记得有一次，在调试一个通知功能时，发现某个浏览器上的图标显示有点问题，这让我意识到即使是标准API，也可能存在细微的差异。

浏览器兼容性：主流的现代浏览器（Chrome, Firefox, Edge, Safari）都支持

Notification API

登录后复制

，但具体实现细节和支持的

options

登录后复制

属性可能略有不同。例如，

actions

登录后复制

属性在一些旧版本浏览器或特定移动浏览器上可能不完全支持。

badge

登录后复制

属性主要在Android Chrome上显示效果明显。在开发时，最好查阅 MDN 或 Can I use 网站，了解目标用户群体的浏览器兼容性情况。对于不支持的浏览器，应提供优雅降级方案，比如在页面内显示一个消息提示条。

用户操作系统层面的限制：这是一个常常被忽略但又非常重要的点。即使你的网页代码完美无缺，用户操作系统（Windows, macOS, Android, iOS）的通知设置也会影响通知的显示。例如，用户可能开启了“勿扰模式”，或者在系统设置中禁用了特定应用的通知权限。这些情况是前端代码无法直接控制的，只能通过引导用户去检查系统设置来解决。

通知滥用与用户疲劳：这是最大的“非技术”挑战。如果你的网站过于频繁地发送通知，或者发送的通知内容对用户价值不大，用户很快就会感到厌烦，并选择关闭通知，甚至将你的网站加入黑名单。一旦用户拒绝了通知权限，重新获取就非常困难。因此，通知策略需要深思熟虑，注重用户体验和价值传递。

安全考量：虽然