废弃卸载事件

Demián Renzulli
Demián Renzulli
X GitHub
Barry Pollard

发布时间：2023 年 8 月 10 日；上次更新时间：2026 年 4 月 28 日

unload 事件将逐步弃用，方法是逐步更改默认设置，使 unload 处理脚本在网页上停止触发，除非网页明确选择重新启用它们。

弃用时间表

早在 2019 年 1 月宣布打算实现往返缓存时，我们就指出卸载行为可能会发生变化。在实施工作的同时，我们进行了大规模的主动联系，这导致卸载使用情况显著下降。为了配合此次宣传活动，我们还开始提供一些方法来测试从 Chrome 115 中弃用 unload 的影响：

在 2024 年全年，我们解决了多项阻碍开始分阶段发布的问题；在 2025 年全年，我们针对前 50 个网站分阶段发布了弃用公告。

Milestone 里程碑日期 50 大网站 其他来源所占的百分比
135 2025 年 3 月 26 日 1（www.google.com） 0
139 2025 年 7 月 30 日 5 0
140 2025 年 8 月 27 日 10 0
141 2025 年 9 月 24 日 25 0
142 Oct 22, 2025 50 0
“热门 50 个网站”的弃用时间表。

现在，我们已完成对前 50 个网站的弃用，并获得了进一步的批准，将在 8 个里程碑（约 32 周）内将此功能推广到所有来源，详情如下表所示。

Milestone 里程碑日期 50 大网站 所有网站的 Chrome 网页加载次数所占的百分比
146 2026 年 3 月 10 日 50 1
147 2026 年 4 月 7 日 50 5
148 2026 年 5 月 5 日 50 10
149 2026 年 6 月 2 日 50 20
150 2026 年 6 月 30 日 50 40
151 2026 年 7 月 28 日 50 60
152 2026 年 8 月 25 日 50 80
153 2026 年 9 月 22 日 50 100
所有网站的弃用时间表。

全面推出是基于网页加载（随时间保持一致），而不是基于单个用户或网站，以避免对用户或网站造成比其他用户或网站更大的影响，如弃用意向中所述。

请注意，我们还提供了一个选择退出选项菜单，以防此弃用时间表无法提供足够的时间来从 unload 迁移。我们的目标是使用此软弃用来告知最后一个阶段（硬弃用 unload）的时间表，在该阶段中，这些选择停用功能将被移除或减少。

卸载弃用时间表。
unload 弃用时间表。

背景

unload 旨在在卸载文档时触发。从理论上讲，它可用于在用户离开网页时运行代码，也可作为会话结束回调。

此事件最常用于以下场景：

  • 保存用户数据：在离开网页之前保存数据。
  • 执行清理任务：在放弃网页之前关闭打开的资源。
  • 发送分析数据：在会话结束时发送与用户互动相关的数据。

不过，unload 事件非常不可靠。

在桌面版 Chrome 和 Firefox 中，unload 的可靠性尚可，但它会阻止使用 往返缓存 (bfcache)，从而对网站的性能产生负面影响。

在移动浏览器上，unload 通常不会运行，因为标签页经常会转到后台，然后被终止。因此，浏览器选择在移动设备上优先使用 bfcache 而不是 unload，这使得 unload 更加不可靠。Safari 也会在桌面设备上使用此行为。

Chrome 团队认为，在桌面设备上使用移动模式（即优先考虑 bfcache 而不是 unload）会造成干扰，因为这也会导致桌面设备上的 bfcache 变得更加不可靠，而之前 Chrome（和 Firefox）中的 bfcache 一直相当可靠。相反，Chrome 的目标是完全移除 unload 事件。在此之前，对于明确选择不弃用该功能的桌面版用户，该功能仍可正常使用。

为何弃用 unload 事件？

弃用 unload 是我们对当前网络环境进行更广泛认知的重要一步。unload 事件会给人一种对应用生命周期进行控制的虚假感觉，这与我们在现代计算世界中浏览网页的方式越来越不符。

移动操作系统经常会冻结或卸载网页以节省内存，而桌面浏览器现在也出于同样的原因而越来越频繁地执行此操作。即使没有操作系统干预，用户本身也经常在不正式“离开网页”的情况下切换标签页并关闭旧标签页。

移除过时的 unload 事件，表明我们作为 Web 开发者需要确保我们的范式与现实世界相符，而不是依赖不再成立的过时概念（即使它们曾经成立）。

unload 事件的替代方案

建议使用以下方法，而不是 unload：

  • visibilitychange：用于确定网页的可见性何时发生变化。当用户切换标签页、最小化浏览器窗口或打开新网页时，系统会触发此事件。考虑将 hidden 状态作为保存应用和用户数据的最后可靠时间。
  • pagehide：用于确定用户何时已离开网页。当用户离开页面、重新加载页面或关闭浏览器窗口时，系统会触发此事件。当网页最小化或切换到其他标签页时，不会触发 pagehide 事件。请注意，由于 pagehide 不会使网页不符合使用往返缓存的条件，因此网页可能会在此事件触发后恢复。如果您在此事件中清理了任何资源，则可能需要在页面恢复时恢复这些资源。

beforeunload 事件的应用场景与 unload 略有不同，因为它是可取消的事件。它通常用于在用户离开时警告用户有未保存的更改。此事件也不可靠，因为如果后台标签页被终止，此事件不会触发。建议限制 beforeunload 的使用，仅在有条件的情况下添加。请改用前面提及的事件来替换大多数 unload。

