Chrome扩展重启或浏览器关闭时是否存在可检测的回调方法

chrome.runtime.onSuspend无法触发的核心原因 #

这个事件的触发规则和大部分开发者的预期偏差极大，测不到是正常情况：

• 仅作用于非持久化后台上下文：也就是Manifest V3的Service Worker、Manifest V2中配置了persistent: false的事件页，持久化后台不会触发该事件。
• 触发时机完全由浏览器调度：只有当浏览器判定后台上下文无待执行任务、无活跃端口连接、无未完成回调时，才会在回收上下文前触发该事件，事件触发后仅预留极短时间执行同步逻辑，异步代码会被直接中断。
• 覆盖场景非常有限：浏览器正常退出、用户手动禁用/卸载扩展、扩展崩溃重启、系统强制结束浏览器进程这些场景下，该事件完全不会触发。

可落地的替代实现方案 #

• 检测扩展自身重启：不需要专门的事件回调，直接在后台上下文的顶层代码做判断即可。每次后台上下文启动（包括扩展重新加载、浏览器重启后扩展唤醒、Service Worker被回收后重新唤起）都会执行顶层代码，搭配本地存储记录上次运行时间，就能精准识别重启场景，参考代码：

// 后台Service Worker/事件页顶层执行
const runFlag = await chrome.storage.local.get('lastActiveAt');
if (runFlag.lastActiveAt) {
  // 此处编写扩展重启/重新唤醒后的业务逻辑
  console.log('扩展已重新启动，上次活跃时间：', new Date(runFlag.lastActiveAt));
}
// 实时更新活跃时间标记
chrome.storage.local.set({ lastActiveAt: Date.now() });

• 检测浏览器关闭：没有100%可靠的回调。最接近的方案是监听chrome.windows.onRemoved事件，判断关闭的是否为最后一个浏览器窗口，但如果用户开启了Chrome后台运行模式（允许扩展/网页应用在关闭窗口后继续运行），所有窗口关闭后浏览器进程不会退出，该判断会存在误差。
• 数据持久化/资源清理类需求：不要依赖任何关闭类回调，业务数据产生变更时即时写入chrome.storage，资源用完即时释放，不要等到上下文销毁时再统一处理，这类逻辑的执行成功率极低。

常见踩坑提示 #

• 不要通过定时器轮询、长连接保活等方式强行维持后台上下文存活，不仅在Manifest V3下会被浏览器强制回收，还可能违反扩展商店规则导致下架。
• 不要在onSuspend事件中执行异步请求、延时操作，上下文销毁时未执行完的任务会被直接终止，没有容错空间。

内容的提问来源于stack exchange，提问作者d-_-b