扩展程序 Service Worker 既可响应标准 Service Worker 事件，也可响应扩展程序命名空间中的事件。之所以将它们放在一起，是因为在使用扩展程序期间，一种类型通常会紧跟着另一种类型。
安装
当用户从 Chrome 应用商店安装或更新 Service Worker，或者用户使用 chrome://extensions 页面加载或更新已解压的扩展程序时，就会发生安装。按以下顺序发生三个事件。
ServiceWorkerRegistration.install
安装期间触发的第一个事件是 Web Service Worker 的 install 事件。
chrome.runtime.onInstalled
接下来是该扩展程序的 onInstalled 事件，当该扩展程序（而不是 Service Worker）首次安装时、该扩展程序更新到新版本以及 Chrome 更新到新版本时，都会触发该事件。使用此事件来设置状态或一次性初始化，例如上下文菜单。
chrome.runtime.onInstalled.addListener((details) => {
if(details.reason !== "install" && details.reason !== "update") return;
chrome.contextMenus.create({
"id": "sampleContextMenu",
"title": "Sample Context Menu",
"contexts": ["selection"]
});
});
ServiceWorkerRegistration.active
最后，系统将触发 Service Worker 的 activate 事件。请注意，与 Web Service Worker 不同，此事件会在安装扩展程序后立即触发，因为没有与扩展程序中的页面重新加载相媲美的功能。
扩展程序启动
当用户个人资料启动时，会触发 chrome.runtime.onStartup 事件，但不会调用任何 Service Worker 事件。
空闲和关停
通常，Chrome 会在满足以下条件之一时终止 Service Worker：
- 无操作 30 秒后。收到事件或调用扩展程序 API 会重置此计时器。
- 单个请求（例如事件或 API 调用）的处理用时超过 5 分钟。
- 当
fetch()响应的传递时间超过 30 秒时。
事件和对扩展程序 API 的调用会重置这些计时器，如果 Service Worker 已休眠，传入事件将使它们恢复。不过，您应该将 Service Worker 设计为能够灵活应对意外终止。
要优化扩展程序的资源消耗量，请尽可能避免让 Service Worker 无限期地保持活跃状态。测试您的扩展程序，确保您不会在无意中执行此操作。
保留数据而不是使用全局变量
如果 Service Worker 关闭，您设置的任何全局变量都将丢失。将值保存到存储空间，而不是使用全局变量。您的选项如下所示。请注意，Web Storage API 不适用于扩展程序 Service Worker。
- chrome.storage API
- 一种扩展程序 API，提供多种存储类型；本地存储、会话存储、托管（网域）和同步存储。此 API 用于存储使用开发者定义的密钥识别和检索的 JSON 对象。当用户清除网页缓存时，此类存储空间不会移除。
- IndexedDB API
- 用于在客户端存储结构化数据（包括文件和 blob）的低级别 API。此 API 提供了用于创建事务型数据存储和检索的原语。虽然此 API 通常对于简单的使用场景而言过于复杂，但在此基础上构建了许多第三方存储解决方案。
- CacheStorage API
- 请求和响应对象对的永久性存储机制。此 API 专为 Web Service Worker 设计，用于从端点检索数据。可通过多种方式使用此 API，具体取决于用户是否查看最新数据及其重要性。有关详情，请参阅离线指南。除非您专门通过提取处理程序来代理网络请求，否则应使用
chrome.storage。
选择最低 Chrome 版本
自 Manifest V3 发布以来，我们对 Service Worker 的生命周期进行了多项改进。这意味着，如果您的 Manifest V3 扩展程序支持较低版本的 Chrome，则您需要注意某些情况。如果这些情况不会影响您的扩展程序，您可以在此部分继续操作。如果支持，请考虑在清单中指定最低 Chrome 版本。
Chrome 120
现在可以将闹钟设置为一个最短 30 秒的时间段，以匹配 Service Worker 生命周期。如需了解详情，请参阅 chrome.alarms。
Chrome 118
使用 chrome.debugger API 创建的活跃调试程序会话现在会使 Service Worker 保持活跃状态。这可以防止 Service Worker 在调用此 API 期间超时。
Chrome 116
Chrome 116 引入了以下 Service Worker 生命周期改进：
活跃
WebSocket连接现在可延长扩展程序 Service Worker 的生命周期。在扩展程序 Service Worker 中通过WebSocket发送或接收消息会重置 Service Worker 的空闲计时器。其他扩展程序 API 可以超过扩展程序 Service Worker 的五分钟超时期限。这些 API 会显示一条用户提示，因此解析可能需要 5 分钟以上。其中包括
desktopCapture.chooseDesktopMedia()、identity.launchWebAuthFlow()、management.uninstall()和permissions.request()。
Chrome 浏览器 114
使用长期消息传递发送消息会让 Service Worker 保持活跃状态。以前，打开端口会重置计时器，但发送消息不会。打开端口不会再重置计时器。
Chrome 浏览器 110
Extension API 调用会重置计时器。在此之前，仅运行事件处理脚本会使 Service Worker 保持活动状态。任何已加入队列但未调用处理程序的事件都不会导致重置。
Chrome 109
通过屏幕外文档发送的消息会重置计时器。
Chrome 105
使用 chrome.runtime.connectNative() 连接到原生消息传递主机会使 Service Worker 保持活跃状态。如果主机进程崩溃或关闭，端口会关闭，Service Worker 将在计时器完成后终止。可通过在端口的 onDisconnect 事件处理脚本中调用 chrome.runtime.connectNative() 来防范此问题。