如需了解详情，请参阅有关切勿使用 unload 处理程序的建议。

检测 unload 的使用情况

您可以使用不同的工具来帮助您查找网页上出现的 unload 事件。这样一来，网站就可以发现自己是否在自己的代码中或使用库时使用了此事件，从而了解自己是否会受到即将到来的弃用的影响。

Chrome DevTools

Chrome 开发者工具包含 back-forward-cache 审核，可帮助您找出可能导致网页不符合往返缓存资格条件的问题，包括 unload 处理程序的使用情况。

如需测试往返缓存，请按以下步骤操作：

  1. 在网页上打开开发者工具，然后依次前往应用 > 后台服务 > 往返缓存。

  2. 点击测试往返缓存，Chrome 会自动将您带到 chrome://terms/，然后再返回到您的网页。或者，您也可以点击浏览器的后退和前进按钮。

如果您的网页不符合使用往返缓存的条件，往返缓存标签页会显示问题列表。在可操作下，您可以查看自己是否在使用 unload：

Chrome 开发者工具往返缓存测试工具显示使用了 unload 处理程序
Chrome 开发者工具的往返缓存测试工具。

Reporting API

Reporting API 可与只读权限政策结合使用，以检测网站用户对 unload 的使用情况。

如需了解详情，请参阅使用 Reporting API 查找卸载

Bfcache notRestoredReasons API

添加到 PerformanceNavigationTiming 类中的 notRestoredReasons 属性会报告有关文档是否因导航而被阻止使用 bfcache 的信息，以及被阻止的原因。以下示例展示了现有 unload 监听器的响应对象警告的显示方式：

{
   children: [],
   id: null,
   name: null,
   reasons: [
     {"reason", "unload-listener"}
   ],
   src: null,
   url: "https://www.example.com/page/"
}

控制对 unload 的访问权限

Chrome 将逐步弃用 unload 事件。在此期间，您可以使用不同的工具来控制此行为，并为即将到来的弃用做好准备。请注意，您不应长期依赖这些技术，而应尽快计划迁移到替代方案。

通过以下选项，您可以启用或停用 unload 处理程序，以测试您的网站在没有这些处理程序的情况下会如何运作，从而为即将到来的弃用做好准备。政策类型有多种：

  • 权限政策：这是一个平台 API，网站所有者可以使用 HTTP 标头在网站或单个网页级别控制对功能的访问权限。
  • 企业版政策：供 IT 管理员为组织或企业配置 Chrome 的工具。您可以使用管理员面板（例如 Google 管理控制台）来配置这些设置。
  • Chrome flag：这允许单个开发者更改 unload 弃用设置，以测试对各种网站的影响。

“权限”政策

自 Chrome 115 起，添加了一项权限政策，允许网站选择停用 unload 处理程序，并立即受益于 bfcache，从而提升网站性能。请参阅这些示例，了解如何为您的网站设置此属性。这样一来，网站就可以在 unload 被弃用之前做好准备。

Chrome 117 中对此进行了扩展，允许网站反向操作，即选择继续尝试触发 unload 处理程序（与现在一样），因为 Chrome 将来会更改这些处理程序的默认行为，使其不再触发。如需查看如何继续允许为您的网站触发卸载处理程序的示例，请点击此处。虽然我们建议网站所有者不要再使用 unload 处理程序，因为它们不太可靠，但我们计划在相当长的一段时间内支持需要使用此处理程序的网站选择停用。此外，重新选择启用该功能并不会使移动设备上的 unload 处理程序更可靠，只会恢复当前现状。

企业政策

如果企业有依赖于 unload 事件才能正常运行的软件，可以使用 ForcePermissionPolicyUnloadDefaultEnabled 政策来防止受其控制的设备逐步弃用该事件。启用此政策后，unload 将继续默认对所有来源处于启用状态。网页仍可根据需要设置更严格的政策。与权限政策选择退出类似，这也是一种用于缓解潜在重大变更的工具。我们再次建议网站所有者停止依赖 unload 处理程序，但 Chrome 计划在相当长的一段时间内支持此企业选择停用功能，以供需要使用它的网站使用。

Chrome flag 和命令行开关

除了企业政策之外，您还可以使用 Chrome 标志和命令行开关为个别用户停用弃用：

将此设置 chrome://flags/#deprecate-unload 为 enabled 会提前弃用默认设置，并防止 unload 处理程序触发。虽然仍可使用“权限”政策按网站逐个覆盖这些标头，但这些标头仍会默认触发。

这些设置也可以通过命令行开关来控制。

选项比较

下表总结了前面讨论的选项的不同用途：

提前弃用 提前弃用（有例外情况） 防止弃用，以确保有足够的时间进行迁移
“权限”政策
（适用于网页/网站）		 是 是 是
企业政策
（适用于设备）		 否 否 是
Chrome flag
（适用于个人用户）		 是 否 否
Chrome 命令行开关
（适用于个人用户）		 是 否 是

总结

unload 处理脚本即将被弃用。它们长期以来一直不可靠，并且无法保证在文档被销毁的所有情况下都能触发。此外，unload 处理程序与 bfcache 不兼容。

使用 unload 处理程序的网站应为即将到来的弃用做好准备，方法是测试是否存在任何现有的 unload 处理程序，移除或迁移它们，或者在需要更多时间的情况下，作为最后的手段，延迟弃用。

致谢

感谢 Kenji Baheux、Fergal Daly、Adriana Jara 和 Jeremy Wagner 帮助审核本文。

主打图片由 Unsplash 上的 Anja Bauermann 提供