Application Cache（已废弃）
虽然部分浏览器依然支持，但是W3C已经废弃该方案，推荐开发者使用Service Worker。
简介
HTML5的离线存储（Application Cache）是基于一个manifest文件(缓存清单文件，一般后缀为.appcache)的缓存机制(不是存储技术)。在该文件中定义需要缓存的文件，支持manifest的浏览器，会将按照manifest文件的规则，像文件保存在本地，之后当网络在处于离线状态时，浏览器会通过被离线存储的数据进行页面展示。主要应用在内容变动少、相对固定的场景下。其流程大致如下：
它具备以下优势：
离线浏览 - 用户可在应用离线时使用它们。
更快的速度 - 已缓存资源加载得更快。
减少服务器负载 - 浏览器将只从服务器下载更新过或更改过的资源。
Service Worker
简介
service worker也是一种web worker，额外拥有持久离线缓存的能力。宿主环境会提供单独的线程来执行其脚本，解决js中耗时间、耗资源的运算过程带来的性能问题。
特点
- 独立于JS引擎的主线程，在后台运行的脚本，不影响页面渲染
- 被install后就永远存在，除非被手动卸载。
- 可拦截请求和返回，缓存文件。service worker可以通过fetch这个api，来拦截网络和处理网络请求，再配合cacheStorage来实现web页面的缓存管理以及与前端postMessage通信。
- 不能直接操纵dom：因为service worker是个独立于网页运行的脚本，所以在它的运行环境里，不能访问窗口的window以及dom。
- 生产环境必须是https的协议才能使用。在本地调试时，http://localhost 和http://127.0.0.1 也可以使用，不过需要勾选Bypass for network，否则资源静态资源都会被缓存（没有hash值），导致无法调试。
- 异步实现，service worker大量使用promise。
根据文档中的描述，service worker层面上cacheStorage容量不受限，但还是受到宿主环境 QuotaManager 的限制。
Application Cache 被废弃的原因以及为什么推荐使用 Service Worker
-
更强大的缓存控制：Application Cache 缺乏对缓存过程的完全控制，需要依赖 .appcache 清单文件来管理缓存的资源。相比之下，Service Worker 提供了更多操作缓存的接口，如 Cache Storage API, 使开发者能够更精细地管理资源缓存，包括添加、更新、删除等。
-
更灵活的缓存策略：Application Cache 是全部或无法缓存；当应用需要更灵活的缓存策略时，如根据网络状态选择性缓存，Application Cache 就显得力不从心。而 Service Worker 提供了更多策略选择，如缓存优先（Cache First）、网络优先（Network First）、优先新鲜（Stale-While-Revalidate）等，针对不同场景作出优化。
-
支持拦截网络请求：Service Worker 可以拦截浏览器的网络请求，使开发者在处理离线/在线状态转换时更加灵活。例如，针对加载失败的资源进行降级处理或提供其他替代资源。
-
更广泛的功能支持：Service Worker 不仅作为离线存储技术，还支持其他功能，如推送通知（Push Notifications）、后台数据同步（Background Sync）等。这使得使用 Service Worker 的应用程序具有更丰富的功能和用户体验。
-
更好的性能及安全性：Service Worker 只能在 HTTPS 环境中运行，这保证了应用的安全性。同时，Service Worker 作为一个单独的线程运行在浏览器背景，不受主进程的影响，提升了性能。
总结：Service Worker 提供了更强大、灵活且具备广泛功能的离线存储能力，相对于 Application Cache 而言，它可以让开发者更好地管理缓存资源、根据不同场景应用优化策略、并且支持其他功能，如推送通知和后台数据同步。同时，Service Worker 在性能和安全性方面也更具优势。因此，Service Worker 取代了 Application Cache，并成为推荐的离线存储及功能扩展技术。