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 浏览器的采用情况另有说明。本推荐提供迁移阅读路径，不表示所有浏览器行为一致，也不是本站已经测试了你的应用。