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 迁出流量，可以注册进行“反向”源试用，以延长 AppCache 对其 Web 应用的使用期限。源试用将从 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 和您的令牌之间需要另起一行）。
下方嵌入了一个示例项目，该项目演示了如何将正确的源试用令牌添加到 index.html 和 manifest.appcache 文件中。
为什么在多个位置都需要令牌？
同源试用令牌需要与以下内容相关联：
- 使用 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 提供的离线体验的替代方案。
我们提供了一个 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 版和每夜版中取消了对 AppCache 的支持。
iOS 和 macOS 上的 Safari
Safari 已于 2018 年初弃用 AppCache。
iOS 设备，Chrome 浏览器
Chrome（iOS 版）是一种特殊情况，因为它使用的浏览器引擎与其他平台上的 Chrome 不同：WKWebView。使用 WKWebView 的 iOS 应用目前不支持 Service Worker，而且 Chrome 的 AppCache 移除公告未涵盖 Chrome（iOS 版）上 AppCache 的可用性。如果您知道自己的 Web 应用具有大量 Chrome（iOS 版）受众群体，那么请务必注意这一点。
Android WebView
一些 Android 应用的开发者使用 Chrome WebView 来显示 Web 内容，还可能会使用 AppCache。不过，您无法为 WebView 启用源试用。因此，在 Chrome 90 中最终移除之前，Chrome WebView 将支持 AppCache，而无需进行源试用。
了解详情
以下是一些面向从 AppCache 迁移到 Service Worker 的开发者的资源。
文章
工具
获取帮助
如果您在使用特定工具时遇到问题，请在该问题的 GitHub 代码库中打开相应问题。
您可以使用 html5-appcache 标记在 Stack Overflow 上询问关于从 AppCache 迁出的一般性问题。
如果您遇到与 Chrome 的 AppCache 移除相关的错误，请使用 Chromium 问题跟踪器报告该错误。
主打图片来自 Smithsonian Institution Archives, Acc. 11-007，Box 020，图片编号：MNH-4477。