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 网页。为此，您可以采用两种方法：
<ph type="x-smartling-placeholder">
- </ph>
- 在每个网页的标头部分添加
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 和您的令牌之间需要换行。）
您可以看到下方嵌入的示例项目，该项目演示了如何将正确的源试用令牌添加到 index.html 和 manifest.appcache 文件中。
为什么多个地方都需要令牌？
同源试用令牌需要与以下项相关联：
- 使用 AppCache 的所有 HTML 网页。
- 您的所有 AppCache 清单（通过
ORIGIN-TRIAL清单字段指定）。
如果您之前参与过源试用，那么您可能只是将令牌添加到了 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 提供的离线体验提供了替代方案。
我们提供了一个 polyfill，它使用 Service Worker 复制 AppCache 的某些功能，尽管它不会复制整个 AppCache 接口。具体来说，它不提供 window.applicationCache 接口或相关 AppCache 事件的替代。
对于更复杂的用例，Workbox 等库可让您轻松为 Web 应用创建现代 Service Worker。
Service Worker 和 AppCache 是互斥的
在制定迁移策略时，请记住，Chrome 将在 Service Worker 的控制下加载的任何页面上停用 AppCache 功能。换言之，一旦您部署了控制给定页面的 Service Worker，就不能再在该页面上使用 AppCache。
因此，我们建议您不要尝试逐个迁移到 Service Worker。部署仅包含部分缓存逻辑的 Service Worker 是错误的。您不能依靠 AppCache 来“填补差距”。
同样，如果您在移除 AppCache 之前部署一个 Service Worker，然后发现需要回滚到之前的 AppCache 实现，则需要确保取消注册该 Service Worker。只要有注册的 Service Worker 在给定页面的作用域内，就不会使用 AppCache。
跨平台案例
如果您想详细了解特定浏览器供应商的 AppCache 移除计划，建议您咨询该供应商。
所有平台上的 Firefox
Firefox 在版本 44（2015 年 9 月）中弃用 AppCache，并且自 2019 年 9 月起在其 Beta 版和每夜 build 中移除对 AppCache 的支持。
iOS 和 macOS 上的 Safari
Safari 已于 2018 年初弃用 AppCache。
iOS 设备，Chrome 浏览器
Chrome（iOS 版）是一种特殊情况，因为它使用的浏览器引擎不同于其他平台上的 Chrome：WKWebView。使用 WKWebView 的 iOS 应用目前不支持 Service Worker，而且 Chrome 的 AppCache 移除公告未涵盖 Chrome（iOS 版）上 AppCache 的可用性。如果您知道自己的网络应用拥有大量 Chrome（iOS 版）受众，请记住这一点。
Android WebView
某些 Android 应用的开发者使用 Chrome WebView 显示网页内容，还可能会使用 AppCache。不过，您无法为 WebView 启用源试用。因此，在最终移除应用之前（预计在 Chrome 90 中），Chrome WebView 无需源试用即可支持 AppCache。
了解详情
以下资源适用于从 AppCache 迁移到 Service Worker 的开发者。
文章
工具
获取帮助
如果您在使用特定工具时遇到问题，请在相应工具的 GitHub 代码库中提交问题。
您可以使用标记 html5-appcache 在 Stack Overflow 上提出有关从 AppCache 迁移的常规问题。
如果您遇到与 Chrome 移除 AppCache 相关的错误，请使用 Chromium 问题跟踪器报告该错误。