Service Worker 生命周期可确保安装和更新过程可预测， 这会使本地开发周期略微微妙。
在典型的本地开发周期中，开发者将对文件所做的更改保存到文本编辑器中， 然后切换到浏览器以验证更改，系统会重复此过程。 当混合使用一个 Service Worker 时，这个循环大致是相同的， 但开发者的期望和浏览器的行为可能会有所不同。
本地开发的例外情况
一般来说，Service Worker API 仅适用于通过 HTTPS 提供的页面，
但也有一些例外情况，在这些情况下，可以通过 HTTP 协议使用 HTTP 协议。
有一项值得注意的例外情况，那就是通过 localhost 提供的网页，这种格式非常适合本地开发。
然而，除了 localhost 在
hosts 文件。
如果多个项目需要单独的主机名，则在本地开发环境中需要执行此操作。
在这些情况下，可以预配自签名证书。
一种更方便的解决方法是指示浏览器允许 Service Worker 测试例外。
对于 Chrome，请前往 chrome://flags/#unsafely-treat-insecure-origin-as-secure
并指定不安全的源以被视为安全源。
Firefox 提供了一种方法，可通过 about:config 中的 devtools.serviceWorkers.testing.enabled 设置在不安全的源上测试 Service Worker。
Service Worker 开发辅助工具
混合使用 Service Worker 的本地开发可能会导致看似意外的行为。
例如，假设针对无版本控制的静态资产采用“仅缓存”策略，或者采用预缓存的“你处于离线状态”策略更改后，系统会在重新加载时更新该网页。
由于这些资源的过时版本始终通过 Cache 实例提供，
它们似乎从未更新！
令人失望的是，Service Worker 只能执行其构建用途，
但有些方法可以简化测试
目前为止，测试 Service Worker 的最有效方法是依靠无痕浏览窗口，例如 Chrome 中的无痕式窗口，
或 Firefox 的隐私浏览功能。
每次您打开无痕浏览窗口时，都是全新的。
没有活跃的 Service Worker，也没有打开的 Cache 实例。此类测试的例程如下：
- 打开无痕浏览窗口。
- 导航到注册 Service Worker 的页面。
- 验证 Service Worker 的行为是否符合您的预期。
- 关闭无痕式窗口。
- 重复。
通过此过程，您可以真实地模拟 Service Worker 的生命周期。
Chrome 开发者工具的 Application 面板中提供的其他测试工具 可以有所帮助 - 但它们可以通过某些方式修改 Service Worker 的生命周期。
应用面板包含一个标记为 Service Workers 的子面板， 其中显示了当前页面的活跃 Service Worker。 每个活跃的 Service Worker 都可以手动更新，甚至可以全部取消注册。 顶部还提供了三个有助于开发工作的切换开关。
- 离线功能会模拟离线情况。这有助于测试活跃的 Service Worker 是否提供离线内容。
- Update on reload：切换后，每当页面重新加载时，都会重新获取并替换当前的 Service Worker。
- 绕过网络，当此设置处于切换状态时，系统会绕过 Service Worker 的
fetch事件中的任何代码，并始终从网络获取内容。
这些是有用的切换开关，尤其是绕过网络， 当您使用活跃的 Service Worker 开发项目时，这会非常有用， 但又想确保体验在没有 Service Worker 的情况下也能按预期运行。
Firefox 的开发者工具中也有类似的应用面板， 但该功能仅限于显示已安装的 Service Worker， 还可以手动取消注册当前页面的任何活跃 Service Worker。 它同样有用，但在本地开发周期中确实需要更多的手动工作。
Shift 并重新加载
如果使用活跃的 Service Worker 进行本地开发，而不需要“刷新时更新”或“绕过网络”提供的功能，那么按住 Shift 键并按刷新按钮也十分有用。
这称为强制刷新，会绕过网络的 HTTP 缓存。 当 Service Worker 处于活动状态时，强制刷新也将完全绕过 Service Worker。
如果对特定缓存策略能否按预期运行存在不确定性，此功能非常有用， 从网络中获取所有内容，以比较有没有 Service Worker 和没有 Service Worker 时的行为，这非常有用。 更棒的是，这是一种指定的行为，因此支持 Service Worker 的所有浏览器都会观察它。
检查缓存内容
如果无法检查缓存，则很难判断缓存策略是否按预期运行。
当然，可以在代码中检查缓存，
但这是一个涉及调试程序和/或 console 语句的过程，此时可视化工具更适合该任务。
Chrome DevTools 中的 Application 面板提供了一个子面板，用于检查 Cache 实例的内容。
此子面板通过提供如下功能来简化 Service Worker 的开发：
- 查看
Cache实例的名称。 - 能够检查已缓存资源的响应正文及其关联的响应标头。
- 您可以从缓存中逐出一项或多项，甚至删除整个
Cache实例。
这种图形界面有助于更轻松地检查 Service Worker 缓存，以了解是否从 Service Worker 缓存完全添加、更新或移除了项目。Firefox 自带具有类似功能的缓存查看器，不过它位于单独的存储面板中。
模拟存储空间配额
在包含大量大型静态资源（例如高分辨率图片）的网站上， 就有可能会达到存储空间配额出现这种情况时 浏览器会从缓存中删除它认为已过时或值得牺牲的项，以便为新资产腾出空间。
存储配额的处理应该是 Service Worker 开发的一部分， Workbox 能比自行管理管理流程更简单。 但无论是否使用 Workbox，都适合通过模拟自定义存储空间配额来测试缓存管理逻辑。
Chrome 开发者工具中的“Application”面板有一个 Storage 子面板，显示当前使用了多少存储空间配额的信息。 它还允许以 MB 为单位指定自定义配额。 生效后，Chrome 将强制执行自定义存储空间配额，以便您进行测试。
顺便说一句，此子面板还包含一个清除网站数据按钮，以及一系列关联复选框，用于供用户点击该按钮时清除的内容。
其中包括所有打开的 Cache 实例，以及能够取消注册控制该页面的任何活跃 Service Worker。
开发更轻松，工作效率更高
开发者如果能摆脱困境，就能更自信地开展工作，提高工作效率。 使用 Service Worker 进行本地开发可能会很微妙，但不必那么痛苦。 有了这些提示和技巧，通过活跃的 Service Worker 进行开发应该变得更加透明和可预测， 从而带来更好的开发者体验