Notification API 剛出來那幾年我一直覺得它就是個(gè)“錦上添花”的小功能網(wǎng)頁(yè)能彈個(gè)系統(tǒng)通知看著挺酷但真正想依賴它做業(yè)務(wù)提醒總覺得不太靠譜。直到后來在幾個(gè)實(shí)際項(xiàng)目里被迫認(rèn)真啃了一遍才意識(shí)到這個(gè) API 遠(yuǎn)比想象中有分量。尤其是當(dāng)你做的是內(nèi)部運(yùn)營(yíng)系統(tǒng)、工單平臺(tái)、預(yù)約提醒這類產(chǎn)品時(shí)用戶關(guān)掉頁(yè)面后還能收到消息提醒體驗(yàn)上完全是兩個(gè)檔次。這篇文章我就圍繞“瀏覽器 APINotification實(shí)現(xiàn)系統(tǒng)通知”這個(gè)主題把權(quán)限申請(qǐng)、通知參數(shù)、生命周期、業(yè)務(wù)集成、踩坑排查從頭到尾捋一遍。不管你是剛接觸前端的小白還是已經(jīng)在項(xiàng)目里接過通知功能但被各種兼容性問題折騰過的開發(fā)者這篇文章應(yīng)該都能給你一些直接用得上的參考。1. 權(quán)限鏈路先搞懂為什么用戶必須手動(dòng)點(diǎn)一下才能彈通知1.1 Notification API 的權(quán)限模型與狀態(tài)流轉(zhuǎn)Notification API 最大的特點(diǎn)是它不在網(wǎng)頁(yè)內(nèi)部展示內(nèi)容而是直接調(diào)用操作系統(tǒng)層面的通知能力所以瀏覽器對(duì)它的管控非常嚴(yán)格。這個(gè) API 的核心入口是Notification.permission它只有三個(gè)值granted、denieddefault。很多人一開始會(huì)忽略default這個(gè)狀態(tài)實(shí)際上它才是大多數(shù)新用戶首次訪問頁(yè)面時(shí)的默認(rèn)值含義是“用戶還沒有做過任何決定”。整個(gè)權(quán)限模型是這樣的頁(yè)面加載后Notification.permission是default此時(shí)調(diào)用Notification.requestPermission()瀏覽器會(huì)彈出授權(quán)詢問框用戶點(diǎn)擊“允許”后變成granted點(diǎn)擊“屏蔽”或“不允許”后變成denied。一旦變成denied當(dāng)前站點(diǎn)在絕大多數(shù)瀏覽器里就基本沒有挽回余地了再調(diào)用requestPermission()也不會(huì)彈出授權(quán)框而是直接返回denied控制臺(tái)會(huì)提示用戶已在設(shè)置里屏蔽了該站點(diǎn)的通知權(quán)限。這里有個(gè)關(guān)鍵點(diǎn)requestPermission()必須由用戶主動(dòng)手勢(shì)觸發(fā)。什么意思就是你不能在頁(yè)面加載后立刻執(zhí)行這句代碼而是應(yīng)該把它放在按鈕點(diǎn)擊、表單提交這類由用戶操作引發(fā)的事件回調(diào)里。瀏覽器這樣設(shè)計(jì)是因?yàn)橥ㄖ獧?quán)限屬于高打擾能力如果任何網(wǎng)站都能在后臺(tái)靜默申請(qǐng)權(quán)限那整個(gè)互聯(lián)網(wǎng)的通知欄很快就變成廣告位了。我在項(xiàng)目里就犯過這個(gè)錯(cuò)誤想在頁(yè)面初始化時(shí)直接申請(qǐng)權(quán)限結(jié)果在部分瀏覽器中彈窗直接被攔甚至有的瀏覽器干脆靜默失敗連個(gè)報(bào)錯(cuò)都沒有。排查了很久才發(fā)現(xiàn)是調(diào)用時(shí)機(jī)不對(duì)。1.2 權(quán)限申請(qǐng)的正確姿勢(shì)與降級(jí)方案正確的權(quán)限申請(qǐng)流程應(yīng)該是這樣先判斷當(dāng)前狀態(tài)如果是granted直接初始化通知能力如果是default在用戶點(diǎn)擊某個(gè)功能按鈕時(shí)再?gòu)椛暾?qǐng)如果是denied界面上要給用戶一個(gè)明確的指引引導(dǎo)他們?nèi)g覽器設(shè)置里手動(dòng)打開通知權(quán)限而不是反復(fù)調(diào)用 API。寫代碼的時(shí)候可以封裝成一個(gè) Promise方便在業(yè)務(wù)里等待用戶的選擇結(jié)果async function ensureNotificationPermission() { if (!(Notification in window)) { return { supported: false, permission: unsupported }; } if (Notification.permission granted) { return { supported: true, permission: Notification.permission }; } if (Notification.permission denied) { return { supported: true, permission: Notification.permission }; } const permission await Notification.requestPermission(); return { supported: true, permission }; }調(diào)用的時(shí)候把它掛在一個(gè)明確的用戶動(dòng)作后面比如“開啟消息提醒”按鈕。不要放在路由切換、定時(shí)器回調(diào)這些非用戶手勢(shì)的上下文里。此外還需要注意在部分瀏覽器里requestPermission()返回的是一個(gè) Promise但在舊版的 Safari 里它需要回調(diào)函數(shù)寫法上建議用Promise.resolve()包一層或者干脆做一次兼容處理把兩種方式都覆蓋到避免老設(shè)備上白屏報(bào)錯(cuò)。在實(shí)際業(yè)務(wù)里用戶拒絕權(quán)限后不要直接放棄可以做一個(gè)“引導(dǎo)開啟”的浮層告訴用戶“通知權(quán)限被關(guān)閉了請(qǐng)前往瀏覽器設(shè)置中允許本站發(fā)送通知”。桌面端的 Chrome 和 Edge 里地址欄左側(cè)的站點(diǎn)信息圖標(biāo)可以快速進(jìn)入權(quán)限設(shè)置移動(dòng)端則在瀏覽器菜單里不同廠商入口稍有差異。這一層雖然不屬于 API 本身但能明顯減少用戶因?yàn)檎`操作屏蔽權(quán)限后流失的情況。2. 從 new Notification 到真正的系統(tǒng)通知核心細(xì)節(jié)拆解2.1 構(gòu)造函數(shù)與 Options 參數(shù)逐項(xiàng)說明拿到權(quán)限之后創(chuàng)建通知其實(shí)非常簡(jiǎn)單const notification new Notification(標(biāo)題內(nèi)容, { body: 這里是通知的正文內(nèi)容用于展示更詳細(xì)的信息, icon: https://example.com/icon.png, image: https://example.com/image.png, badge: https://example.com/badge.png, tag: order-10086, renotify: true, requireInteraction: true, silent: false, data: { orderId: 10086, url: /orders/10086 }, dir: auto });標(biāo)題是第一個(gè)參數(shù)不能為空字符串否則部分瀏覽器會(huì)直接拋異常。第二個(gè)參數(shù)的 Options 對(duì)象里每個(gè)字段背后都有各自的適用場(chǎng)景我逐個(gè)說一下我在實(shí)際使用中的理解。body是通知正文不需要多說重點(diǎn)在于控制長(zhǎng)度。桌面系統(tǒng)一般會(huì)展示兩到三行超過部分會(huì)用省略號(hào)代替所以核心信息一定要放在開頭。icon是通知欄左側(cè)的圖標(biāo)通常建議使用 192px 以上的正方形 PNG帶透明背景效果更好如果用 JPEG 圖邊緣可能會(huì)顯得很生硬。badge則是在移動(dòng)端通知圖標(biāo)位置顯示的小徽章某些瀏覽器里只展示這個(gè)極簡(jiǎn)小圖標(biāo)所以它的視覺要求比icon更高盡量使用簡(jiǎn)單的幾何圖形縮小后仍然可辨識(shí)。image是大圖桌面 Chrome 和 Edge 支持可以展示在通知正文下方適合消息卡片、營(yíng)銷海報(bào)、數(shù)據(jù)截圖這類場(chǎng)景但 IE 和不支持的系統(tǒng)上會(huì)被忽略。tag這個(gè)字段極其關(guān)鍵。它是通知的分組標(biāo)識(shí)當(dāng)新建通知的 tag 與當(dāng)前已有未關(guān)閉通知的 tag 相同時(shí)瀏覽器會(huì)用新通知替換舊通知避免同一個(gè)會(huì)話的消息把系統(tǒng)通知欄刷爆。舉個(gè)例子用戶在聊天群里連續(xù)收到 20 條消息如果不設(shè)置 tag系統(tǒng)里就會(huì)出現(xiàn) 20 條通知設(shè)置了 tag 為chat-123新的通知會(huì)覆蓋舊的通知欄里始終只有一條并且會(huì)更新內(nèi)容。renotify配合tag使用設(shè)為true時(shí)替換通知會(huì)重新發(fā)出提示音和震動(dòng)否則替換時(shí)保持靜默。這里有個(gè)坑MDN 上明確說明只設(shè)置tag不設(shè)置renotify時(shí)替換是安靜的但如果你設(shè)置renotify: true卻不設(shè)置tag部分瀏覽器會(huì)忽略它因?yàn)楦緵]有可替換的舊通知。requireInteraction控制通知是否自動(dòng)消失。默認(rèn)情況下通知大約幾秒后自動(dòng)收起設(shè)為true后通知會(huì)一直留在屏幕上直到用戶手動(dòng)點(diǎn)擊或關(guān)閉適合那些不能錯(cuò)過的系統(tǒng)告警、訂單支付結(jié)果這類場(chǎng)景。代價(jià)就是用戶如果不手動(dòng)清理通知會(huì)一直占據(jù)屏幕空間所以要用在真正需要強(qiáng)提醒的場(chǎng)景別全程無腦開啟。silent是控制聲音和震動(dòng)的。如果同時(shí)使用requireInteraction: true和silent: true可以實(shí)現(xiàn)一個(gè)不打攪人但又不丟失的“桌面角標(biāo)”式通知。data字段用來掛載業(yè)務(wù)數(shù)據(jù)點(diǎn)擊通知后通過notification.data取回這個(gè)非常實(shí)用可以把頁(yè)面路徑、主鍵 ID 都放進(jìn)去。dir是文字方向除非做阿拉伯語(yǔ)、希伯來語(yǔ)等 RTL 適配否則用默認(rèn)的auto就夠了。2.2 事件監(jiān)聽與內(nèi)存管理創(chuàng)建出來的notification對(duì)象上有三個(gè)關(guān)鍵事件show、click、close還有一個(gè)error事件需要注意。show在通知顯示后觸發(fā)一般很少用到但可以用來統(tǒng)計(jì)通知到達(dá)率。click是最常用的用戶點(diǎn)擊通知后需要聚焦到對(duì)應(yīng)的頁(yè)面、跳轉(zhuǎn)路由或打開某個(gè)鏈接。這里有一個(gè)非常重要的細(xì)節(jié)在click事件回調(diào)里調(diào)用window.focus()并不能保證把瀏覽器窗口切換到前臺(tái)你需要用window.parent.focus()或直接操作某個(gè)可聚焦的 DOM 元素必要時(shí)配合window.open()打開新標(biāo)簽頁(yè)。close在通知被關(guān)閉或替換時(shí)觸發(fā)適合做一些清理和埋點(diǎn)。事件綁定要和通知對(duì)象生命周期配合起來const notification new Notification(新訂單, { body: 訂單 #10086 待處理, tag: order-10086, data: { url: /orders/10086 } }); notification.onclick (event) { event.preventDefault(); const targetUrl notification.data.url || /; window.open(targetUrl, _blank); notification.close(); }; notification.onclose () { console.log(通知已關(guān)閉); }; notification.onerror (err) { console.error(通知發(fā)生錯(cuò)誤, err); };內(nèi)存方面要注意如果頁(yè)面上生成了大量通知對(duì)象一定要在不再需要時(shí)調(diào)用notification.close()釋放否則通知即使是系統(tǒng)層面的瀏覽器側(cè)的對(duì)象引用也會(huì)堆積占用內(nèi)存。尤其在使用tag自動(dòng)替換時(shí)被替換掉的舊通知對(duì)象需要手動(dòng) close否則它的引用不會(huì)自動(dòng)清除。2.3 不同瀏覽器/平臺(tái)的行為差異這里直接給一張我在項(xiàng)目里整理過的對(duì)比表能省掉不少排查時(shí)間平臺(tái)行為特征說明桌面 Chrome / Edge支持 icon、image、badge、tag、renotify整體支持最完整通知可被瀏覽器自身管理桌面 Firefox支持大部分字段但不支持 image 大圖大圖會(huì)在代碼里合法但被忽略macOS Safari需注意證書與用戶手勢(shì)限制權(quán)限申請(qǐng)邏輯較嚴(yán)格不支持部分現(xiàn)代字段iOS Safari不支持 Web Notification只能通過 iOS 特有的 Web Push 配合主屏幕 Web App 使用安卓 Chrome支持 icon、badge通知樣式由系統(tǒng)決定需要 HTTPS 環(huán)境否則 API 直接不可用Windows 10/11通知走系統(tǒng)通知中心需要開啟系統(tǒng)的“專注助手”不會(huì)攔截通知否則會(huì)被折疊經(jīng)常會(huì)遇到的場(chǎng)景是同一個(gè)項(xiàng)目在 Chrome 上測(cè)試非常好到了 Firefox 上 image 不顯示排查半天發(fā)現(xiàn)根本不是代碼問題而是平臺(tái)差異。所以做兼容性測(cè)試的時(shí)候不能只看一兩個(gè)瀏覽器就收工至少要覆蓋目標(biāo)用戶最常用的那兩三個(gè)。3. 實(shí)操過程搭一個(gè)可復(fù)用的系統(tǒng)消息通知模塊3.1 模塊設(shè)計(jì)與狀態(tài)初始化說了這么多理論直接落地一個(gè)項(xiàng)目里可以直接復(fù)用的通知模塊。先設(shè)計(jì)整體結(jié)構(gòu)模塊需要在頁(yè)面加載時(shí)完成權(quán)限狀態(tài)探測(cè)提供requestPermission、send、click綁定等方法同時(shí)統(tǒng)一處理瀏覽器兼容和錯(cuò)誤降級(jí)。第一步是初始化const NotificationCenter { supported: Notification in window, permission: Notification.permission, init() { if (!this.supported) return; this.permission Notification.permission; return this; }, async ensurePermission() { if (!this.supported) return false; if (this.permission granted) return true; if (this.permission denied) return false; const result await Notification.requestPermission(); this.permission result; return result granted; }, send({ title, body, tag, icon, image, data, silent, requireInteraction }) { if (!this.supported || this.permission ! granted) return null; const options { body, tag, icon, image, data }; if (typeof silent boolean) options.silent silent; if (typeof requireInteraction boolean) options.requireInteraction requireInteraction; try { const notification new Notification(title, options); return notification; } catch (err) { console.error(通知?jiǎng)?chuàng)建失敗, err); return null; } } }; NotificationCenter.init();有幾點(diǎn)要說清楚。init()在頁(yè)面加載時(shí)就執(zhí)行但ensurePermission()必須放到用戶點(diǎn)擊事件里調(diào)用不要在init里彈授權(quán)。代碼里所有創(chuàng)建通知的操作都用 try 包裹因?yàn)榫退銠?quán)限是granted也可能因?yàn)橄到y(tǒng)通知服務(wù)被關(guān)閉、參數(shù)非法等原因拋出異常不能讓它打斷頁(yè)面主流程。創(chuàng)建失敗時(shí)返回null業(yè)務(wù)側(cè)可以用這個(gè)返回值決定是否降級(jí)到頁(yè)面內(nèi)彈窗。3.2 場(chǎng)景實(shí)戰(zhàn)訂單提醒與消息聚合一個(gè)比較典型的業(yè)務(wù)場(chǎng)景是訂單后臺(tái)。每當(dāng)有用戶提交了新訂單如果運(yùn)營(yíng)人員沒停留在頁(yè)面上一條系統(tǒng)通知能有效提升響應(yīng)速度。這時(shí)可以這樣用async function onNewOrder(order) { const hasPermission await NotificationCenter.ensurePermission(); if (!hasPermission) { // 降級(jí)方案頁(yè)面頂部展示紅色提示條 showInPageAlert(新訂單 ${order.no} 待處理); return; } NotificationCenter.send({ title: 新訂單 ${order.no}, body: 客戶${order.customerName}金額${order.amount}元, tag: order-${order.id}, icon: /images/order-icon.png, data: { url: /orders/${order.id} }, requireInteraction: true, silent: false }); }再?gòu)?fù)雜一點(diǎn)的場(chǎng)景是消息聚合。當(dāng)某個(gè)會(huì)話短時(shí)間內(nèi)有多條新消息時(shí)沒必要每次都彈新通知正確做法是使用固定 tag 配合更新 bodyfunction notifyNewMessage({ chatId, latestMessage, unreadCount }) { const title unreadCount 1 ? ${unreadCount} 條新消息 : 來自 ${latestMessage.sender} 的新消息; NotificationCenter.send({ title, body: latestMessage.content, tag: chat-${chatId}, icon: /images/chat-icon.png, data: { url: /chats/${chatId} }, requireInteraction: false, silent: false }); }這樣用戶在一個(gè)會(huì)話里連續(xù)收到 10 條消息通知欄始終只有一條點(diǎn)擊后直達(dá)會(huì)話頁(yè)。我在實(shí)際項(xiàng)目里測(cè)試過如果不做聚合用戶在群里聊十分鐘通知欄能堆出幾十條通知體驗(yàn)非常糟糕。3.3 配合 Service Worker讓通知在頁(yè)面關(guān)閉后依然可達(dá)Notification API 真正的威力不在頁(yè)面存活期間彈通知而是配合 Service Worker 實(shí)現(xiàn)離線推送。基本鏈路是頁(yè)面注冊(cè) Service Worker通過訂閱接口拿到推送憑證服務(wù)端在需要提醒時(shí)把消息推給瀏覽器Service Worker 收到后調(diào)用self.registration.showNotification()顯示系統(tǒng)通知。Service Worker 里的事件監(jiān)聽比較標(biāo)準(zhǔn)self.addEventListener(push, (event) { const payload event.data ? event.data.json() : {}; const options { body: payload.body || , icon: payload.icon || /default-icon.png, badge: payload.badge || /badge.png, tag: payload.tag || push-default, data: payload.data || {} }; event.waitUntil( self.registration.showNotification(payload.title || 新消息, options) ); }); self.addEventListener(notificationclick, (event) { event.notification.close(); const url event.notification.data.url || /; event.waitUntil( clients.matchAll({ type: window, includeUncontrolled: true }) .then((windowClients) { for (const client of windowClients) { if (focus in client) { return client.navigate(url).then((client) client.focus()); } } return clients.openWindow(url); }) ); });注意這里有個(gè)細(xì)節(jié)showNotification()只能由 Service Worker 調(diào)用頁(yè)面里創(chuàng)建的 Notification 對(duì)象不能直接被 Service Worker 引用兩條鏈路是獨(dú)立的。如果項(xiàng)目既有“用戶在頁(yè)面內(nèi)”時(shí)的通知場(chǎng)景又有“頁(yè)面關(guān)閉”后的推送場(chǎng)景兩套邏輯需要分開維護(hù)但最終展示的形式都是系統(tǒng)通知所以之前說的 Options 參數(shù)經(jīng)驗(yàn)在 Service Worker 里完全適用。3.4 生產(chǎn)環(huán)境必需條件HTTPS 與站點(diǎn)配置這一點(diǎn)我放到實(shí)操章節(jié)的最后說是怕一開始說太多容易勸退新手但它確實(shí)非常重要Notification API 在絕大多數(shù)主流瀏覽器中都被歸類為“強(qiáng)大功能”它要求頁(yè)面運(yùn)行在安全上下文HTTPS中。本地開發(fā)時(shí)localhost被視為安全上下文可以正常調(diào)試但一旦部署到內(nèi)網(wǎng)或測(cè)試服如果站點(diǎn)還是 HTTPNotification in window雖然返回 true但requestPermission()會(huì)直接失敗或者根本不彈框。解決思路無非是兩條一是生產(chǎn)環(huán)境統(tǒng)一走 HTTPS內(nèi)部管理系統(tǒng)可以自建證書成本不高二是如果實(shí)在沒有 HTTPS 條件就得放棄原生的 Notification API降級(jí)到頁(yè)面內(nèi)自定義彈窗或者 WebSocket 消息提醒不能硬撐。我見過一個(gè)團(tuán)隊(duì)把 HTTP 部署的前端項(xiàng)目做完才發(fā)現(xiàn)通知功能在正式環(huán)境完全不可用最后返工加了證書浪費(fèi)了不少時(shí)間。提前確認(rèn)這一點(diǎn)能省掉很多無謂的調(diào)試成本。4. 常見問題與排查技巧實(shí)錄4.1 問題速查表把我在項(xiàng)目中真正遇到過的、以及身邊同事踩過的常見坑整理成了一張速查表遇到問題時(shí)可以先對(duì)照自查現(xiàn)象可能原因排查方式與解法頁(yè)面加載后沒有彈授權(quán)框requestPermission()不在用戶手勢(shì)回調(diào)里將申請(qǐng)邏輯移到按鈕點(diǎn)擊、表單提交事件中調(diào)用requestPermission()后直接返回denied用戶之前在設(shè)置里屏蔽過權(quán)限提示用戶去瀏覽器設(shè)置里重新允許無法代碼強(qiáng)制更改新通知彈出但立即消失未設(shè)置requireInteraction系統(tǒng)默認(rèn)自動(dòng)收起對(duì)重要通知設(shè)置requireInteraction: true連續(xù)多條消息刷爆通知欄未設(shè)置tag或設(shè)置了不同的 tag同一會(huì)話/訂單使用固定 tag 聚合通知點(diǎn)擊通知沒有跳轉(zhuǎn)或沒有聚焦未處理notificationclick事件或窗口 focus 邏輯有問題綁定click事件用window.open或clients.openWindow處理有g(shù)ranted權(quán)限但通知不顯示系統(tǒng)通知服務(wù)被關(guān)閉或?qū)Ｗ⒅珠_啟檢查系統(tǒng)設(shè)置關(guān)閉專注助手測(cè)試系統(tǒng)通知本身是否可用在部分瀏覽器上image不顯示該瀏覽器不支持通知大圖降級(jí)設(shè)計(jì)把重要圖片信息放到 body 或 icon 中授權(quán)后打開新標(biāo)簽頁(yè)通知又要求重新授權(quán)瀏覽器按源origin隔離權(quán)限確認(rèn)通知權(quán)限綁定的是源而不是標(biāo)簽頁(yè)不需要重新授權(quán)可能是開發(fā)者工具屏蔽了權(quán)限r(nóng)enotify: true不生效未設(shè)置tag或 tag 與之前的通知不一致必須讓新通知攜帶與舊通知相同的 tag 才能替換并重新提醒iOS Safari 完全無法使用 NotificationiOS 不支持 Web Notification API使用 iOS 的 Web Push 能力或降級(jí)為應(yīng)用內(nèi)提醒4.2 我踩過的三個(gè)比較隱蔽的坑上面表格是概括性的這里展開說說我印象最深的三次排障經(jīng)歷每次排查的過程都挺磨人的。第一次是“通知在 Chrome 上不顯示”。權(quán)限狀態(tài)確實(shí)是granted代碼執(zhí)行也沒有報(bào)錯(cuò)但通知就是不出來。后來在系統(tǒng)右下角操作中心里發(fā)現(xiàn)了被折疊的通知——Windows 10 的“專注助手”會(huì)在特定時(shí)段攔截所有通知把它們靜默收進(jìn)操作中心。這個(gè)問題不是代碼能解決的需要引導(dǎo)用戶關(guān)閉專注助手或把站點(diǎn)加入例外列表。第二次是“點(diǎn)擊通知無法跳轉(zhuǎn)”。當(dāng)時(shí)寫了notification.onclick () { location.href /xxx }在 Chrome 里測(cè)試正常結(jié)果放到某款國(guó)產(chǎn)瀏覽器里就成了“點(diǎn)擊無效”。排查后發(fā)現(xiàn)這個(gè)瀏覽器對(duì) location.href 的頁(yè)面跳轉(zhuǎn)做了限制從通知點(diǎn)擊進(jìn)入的上下文里不能直接修改當(dāng)前頁(yè)面地址。后來統(tǒng)一改用window.open(url, _blank)問題就解決了。第三次是“通知在頁(yè)面刷新后權(quán)限狀態(tài)丟失”?，F(xiàn)象是用戶明明點(diǎn)擊了允許刷新頁(yè)面后又變成default。排查發(fā)現(xiàn)是因?yàn)闉g覽器開發(fā)者工具測(cè)試時(shí)把“重新加載時(shí)清除權(quán)限”選項(xiàng)打開了真實(shí)環(huán)境中并不存在這個(gè)問題。但當(dāng)時(shí)差點(diǎn)讓我以為 API 的權(quán)限不持久花了不少時(shí)間翻文檔。這里也提醒大家在做權(quán)限相關(guān)調(diào)試時(shí)先確認(rèn)開發(fā)者工具里的設(shè)置沒有干擾項(xiàng)。4.3 本地調(diào)試與真機(jī)驗(yàn)證建議Notification 的調(diào)試難度在于它是系統(tǒng)級(jí) UI普通的前端調(diào)試面板無法完全模擬。我現(xiàn)在的習(xí)慣是先寫一個(gè)最簡(jiǎn)頁(yè)面只包含一個(gè)按鈕點(diǎn)擊后申請(qǐng)權(quán)限并立即彈一條通知用這個(gè)頁(yè)面排除業(yè)務(wù)代碼干擾快速驗(yàn)證環(huán)境是否支持。確認(rèn)這條鏈路通了之后再逐步往項(xiàng)目里集成。在 Chrome DevTools 的 Application 面板里可以手動(dòng)清空通知權(quán)限隨時(shí)重置回default方便反復(fù)測(cè)試授權(quán)流程。Firefox 則需要在 about:preferences 的隱私與安全分類里手動(dòng)移除站點(diǎn)權(quán)限。每輪測(cè)試都要覆蓋三種狀態(tài)首次訪問的default、允許后的granted、拒絕后的denied以及“先允許后手動(dòng)改回拒絕”的過渡狀態(tài)確保 UI 上對(duì)應(yīng)的引導(dǎo)文案正確顯示。真機(jī)測(cè)試的注意事項(xiàng)也不少。安卓端不同廠商的瀏覽器對(duì) Notification 的樣式和交互支持存在差異尤其是小米、華為、OPPO 等自帶瀏覽器權(quán)限管理入口五花八門彈出權(quán)限框的樣式也不一樣。如果項(xiàng)目目標(biāo)用戶里有相當(dāng)比例使用手機(jī)瀏覽器務(wù)必要拿真機(jī)一臺(tái)一臺(tái)測(cè)過去。單純依賴桌面模擬器是遠(yuǎn)遠(yuǎn)不夠的。5. 合理使用 Notification 的幾條個(gè)人體會(huì)回想這個(gè) API 的使用過程我最深的感受是Notification 本身不難難的是把它嵌入到真實(shí)業(yè)務(wù)場(chǎng)景時(shí)各種平臺(tái)限制和用戶預(yù)期都在挑戰(zhàn)你。這里分享幾條自己在項(xiàng)目里總結(jié)出來的原則。第一不要把通知當(dāng)成唯一的信息觸達(dá)渠道。系統(tǒng)通知天然會(huì)被用戶關(guān)閉、被系統(tǒng)折疊、被平臺(tái)限制它應(yīng)該是提醒鏈路里最顯眼的一環(huán)但絕不能是唯一的一環(huán)。我在設(shè)計(jì)通知模塊時(shí)都會(huì)同步保留頁(yè)面內(nèi)提醒的能力根據(jù)權(quán)限狀態(tài)自動(dòng)降級(jí)確保用戶關(guān)掉通知權(quán)限后業(yè)務(wù)消息仍然可以通過站內(nèi)信或頁(yè)面彈窗觸達(dá)。第二尊重用戶的注意力。requireInteraction: true一定要慎用每一條常駐通知都在消耗用戶對(duì)產(chǎn)品的耐心。通知的文案要直接給出結(jié)論不要用“您的訂單有更新”這種廢話直接說“訂單 #10086 已發(fā)貨順豐單號(hào) SF1234567890”才是有效的通知。沒用的通知比沒有通知更讓人反感。第三權(quán)限申請(qǐng)一定要選對(duì)時(shí)機(jī)。不要把“開啟通知”這個(gè)請(qǐng)求放在用戶剛進(jìn)入頁(yè)面的時(shí)候也不要在用戶還沒有體驗(yàn)到產(chǎn)品價(jià)值前就急著索要權(quán)限。更好的時(shí)機(jī)是在用戶完成了一次關(guān)鍵操作之后比如創(chuàng)建了一個(gè)訂單、設(shè)置了一個(gè)預(yù)約、加入了一個(gè)會(huì)話這時(shí)候用戶對(duì)“后續(xù)要有提醒”是有預(yù)期的授權(quán)通過率會(huì)明顯更高。第四用 tag 做聚合是 Notification API 里最值得投入的設(shè)計(jì)。我之前在一個(gè)即時(shí)通信 Web 端里做過一次統(tǒng)計(jì)做了 tag 聚合之后通知欄消息條數(shù)降低了 80% 以上用戶對(duì)通知功能的吐槽也幾乎消失了。凡是可能高頻觸發(fā)的通知場(chǎng)景都應(yīng)該設(shè)計(jì)好 tag 策略。最后如果團(tuán)隊(duì)里同時(shí)有前端和服務(wù)端同學(xué)建議把 Notification 的權(quán)限鏈路、參數(shù)規(guī)劃、通知模板、降級(jí)方案沉淀成一份文檔因?yàn)檫@里涉及的不只是前端 API 調(diào)用還牽扯 Service Worker 的推送證書、服務(wù)器端消息簽名、系統(tǒng)權(quán)限設(shè)置引導(dǎo)文案這些跨端協(xié)作的內(nèi)容。把流程定清楚后續(xù)每次接入新業(yè)務(wù)場(chǎng)景都會(huì)輕松很多。