摘要

  • AppCache 让网页应用在断网时继续打开。网页指向一份缓存清单，浏览器保存清单列出的文件；开发者只改服务器上的脚本或图片，旧缓存并不会因此自动换新，清单本身必须变化。
  • 清单或其中一个必需文件下载失败，整次更新就可能失败，浏览器继续用旧应用。Chrome 从 2020 年起分阶段关闭 AppCache。原本为了离线而写的小清单，成了软件发布的开关。

修好了脚本，读者还在用旧版

开发者把 main.js 修好并部署。服务器已是新文件，读者打开应用却依然碰到旧故障。问题不在“刷新”这个按钮有多难找，而在 AppCache 的更新规则。Google 的原始开发指南写得明确：清单中已有的脚本或图片即使在服务器上修改，浏览器也不会仅凭文件变化重新缓存；必须改动清单文件。给清单里的一行注释换个版本号，就可能成为实际的发布动作。

这是一笔交换。浏览器把完整应用留在本地，网络断了仍可打开；相应地，服务器上单个文件的新版本失去了直接到达用户的权力。清单是门卫。修好的脚本要等它点头。

一份名单替离线应用守门

W3C 在2008 年 5 月的离线网页应用说明里给出的愿景很实在：邮件、日历、文档应用不应一离开网络就只剩空白。普通 HTTP 缓存未必恰好保留所有必需文件。HTML 的 manifest 属性因此可以指向一份 text/cache-manifest 文件，列明要保存的资源；NETWORK: 部分则指定仍应走网络的请求。开发者终于能明确告诉浏览器，哪些东西必须陪用户离线。

明确名单也带来整组更新。Google 的指南说明，清单本身或其中一个列出的文件下载失败，整个更新会失败，浏览器继续使用旧的完整缓存。即使新的一组文件成功下载，已经打开的页面也要重新加载，才能用到新文件。浏览器保护的是一套能工作的应用，不是一堆凑巧最新的零件。

这套保护在发布时有两个反面。只改 main.js，清单没动，用户仍会拿到旧脚本；清单改了，却有一个必需资源无法下载，用户仍会拿到旧应用。“服务器有修复”与“读者看见修复”成了两个需要分别证明的事实。

清单不动会卡住，动得太快也会卡住

更新节奏同样受清单支配。开发者若为了省事让清单每次请求都带一个新时间戳，浏览器在下载开始和结束时可能读到两份不同的清单。Google 指南指出，它可能因此发现文件来自不同版本，拒绝安装这组混合物，稍后重试。清单从不变化，旧版出不去；清单变化得太急，新版也进不来。

CACHE、NETWORK、FALLBACK 三类声明把这份文本变成应用政策：哪些资源锁在本地，哪些请求出网，哪些路径在网络失败时收到替代页面。少一个必需文件，不再只是页面上一个坏链接，而可能让整组新版本作废。离线可靠性和更新速度都系在这份小文件上。

AppCache 的取舍并不神秘：浏览器宁可保留一套完整旧版，也不交付一套残缺新版。它能避免断网应用半途坏掉，也会让紧急修复停在服务器上，直到清单和整组文件都合格。真正的发布检查必须走到读者浏览器，而不是停在部署服务器。

Chrome 把旧门拆掉

Google 在2020 年的 AppCache 退场指南中列出分阶段时间线：Chrome 85 默认关闭 AppCache，需要缓冲期的网站可使用源试验继续迁移。Service Worker 成为离线体验的替代机制。迁移中有条硬规则：在 Chrome 里，只要页面已受 Service Worker 控制，AppCache 就不再替这页工作。新缓存只做了一半，旧缓存不会自动补齐剩下一半。

这意味着团队要重新决定哪些请求被接管、哪些文件保存、打开中的页面怎样换版。Google 说明，它提供的迁移工具只复现部分旧行为，并不复刻 window.applicationCache 接口和事件。Chrome 的时间线也只约束该浏览器的退场过程，各浏览器有自己的节奏。

AppCache 的历史带着一点讽刺：为了让用户断网时仍能看见应用，开发者把版本的钥匙交给一份名单；网络恢复、服务器修好之后，用户仍可能被那把钥匙挡在旧版里。网页活了下来，修复却还在门外。