Chrome 預設停用 unload 後，網站該檢查什麼

不要等到關頁面才保存重要狀態

Barry Pollard 與 Fergal Daly 在公告中說明，Chrome 從 155 起已完成預設停用 unload。值得讀的原因很具體：手機上的後台頁面可能被系統直接回收，來不及運行最後一個事件；unload 監聽器還曾阻礙前進後退快取。把關鍵保存邏輯押在關閉標籤頁的一刻，本來就不可靠。

先讀公告，再檢查自己的頁面

從原始公告了解變化，再按關聯的遷移文件盤點業務代碼與第三方庫中的監聽器。官方文件建議利用頁面變為隱藏時的 visibilitychange 保存狀態，以 pagehide 處理導航相關清理，並在快取恢復頁面時恢復必要資源。beforeunload 適合按條件提示未保存修改，不是所有 unload 邏輯的通用替代品。

下面這張官方文件截圖展示 DevTools 的前進後退快取檢查如何指出 unload 阻礙。它是文件範例，不是對 Boloop 的審計結果，也不證明當前任意頁面都有該問題。

在自己維護的頁面打開 DevTools，進入 Application → Background services → Back/forward cache，使用 Test back/forward cache。記錄真實阻礙，改動後復測相關流程；不能僅憑刪除一個監聽器就宣稱效能提升。

公告保留了例外：iOS 上的 Chrome 使用 WebKit，站點或企業顯式選擇保留舊行為時也可能繼續收到事件；其他 Chromium 瀏覽器的採用情況另有說明。本推薦提供遷移閱讀路徑，不表示所有瀏覽器行為一致，也不是本站已經測試了你的應用。