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