废弃卸载事件

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

发布时间：2023 年 8 月 10 日；最后更新时间：2026 年 1 月 29 日

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 事件非常不可靠。

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

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

Chrome 团队认为，在桌面设备上使用优先考虑 bfcache 而不是 unload 的移动模式会造成干扰，因为这也会导致桌面设备上的可靠性降低，而之前 Chrome（和 Firefox）在这方面一直表现得相当可靠。相反，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 事件才能正常运行的软件，可以使用 ForcePermissionPolicyUnloadDefaultEnabled 政策来防止受其控制的设备逐步弃用该事件。启用此政策后，unload 将继续默认对所有来源处于启用状态。网页仍可根据需要设置更严格的政策。与权限政策选择停用类似，此工具可用于缓解潜在的重大变更，但不应无限期使用。

Chrome 标志和命令行开关

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

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

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

选项比较

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

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

总结

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

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

致谢

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

主打图片提供者：Anja Bauermann；来源：Unsplash