Chrome扩展MV3 Service Worker为何需在事件循环首次轮次注册监听器？

背景 #

我正在将使用持久化Background Pages的MV2扩展迁移至MV3。Chrome迁移指南指出：为确保Chrome能将事件成功分发至对应监听器，扩展必须在事件循环的首次轮次注册监听器，最直接的方式是将事件注册移至Service Worker脚本的顶层。当Service Worker终止时，其关联的事件监听器也会终止；而事件在Service Worker启动时分发，异步注册监听器会导致事件因启动初期无监听器而丢失。

疑问 #

1. 为何必须如此注册？在异步操作后注册会有什么问题？
2. 既然‘Service Worker终止时其关联的事件监听器也会终止’，那么已终止的Service Worker为何能突然激活？（若监听器已终止，它应该无法监听事件）

解答 #

问题1：为什么必须在顶层注册监听器，异步注册有什么问题？ #

Chrome的Service Worker是按需启动、用完即销毁的，它不像MV2的Background Page那样一直驻留内存。当触发扩展相关事件（比如点击插件图标）时，Chrome会先启动Service Worker，然后尝试把事件分发给它。

如果你的监听器是在异步操作（比如chrome.storage.local.get的回调）里注册的，Service Worker启动后的第一轮事件循环里根本没有这个监听器。Chrome在启动Service Worker后，会立刻检查有没有对应事件的监听器——如果此时没有，它就会认为这个Service Worker不需要处理该事件，甚至可能直接终止它，导致后续异步回调里的监听器根本没机会生效，事件直接丢失。

举个实际场景：用户点击插件图标，Chrome启动你的Service Worker，脚本开始执行后先发起chrome.storage.local.get请求，这个请求是异步的，会被放到任务队列里排队。而Chrome此时已经在分发chrome.action.onClicked事件了，但此时还没注册任何监听器，这个事件就直接“浪费”了，等异步回调执行完注册监听器时，事件早就没影了。

问题2：已终止的Service Worker为什么能被激活？ #

这里要区分开两个东西：监听器的注册元数据和Service Worker的运行实例。

当你在Service Worker的顶层代码里注册监听器时，Chrome会把这个监听器的相关信息（比如监听的是哪个事件）保存成元数据，和你的扩展绑定在一起——这些元数据不会随着Service Worker实例的终止而消失。

当Service Worker实例终止后，这些元数据还存在Chrome那边。当对应的事件触发时，Chrome会查这个元数据：哦，这个扩展有监听这个事件的Service Worker，那我重新启动它的Service Worker实例，然后把事件分发给新启动的实例。新实例启动后会执行顶层代码，重新注册监听器，自然就能接住事件了。

说白了：终止的是Service Worker的运行进程，但监听事件的“登记信息”已经提前告诉Chrome了，所以Chrome知道要唤醒它来干活。

错误示例代码 #

// background.js(service worker)
chrome.storage.local.get(["badgeText"], ({ badgeText }) => {
  chrome.action.setBadgeText({ text: badgeText });

  // 异步注册的监听器，在MV3/Service Worker中无法保证生效！别这么做
  chrome.action.onClicked.addListener(handleActionClick);
});

正确写法示例 #

// background.js(service worker)
// 优先在顶层注册监听器，确保Chrome能识别到
chrome.action.onClicked.addListener(handleActionClick);

// 异步操作放在回调里执行，不影响监听器的注册时机
chrome.storage.local.get(["badgeText"], ({ badgeText }) => {
  chrome.action.setBadgeText({ text: badgeText });
});

function handleActionClick() {
  // 这里写点击插件图标后的处理逻辑
}

内容的提问来源于stack exchange，提问作者Kritidipto Ghosh