Chrome 85 默认移除对 AppCache 的支持。大多数开发者现在就应该迁移出 AppCache，不要再等待了。
继之前的公告之后，Chrome 和其他基于 Chromium 的浏览器将不再支持 AppCache。我们建议开发者立即停用 AppCache，而不是再等待一段时间。
Service Worker 在当前浏览器中得到广泛支持，可替代 AppCache 提供的离线体验。请参阅迁移策略。
时间轴
Chrome 发布时间表的近期变更意味着其中一些步骤的时间可能会有所不同。我们会尽量让此时间表保持最新状态，但在目前阶段，请尽快迁移出 AppCache，而不是等待特定的里程碑。
“已弃用”的功能仍然存在，但会记录警告消息，不鼓励使用。浏览器中不再存在“已移除”功能。
| 在不安全的上下文中弃用 | Chrome 50（2016 年 4 月） |
| 从不安全情境中移除 | Chrome 70（2018 年 10 月） |
| 在安全上下文中弃用 | Chrome 79（2019 年 12 月） |
| AppCache 范围限制 | Chrome 80（2020 年 2 月） |
| “反向”源试用开始 | Chrome 84（2020 年 7 月） |
| 从安全情境中移除，但选择加入源试用的情境除外 | Chrome 85（2020 年 8 月） |
| 面向所有用户从安全上下文中完全移除，并完成源试用 | 2021 年 10 月 5 日（大致为 Chrome 95） |
源试用
时间轴列出了两个即将移除的里程碑。从 Chrome 85 开始，默认情况下 Chrome 中将不再提供 AppCache。如果开发者需要更多时间来迁移 AppCache，可以注册“反向”源试用，以便延长其 Web 应用的 AppCache 可用时间。源试用将在 Chrome 84 中开始（在 Chrome 85 中默认移除之前），并将持续到 2021 年 10 月 5 日（大约是 Chrome 95）。届时，AppCache 将面向所有人（包括已注册源试用的用户）完全移除。
如需参与“反向”源试用，请执行以下操作：
- 为您的来源请求令牌。
- 将令牌添加到 HTML 网页。您可以通过两种方式来完成此操作：
- 在每个网页的头部添加
origin-trial<meta>标记。例如：<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE"> - 或者，您也可以配置服务器，使其返回包含
Origin-TrialHTTP 标头的响应。生成的响应标头应如下所示：Origin-Trial: TOKEN_GOES_HERE
- 在每个网页的头部添加
- 将同一令牌添加到您的 AppCache 清单中。您可以通过清单中的一个新字段来执行此操作，格式如下：
ORIGIN-TRIAL:
TOKEN_GOES_HERE
（ORIGIN-TRIAL 和您的令牌之间需要换行。）
为什么需要在多个位置使用令牌？
同源试用令牌需要与以下内容相关联：
- 使用 AppCache 的所有 HTML 页面。
- 通过
ORIGIN-TRIAL清单字段列出所有 AppCache 清单。
如果您之前参与过源试用，可能只在 HTML 网页中添加了令牌。AppCache“反向”源试用版非常特殊，因为您还需要将令牌与每个 AppCache 清单相关联。
将源试用令牌添加到 HTML 网页后，您便可以在 Web 应用中使用 window.applicationCache 界面。未与令牌关联的网页将无法使用 window.applicationCache 方法和事件。没有令牌的网页也无法从 AppCache 加载资源。从 Chrome 85 开始，它们将表现得好像 AppCache 不存在一样。
将源试用令牌添加到 AppCache 清单中，表示每个清单仍然有效。从 Chrome 85 开始，任何没有 ORIGIN-TRIAL 字段的清单都将被视为格式有误，并且清单中的规则将被忽略。
源试用部署时间安排和物流
虽然“反向”来源试用正式开始于 Chrome 84，但您可以立即注册来源试用，并将令牌添加到 HTML 和 AppCache 清单中。随着 Web 应用的受众群体逐渐升级到 Chrome 84，您已添加的所有令牌都将生效。
将令牌添加到 AppCache 清单后，请访问 about://appcache-internals，确认本地 Chrome 实例（版本 84 或更高版本）已将源试用令牌与清单的缓存条目正确关联。如果您的源试用被识别，您应该会在该页面上看到一个带有 Token Expires: Tue Apr 06 2021... 的字段，该字段与您的清单相关联：
在移除前进行测试
我们强烈建议您尽快迁移，不再使用 AppCache。如果您想测试 Web 应用中 AppCache 的移除情况，请使用 about://flags/#app-cache 标志来模拟移除。此标志从 Chrome 84 开始提供。
迁移策略
Service Worker 在当前浏览器中得到广泛支持，可提供 AppCache 提供的离线体验。
我们提供了一个使用 Service Worker 来复制部分 AppCache 功能的 polyfill，但它无法复制整个 AppCache 接口。特别是，它不会取代 window.applicationCache 接口或相关的 AppCache 事件。
对于更复杂的情况，Workbox 等库提供了一种简单的方法来为 Web 应用创建现代化的 Service Worker。
Service Worker 和 AppCache 是互斥的
在制定迁移策略时，请注意，Chrome 会在任何由 Service Worker 控制的网页上停用 AppCache 功能。换句话说，只要您部署了控制特定网页的 Service Worker，就无法再在该网页上使用 AppCache。
因此，我们建议您不要尝试逐步迁移到 Service Worker。部署仅包含部分缓存逻辑的服务工作线程是错误的。您无法依赖 AppCache 来“填补空白”。
同样，如果您在移除 AppCache 之前部署了 Service Worker，然后发现需要回滚到之前的 AppCache 实现，则需要确保您取消注册该 Service Worker。只要在给定网页的范围内注册了 Service Worker，就不会使用 AppCache。
跨平台故事
如果您想详细了解特定浏览器供应商有关移除 AppCache 的计划，建议您与他们联系。
所有平台上的 Firefox
Firefox 在版本 44（2015 年 9 月）中弃用了 AppCache，并从 2019 年 9 月起在其 Beta 版和 Nightly 版 build 中移除了对它的支持。
iOS 和 macOS 设备上的 Safari
Safari 于 2018 年初弃用了 AppCache。
iOS 设备，Chrome 浏览器
iOS 版 Chrome 是一种特殊情况，因为它使用的浏览器引擎与其他平台上的 Chrome 不同，即 WKWebView。使用 WKWebView 的 iOS 应用目前不支持服务工作线程，而 Chrome 的 AppCache 移除公告并未提及 iOS 版 Chrome 上 AppCache 的可用性。如果您知道自己的 Web 应用有大量 Chrome for iOS 用户，请务必注意这一点。
Android WebView
某些 Android 应用开发者使用 Chrome WebView 来显示 Web 内容，并且可能还会使用 AppCache。不过，无法为 WebView 启用源试用。鉴于此，在最终移除之前（预计在 Chrome 90 中），Chrome WebView 将在没有源试用的情况下支持 AppCache。
了解详情
以下是一些资源，可帮助开发者从 AppCache 迁移到 Service Worker。
文章
工具
获取帮助
如果您在使用特定工具时遇到问题，请在其 GitHub 代码库中提交问题。
您可以在 Stack Overflow 上提出有关从 AppCache 迁移的一般性问题，并使用 html5-appcache 标记。
如果您遇到与 Chrome 移除 AppCache 相关的 bug，请使用 Chromium 问题跟踪器报告该 bug。
主打图片基于 Smithsonian Institution Archives, Acc. 11-007，Box 020，图片编号 MNH-4477。