如果要選一個(gè) “最能提升網(wǎng)頁應(yīng)用存在感” 的瀏覽器原生能力Notification API 一定排得上號(hào)。它讓網(wǎng)頁能跳出標(biāo)簽頁的限制直接把信息推到系統(tǒng)桌面比如收到新消息、訂單狀態(tài)變化、定時(shí)任務(wù)到點(diǎn)——用戶即使把頁面切到后臺(tái)也依然能被提醒。很多人以為這只是一個(gè)簡單的彈窗接口實(shí)際做下來會(huì)發(fā)現(xiàn)權(quán)限申請(qǐng)時(shí)機(jī)、事件綁定、Service Worker 聯(lián)動(dòng)、不同瀏覽器的行為差異每一項(xiàng)都需要單獨(dú)處理。這篇文章就把 Notification 從基礎(chǔ) API 到項(xiàng)目級(jí)用法徹底過一遍包含我能想到的絕大多數(shù)實(shí)操細(xì)節(jié)和踩坑記錄希望能幫你少走彎路。1. 它解決的問題與適用的場景1.1 說白了它是把網(wǎng)頁信息“送出頁面”的通道瀏覽器本身是用戶主動(dòng)打開來看內(nèi)容的地方但業(yè)務(wù)跟你互動(dòng)的時(shí)候用戶很可能不在當(dāng)前頁面。傳統(tǒng)的做法是網(wǎng)頁里放一個(gè)角標(biāo)、聲音或者改 document.title 來提示但用戶只要切到別的應(yīng)用這些提示就全部失效了。Notification API 的本質(zhì)區(qū)別在于它把消息交給操作系統(tǒng)來展示相當(dāng)于繞開了“用戶是否正盯著瀏覽器”這個(gè)前置條件。這個(gè)能力對(duì)兩類產(chǎn)品尤其重要。一是工具型網(wǎng)頁比如任務(wù)管理、番茄鐘、郵件客戶端它們的作用就是“到點(diǎn)了提醒你做某事”通知是核心功能而非附屬功能。二是消息型應(yīng)用比如客服系統(tǒng)、協(xié)同文檔、IM用戶離開頁面后仍然需要被拉回來。這幾類場景里通知不是錦上添花而是產(chǎn)品價(jià)值的載體。相反如果只是想在頁面上彈個(gè)促銷彈窗那 Notification 并不合適——因?yàn)檫@類通知需要用戶明確授權(quán)而且操作系統(tǒng)層面會(huì)直接干預(yù)展示自主權(quán)有限。1.2 場景沒選對(duì)通知就變成騷擾不要覺得“能彈通知”就萬事大吉。通知有權(quán)限門檻而且用戶對(duì)通知的隱私敏感度很高一旦被拒絕后續(xù)很難再拿回授權(quán)。適合用通知的場景應(yīng)該具備兩個(gè)特點(diǎn)信息本身有較強(qiáng)的時(shí)效性用戶大概率處于“不看頁面”的狀態(tài)。從我的項(xiàng)目經(jīng)驗(yàn)來看下面這些場景比較實(shí)用。場景類型具體例子為什么適合時(shí)間提醒番茄鐘結(jié)束、會(huì)議開始前 10 分鐘、活動(dòng)搶購開始信息必須準(zhǔn)時(shí)觸達(dá)郵件或站內(nèi)信時(shí)效性不夠運(yùn)行結(jié)果反饋長任務(wù)跑完、文件渲染完成、導(dǎo)出成功用戶不需要盯著進(jìn)度條做完通知即可消息到達(dá)新訂單、用戶留言、客服會(huì)話接入響應(yīng)越快越好頁面刷新頻率未必能跟上異常警告服務(wù)掉線、設(shè)備離線、批量操作失敗用戶可能不在電腦前需要系統(tǒng)級(jí)提醒不適合的場景內(nèi)容營銷推送、產(chǎn)品更新公告、節(jié)日問候。這類信息用戶收到時(shí)會(huì)覺得被打擾而且不是即時(shí)剛需通過郵件或下次訪問時(shí)再展示更合理。通知這個(gè)東西越克制越有價(jià)值把用戶注意力消耗干凈之后真正重要的消息也會(huì)被無視。2. 權(quán)限機(jī)制與瀏覽器適配2.1 三個(gè)權(quán)限狀態(tài)與授權(quán)流程N(yùn)otification API 的權(quán)限管理非?！拔锢硎澜纭毙枰脩糁鲃?dòng)點(diǎn)擊一個(gè)按鈕來授予權(quán)限不能在頁面加載時(shí)自動(dòng)彈出授權(quán)框。這一點(diǎn)和相機(jī)、麥克風(fēng)權(quán)限的邏輯一樣瀏覽器把決定權(quán)完全交給用戶任何繞過用戶手勢去請(qǐng)求權(quán)限的行為都會(huì)被靜默拒絕或者被瀏覽器攔截。權(quán)限一共有三種狀態(tài)存儲(chǔ)在Notification.permission里granted用戶已授權(quán)允許顯示通知。denied用戶已拒絕再次調(diào)用Notification.requestPermission()不會(huì)彈出授權(quán)框而是直接返回denied。default用戶未做選擇等同于拒絕但瀏覽器允許你后續(xù)通過用戶手勢再次請(qǐng)求。拿到權(quán)限是第一步判斷權(quán)限狀態(tài)是另一件容易被忽略的事。推薦在應(yīng)用初始化時(shí)主動(dòng)查詢一次權(quán)限狀態(tài)同步到前端狀態(tài)管理里這樣 UI 上能給出對(duì)應(yīng)引導(dǎo)。比如顯示“開啟通知”按鈕還是“通知已開啟”的提示全部可以根據(jù)權(quán)限狀態(tài)來動(dòng)態(tài)渲染。2.2 不同環(huán)境下的行為差異同樣是 Notification桌面端和移動(dòng)端、不同瀏覽器之間差異非常明顯。主流的瀏覽器家族大概可以分成這么幾派Chrome / Edge / Firefox對(duì) Notification 的支持最完整權(quán)限機(jī)制、事件回調(diào)、自定義按鈕等特性基本都能用。SafarimacOS)支持 Notification但權(quán)限請(qǐng)求方式特殊默認(rèn)情況下網(wǎng)站無法主動(dòng)喚起權(quán)限請(qǐng)求需要用戶手動(dòng)在“網(wǎng)站偏好設(shè)置”里允許通知。iOS SafariiPhone / iPad歷史上完全不支持 Notification直到較新的系統(tǒng)版本才開始逐步放開而且仍然依賴 Web Push不是普通頁面直接new Notification()就能通用的方式。這意味著你在開發(fā)時(shí)不能默認(rèn)「用戶看到的和我測試的瀏覽器一樣」。比較穩(wěn)妥的做法是在代碼里做能力檢測不支持的瀏覽器直接走站內(nèi)提醒兜底同時(shí) UI 上不要展示“開啟系統(tǒng)通知”的入口避免用戶點(diǎn)了之后毫無反應(yīng)留下一個(gè)不好的第一印象。3. 核心用法從權(quán)限申請(qǐng)到彈出通知3.1 三步搭建一個(gè)基礎(chǔ)通知先看最簡版本代碼量比想象中少// 1. 檢測支持 if (!(Notification in window)) { console.log(當(dāng)前瀏覽器不支持系統(tǒng)通知); return; } // 2. 檢查權(quán)限 if (Notification.permission granted) { new Notification(你好呀, { body: 這是你的第一條系統(tǒng)通知 }); } else if (Notification.permission ! denied) { // 3. 請(qǐng)求權(quán)限必須在用戶點(diǎn)擊事件里調(diào)用 const permission await Notification.requestPermission(); if (permission granted) { new Notification(你好呀, { body: 這是你的第一條系統(tǒng)通知 }); } }有兩個(gè)細(xì)節(jié)想單獨(dú)拎出來說。第一requestPermission()返回的是一個(gè) Promise雖然最新的瀏覽器規(guī)范也支持回調(diào)寫法但 Promise 的寫法更現(xiàn)代化也更容易接入async/await流程。第二new Notification()只能用在頁面上下文Service Worker 里要用另一套 API這個(gè)下面專門講。這里強(qiáng)調(diào)一下不要在頁面加載時(shí)就調(diào)用requestPermission()瀏覽器會(huì)直接忽略或者以不合理手勢為由拒絕必須借助一個(gè)按鈕點(diǎn)擊事件去觸發(fā)。3.2 options 參數(shù)里的“隱藏技能”構(gòu)造函數(shù)new Notification(title, options)里最能體現(xiàn)功力的就是options對(duì)象。很多人只會(huì)填body和icon實(shí)際上能力要豐富得多。const notification new Notification(訂單發(fā)貨通知, { body: 您購買的【USB-C 擴(kuò)展塢】已從本地倉庫發(fā)出, icon: https://example.com/icon-128.png, badge: https://example.com/badge-32.png, // 手機(jī)狀態(tài)欄里的小圖標(biāo) image: https://example.com/product-preview.png, // 通知卡片里展示的大圖 tag: order-shipped-2024-0801, renotify: true, silent: false, requireInteraction: true, data: { orderId: ORD-2024-0801, url: https://example.com/orders/20240801 } });這些參數(shù)里面tag是我認(rèn)為最值得優(yōu)先使用的。tag相當(dāng)于通知的“分組 ID”當(dāng)你傳了一個(gè)和之前相同的tag新通知會(huì)直接替換舊通知而不是在通知中心里越摞越多。對(duì)于一條消息反復(fù)推送的場景比如多人協(xié)作文檔里不斷有人 你用同一個(gè) tag 就能保持通知區(qū)域整潔不至于幾十條彈窗把系統(tǒng)通知中心撐爆。requireInteraction的作用是讓通知保持出現(xiàn)狀態(tài)直到用戶主動(dòng)關(guān)閉。不設(shè)置時(shí)系統(tǒng)默認(rèn)幾秒后自動(dòng)收起。用在線上排障或工單告警場景會(huì)比較合適但也要克制別讓用戶桌面上常駐著一堆永遠(yuǎn)清不完的通知。renotify必須配合tag使用作用是當(dāng)新通知替換舊通知時(shí)再次觸發(fā)聲音或振動(dòng)提醒。沒有這個(gè)參數(shù)相同 tag 的通知替換時(shí)是靜默的用戶可能根本不知道又有新內(nèi)容。silent則相反適用于消息量特別大、不想打擾用戶的場景比如批量同步進(jìn)度進(jìn)度通知不需要音效轟炸。3.3 事件回調(diào)讓通知“活”起來通知彈出來只是一半另一半是用戶點(diǎn)擊、關(guān)閉、出錯(cuò)時(shí)的處理。Notification 實(shí)例上有四個(gè)核心事件onshow通知成功顯示后觸發(fā)可以用來統(tǒng)計(jì)到達(dá)率。onclick用戶點(diǎn)擊通知時(shí)觸發(fā)通常是整個(gè)通知功能最關(guān)鍵的邏輯。onclose通知被關(guān)閉時(shí)觸發(fā)不管是用戶主動(dòng)關(guān)閉還是系統(tǒng)自動(dòng)收起。onerror通知展示出錯(cuò)時(shí)觸發(fā)比如 icon 地址失效或權(quán)限被撤銷。如果用戶點(diǎn)擊了通知常見的訴求是“跳轉(zhuǎn)到對(duì)應(yīng)的業(yè)務(wù)頁面”。普通頁面里可以直接用window.open或者改變路由跳轉(zhuǎn)但要注意一個(gè)細(xì)節(jié)點(diǎn)擊通知時(shí)當(dāng)前頁面可能處于后臺(tái)直接window.focus()也未必能百分百把頁面拉回前臺(tái)。更穩(wěn)妥的方案是把要跳轉(zhuǎn)的 URL 塞進(jìn)data字段里點(diǎn)擊回調(diào)里讀取出來再做跳轉(zhuǎn)notification.onclick (event) { event.preventDefault(); // 阻止系統(tǒng)默認(rèn)的聚焦行為 const targetUrl notification.data.url; window.focus(); window.location.href targetUrl; notification.close(); };event.preventDefault()這段很多人會(huì)漏寫。默認(rèn)行為是瀏覽器自動(dòng)把窗口聚焦并跳到來源頁面但如果你的業(yè)務(wù)需要精確控制跳轉(zhuǎn)地址比如從通知直接跳到某個(gè)內(nèi)頁就一定要攔截默認(rèn)行為自己接管。4. 進(jìn)階實(shí)戰(zhàn)Service Worker 與通知的聯(lián)動(dòng)4.1 為什么需要 Service Worker純頁面的new Notification()存在一個(gè)天然短板頁面一旦關(guān)閉通知的“訂一些優(yōu)點(diǎn)都消失”。你可以推一次但沒法在頁面不在后臺(tái)運(yùn)行的時(shí)候依然保持監(jiān)聽和推送。Notification 本身不是推送通道它只是一個(gè)展示接口背后的“觸發(fā)者”還得另外找。Service Worker 就是這里的關(guān)鍵角色——它由瀏覽器在后臺(tái)獨(dú)立管理即使頁面已經(jīng)關(guān)閉只要瀏覽器進(jìn)程在Service Worker 就能存活并代為觸發(fā)通知。這就引出了 Notification 在真實(shí)項(xiàng)目中的標(biāo)準(zhǔn)姿勢不在頁面里直接new Notification()而是通過注冊(cè)好的 Service Worker 調(diào)用registration.showNotification()。好處有三個(gè)頁面關(guān)閉后依然能彈通知比如收到了服務(wù)器推送的消息。通知點(diǎn)擊事件在 Service Worker 里統(tǒng)一監(jiān)聽即使頁面未打開也能執(zhí)行邏輯。與 Web Push 配合真正構(gòu)建一套“服務(wù)端下發(fā)通知”的完整鏈路。需要說清楚的是如果產(chǎn)品只是需要“頁面打開時(shí)”的通知比如一個(gè)網(wǎng)頁番茄鐘到點(diǎn)提醒那直接在頁面上下文里寫也完全沒問題。但如果希望用戶在完全關(guān)閉網(wǎng)頁后還能收到提醒那就必須走 Service Worker 路線。4.2 一個(gè)完整可運(yùn)行的 SW 通知 Demo我用一個(gè)真實(shí)的指紋工作場景來說明整條鏈路用戶在網(wǎng)頁上啟動(dòng)了一個(gè)“同步任務(wù)”同步過程中可以關(guān)閉頁面完成后瀏覽器彈出通知點(diǎn)擊通知跳回結(jié)果頁。第一步注冊(cè) Service Worker// 在頁面中注冊(cè) sw.js if (serviceWorker in navigator) { const registration await navigator.serviceWorker.register(/sw.js); console.log(Service Worker 注冊(cè)成功, registration); }第二步在 sw.js 里監(jiān)聽消息并彈出通知// sw.js self.addEventListener(message, (event) { const data event.data; if (data.type sync-done) { self.registration.showNotification(data.title, { body: data.body, icon: data.icon, badge: data.badge, tag: data.tag || sync-done, data: { url: data.url } }); } });第三步頁面里向 Service Worker 發(fā)消息const registration await navigator.serviceWorker.ready; registration.active.postMessage({ type: sync-done, title: 同步已完成, body: 本次共同步 128 條數(shù)據(jù)耗時(shí) 3 分 42 秒, url: https://example.com/sync-result/128 });第四步處理通知點(diǎn)擊事件同樣寫在 sw.js 里self.addEventListener(notificationclick, (event) { event.notification.close(); const targetUrl event.notification.data.url; event.waitUntil( clients.matchAll({ type: window, includeUncontrolled: true }) .then((windowClients) { for (const client of windowClients) { if (focus in client) { client.navigate(targetUrl); return client.focus(); } } // 沒有已打開的窗口則打開一個(gè)新窗口 return clients.openWindow(targetUrl); }) ); });這段點(diǎn)擊處理是所有 sw.js 里最經(jīng)典的模板。核心邏輯是先關(guān)閉通知然后在已開著的窗口列表里找一個(gè)窗口聚焦并跳轉(zhuǎn)過去如果當(dāng)前一個(gè)窗口都沒有就新開一個(gè)窗口。event.waitUntil()保證 Promise 執(zhí)行完畢前 Service Worker 不會(huì)被干掉這個(gè)細(xì)節(jié)直接影響通知點(diǎn)擊后的頁面跳轉(zhuǎn)是否可靠?？吹竭@里你應(yīng)該能感受到 Notification 在“頁面上下文”和“Service Worker 上下文”兩套 API 之間的關(guān)系了。其實(shí)底層是同一套展示機(jī)制但 Service Worker 賦予了通知“脫離頁面存活”的生命力。日常項(xiàng)目里如果只是單純做一個(gè)頁面內(nèi)提醒不用上 SW 也說得過去但只要涉及推送和后臺(tái)觸發(fā)SW 就是繞不開的底座。4.3 當(dāng)用戶關(guān)閉的是瀏覽器而不是頁面剛才說“頁面關(guān)閉后依然能彈通知”有個(gè)邊界要?jiǎng)澢宄@里指“關(guān)閉標(biāo)簽頁”不是“退出瀏覽器”。一旦瀏覽器進(jìn)程整個(gè)退出Service Worker 也就停止了。能不能在瀏覽器徹底關(guān)閉后繼續(xù)通知取決于推送通道是否支持這已經(jīng)超出 Notification API 本身的范疇。專業(yè)一點(diǎn)講菜單欄應(yīng)用能一直在后臺(tái)收到通知是因?yàn)樗旧硎且粋€(gè)常駐系統(tǒng)進(jìn)程瀏覽器做不到這層。所以不要在產(chǎn)品文檔里承諾“關(guān)掉瀏覽器也能收到通知”這屬于過度承諾最終會(huì)讓用戶失望。你要做的是把預(yù)期管理好“關(guān)閉網(wǎng)頁后會(huì)收到通知”是成立且合理的預(yù)期“關(guān)閉瀏覽器后收到通知”則不建議承諾。5. 常見問題與排查技巧實(shí)錄5.1 通知不顯示優(yōu)先自查這幾點(diǎn)遇到“代碼明明寫了通知就是不彈”的情況把它們挨個(gè)排查一遍通常能解決 90% 的問題。第一是不是本地文件或 HTTP 環(huán)境。NotificationAPI 在非安全上下文HTTP下不可用localhost除外。如果你用file://協(xié)議直接雙擊打開頁面或者是局域網(wǎng)里用 IP 訪問通知可能直接被禁用。這個(gè)問題最隱蔽因?yàn)樗粫?huì)報(bào)錯(cuò)只是靜默失敗。判斷方法很簡單在瀏覽器 Console 里輸入Notification in window如果是true再看一眼Notification.permission是否正常。第二權(quán)限是不是被拒絕了。有些用戶很早之前點(diǎn)過一次拒絕之后代碼再請(qǐng)求授權(quán)瀏覽器根本不會(huì)再彈授權(quán)框。這種情況不要在代碼邏輯里繼續(xù)白費(fèi)力氣而是要在界面上引導(dǎo)用戶去瀏覽器設(shè)置里手動(dòng)解開權(quán)限。第三tag是不是一直一樣。如果你給通知設(shè)置了固定tag且系統(tǒng)認(rèn)為這條通知還顯示著后續(xù)相同 tag 的通知會(huì)被當(dāng)成“替換”而不是“新增”。當(dāng)你主動(dòng)測試時(shí)可能覺得“通知沒彈出來”其實(shí)它只是被合并更新了。第四系統(tǒng)通知中心是不是被關(guān)閉了。Windows 的“專注助手”和 macOS 的“勿擾模式”會(huì)屏蔽所有通知和代碼無關(guān)。排查這類問題的時(shí)候要先把系統(tǒng)設(shè)置里那些干擾項(xiàng)排除掉不然代碼邏輯查半天發(fā)現(xiàn)是系統(tǒng)層面壓掉了彈窗。第五通知權(quán)限在 Safari 上是不是需要額外開關(guān)。macOS 版 Safari 默認(rèn)不會(huì)彈出網(wǎng)站通知權(quán)限請(qǐng)求必須用戶在偏好設(shè)置里主動(dòng)允許。如果你面向的用戶群體里有大量 Safari 用戶提前在文案里給出配置指引否則這條鏈路對(duì)這些人基本上是無效的。5.2 UX 層的好習(xí)慣別在通知上“翻車”功能層面通了之后還有一個(gè)經(jīng)常被忽略的維度產(chǎn)品體驗(yàn)。通知這種系統(tǒng)級(jí) UI 比頁內(nèi)彈窗更容易惹惱用戶因?yàn)樗驍嗔擞脩粽谧龅娜魏问虑?。?xí)慣一永遠(yuǎn)不要用通知轟炸用戶。通知的本質(zhì)是“打擾”每次彈出都是一次注意力消耗所以不要給每個(gè)動(dòng)作都配通知。比如用戶正在頁面上編輯文檔那任何改動(dòng)都不該彈通知只有“文檔被另一個(gè)成員改動(dòng)了需要刷新才能看到最新版”這類跨會(huì)話信息才值得彈。習(xí)慣二尊重用戶的“撤銷”意愿。第一次請(qǐng)求權(quán)限被拒絕后不要把“開啟通知”的按鈕永遠(yuǎn)藏著也不要立刻再彈第二次。比較好的做法是將通知入口收斂到設(shè)置頁面權(quán)限被拒后顯示“通知已關(guān)閉如需開啟請(qǐng)點(diǎn)擊這里查看設(shè)置步驟”而不是反復(fù)用彈窗式請(qǐng)求去騷擾用戶。習(xí)慣三考慮用戶不在場的情況。通知彈出來的時(shí)候用戶可能正在開會(huì)、睡覺或者吃飯。所以務(wù)必讓通知內(nèi)容自帶上下文點(diǎn)名事件、時(shí)間、數(shù)量、鏈接地址。一條好的通知是“看到內(nèi)容就知道發(fā)生了什么”而不是“我到公司再點(diǎn)開看看”。這也是為什么我建議在data字段里放業(yè)務(wù)上下文點(diǎn)擊跳轉(zhuǎn)時(shí)能把上下文帶過去而不是落到一個(gè)籠統(tǒng)的首頁。5.3 權(quán)限再分配的隱藏策略瀏覽器從設(shè)計(jì)層面上不太鼓勵(lì)用戶“反悔”一旦拒絕就進(jìn)入了一個(gè)死鎖狀態(tài)網(wǎng)頁沒辦法再次發(fā)起授權(quán)請(qǐng)求只能讓用戶去瀏覽器設(shè)置里手動(dòng)改。不同瀏覽器設(shè)置入口不一樣開發(fā)時(shí)如果做到體驗(yàn)顆粒度差異可以在 UI 上做兩個(gè)入口在通知設(shè)置頁里點(diǎn)擊“重新開啟通知”按鈕時(shí)先檢測Notification.permission如果是denied就展示一段“請(qǐng)前往瀏覽器設(shè)置 → 權(quán)限 → 通知將該網(wǎng)站改為允許”的步驟指引。如果是 Chrome可以嘗試通過navigator.permissions.query({ name: notifications })監(jiān)聽權(quán)限狀態(tài)變化用戶一旦在設(shè)置里把手動(dòng)改成允許頁面狀態(tài)能夠?qū)崟r(shí)感知并立刻更新 UI。這種細(xì)節(jié)看起來不起眼但對(duì)通知這種“權(quán)限敏感”的功能來說減少用戶從拒絕到挽回的每一步阻力都能顯著提升最終授權(quán)率。5.4 別忘了在移動(dòng)端的降級(jí)方案移動(dòng)端和桌面端是兩套不同的心智。移動(dòng)端更看重省電、省流量和勿擾很多用戶下意識(shí)會(huì)對(duì)通知說不。即便拿到了授權(quán)移動(dòng)瀏覽器的通知體驗(yàn)也遠(yuǎn)不如桌面端——Android 上系統(tǒng)會(huì)把網(wǎng)頁通知聚合到瀏覽器應(yīng)用的通知渠道下看起來跟普通 App 通知混在一起iOS 的限制則更嚴(yán)格一些。所以移動(dòng)端方案要做降級(jí)通知不可用時(shí)退回頁面內(nèi)小紅點(diǎn) 角標(biāo) 適時(shí)的 toast 提示。不要強(qiáng)制要求用戶開系統(tǒng)通知而是提供“站內(nèi)消息”的中心讓用戶根據(jù)自己的節(jié)奏查看。這種降級(jí)方案任何時(shí)候都比“強(qiáng)行引導(dǎo)用戶開通權(quán)限”更符合實(shí)際產(chǎn)品邏輯。收尾一點(diǎn)個(gè)人體會(huì)做通知功能這幾年最大的感受是Notification API 本身并不復(fù)雜復(fù)雜的是圍繞它的一整套體驗(yàn)設(shè)計(jì)。真正的難點(diǎn)其實(shí)在于三個(gè)維度權(quán)限鏈路怎么引導(dǎo)、消息內(nèi)容怎么克制、后臺(tái)和頁面的狀態(tài)怎么同步。我仍然記得第一次上線到生產(chǎn)環(huán)境時(shí)用戶反饋“通知彈了但點(diǎn)擊了沒反應(yīng)”后來查了很久才發(fā)現(xiàn)是waitUntil的 Promise 沒有處理好Service Worker 提前被終止導(dǎo)致點(diǎn)擊跳轉(zhuǎn)邏輯根本沒執(zhí)行完——這種問題不實(shí)際踩一遍坑很難想到。如果你準(zhǔn)備為自己的網(wǎng)頁接入系統(tǒng)通知我的建議是先在小范圍內(nèi)跑通完整鏈路權(quán)限、展示、點(diǎn)擊、跳轉(zhuǎn)、降級(jí)五個(gè)環(huán)節(jié)都驗(yàn)證一遍然后再考慮怎么推給全部用戶。Notification 是一把好用的工具但它終究只是工具決定它價(jià)值的是你的場景判斷和克制程度。希望這篇文章能幫你在接入它的路上少走幾個(gè)彎路。