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