HTML5 Application Cache，也就是我们常说的AppCache，它主要用于让Web应用离线可用，通过一个清单文件（manifest file）声明哪些资源需要缓存，从而在用户没有网络连接时也能访问这些预先缓存的页面和资源。它的核心机制就是这个清单文件，浏览器会根据它来决定哪些文件应该被存储在本地，哪些应该始终从网络获取，以及哪些是备用资源。
解决方案
要使用AppCache，你需要创建一个
.appcache
后缀的清单文件，并在你的HTML文件的
标签中引用它。这个清单文件通常包含三个部分：
CACHE:
、
NETWORK:
和
FALLBACK:
。
1. 创建清单文件（例如：
cache.appcache
）
CACHE MANIFEST# 版本号，每次更新清单文件时都需要改变，哪怕只是一个注释，否则浏览器不会重新下载# v1.0.1 - 2023-10-27# CACHE: 列出需要离线缓存的静态资源CACHE:/index.html/css/style.css/js/main.js/images/logo.png# NETWORK: 列出永远需要从网络获取的资源，或者不应该被缓存的资源# 即使离线，浏览器也会尝试访问这些资源，失败则报错NETWORK:/api/data.json* # 星号表示所有未在CACHE或FALLBACK中声明的资源都应从网络获取# FALLBACK: 当某个资源无法从网络获取时，提供一个备用资源# 格式是：网络资源路径 备用资源路径FALLBACK:/offline.html /offline.html/ /offline.html # 任何未匹配的路径都重定向到离线页面
2. 在HTML文件中引用清单文件
立即学习“前端免费学习笔记（深入）”；
在你的
标签中添加
manifest
属性，指向你的清单文件：
我的离线应用 欢迎来到离线世界！
@@##@@
3. 服务器配置
确保你的Web服务器为
.appcache
文件设置了正确的MIME类型：
text/cache-manifest
。如果服务器没有正确配置，浏览器可能无法识别清单文件，导致缓存失败。
4. 更新机制
AppCache的更新机制有点“笨拙”。当你修改了任何缓存资源（比如
style.css
），仅仅修改资源本身是不够的，你必须同时修改
cache.appcache
文件本身（比如更改注释中的版本号）。浏览器检测到清单文件有变化后，会重新下载所有缓存资源。这个过程是异步的，用户可能需要刷新页面两次才能看到更新：第一次刷新会下载新资源，第二次刷新才会使用这些新资源。
AppCache的工作原理和生命周期是怎样的？
我个人觉得，要真正理解AppCache，它的工作原理和生命周期是绕不开的。它不像我们现在用的Service Worker那么灵活，AppCache更像一个“一次性”的缓存策略。
当浏览器首次加载一个带有
manifest
属性的HTML页面时，它会：
解析清单文件： 浏览器首先下载并解析
cache.appcache
文件。下载资源： 根据
CACHE:
部分列出的资源，浏览器会逐一下载这些文件并存储在本地缓存中。这个过程是原子性的，如果其中任何一个文件下载失败，整个缓存过程就会失败，浏览器会回滚到之前的缓存状态（如果有的话）。激活： 所有资源下载成功后，缓存就被“激活”了。此时，页面会使用这些缓存资源。
更新周期：
这才是AppCache最让人头疼的地方。
清单文件检测： 每次用户访问带有
manifest
属性的页面时，浏览器都会尝试去服务器请求最新的
cache.appcache
文件。文件比较： 浏览器会将新下载的清单文件与当前已缓存的清单文件进行比较。触发更新：如果两个文件完全相同，什么也不会发生，页面继续使用现有缓存。如果清单文件有任何一个字节的改变（哪怕只是一个注释或版本号），浏览器就会认为有新版本，然后开始下载新清单中列出的所有资源。下载新资源： 浏览器会在后台下载所有新的或更新的资源。
updateready
事件： 当所有新资源下载完毕后，会触发
updateready
事件。此时，新的缓存集已经准备就绪，但页面仍在运行旧的缓存。激活新缓存： 用户需要刷新页面，或者通过JavaScript调用
applicationCache.swapCache()
和
location.reload()
才能激活新的缓存集。
所以，很多时候用户会觉得“我的更新怎么没生效？”就是因为这个两步走的激活过程，用户往往需要手动刷新两次。
使用AppCache时会遇到哪些常见问题和陷阱？
老实说，我在项目里用AppCache的时候，踩过的坑可不少，它真的没有Service Worker那么友好。
清单文件自身缓存： 这是最要命的一个陷阱。一旦浏览器缓存了你的
cache.appcache
文件，它就不会再检查服务器上的新版本了。这意味着即使你更新了清单文件，浏览器也可能因为缓存了旧的清单文件而“看不见”你的更新。解决办法通常是给清单文件的URL添加版本号或哈希值（
manifest="cache.appcache?v=123"
），或者确保服务器不缓存
.appcache
文件。更新不及时或需要两次刷新： 就像前面提到的，用户往往需要刷新两次才能看到更新。这给用户体验带来了很大的困扰，而且也增加了开发者的沟通成本。调试困难： 浏览器开发者工具对AppCache的调试支持相对有限。你很难直观地看到哪些文件被缓存了，缓存状态是什么，或者为什么更新失败。错误信息也往往不够清晰。原子性问题： 如果清单文件中列出的任何一个资源下载失败，整个缓存更新就会失败，浏览器会回滚到之前的状态。这在网络不稳定或资源路径有误时，会非常麻烦。网络模式的严格性：
NETWORK:
部分非常严格。如果你声明了
NETWORK: *
，那么所有未在
CACHE:
或
FALLBACK:
中明确列出的资源都必须从网络获取。如果网络不可用，这些资源就会加载失败。这可能导致一些意想不到的离线行为。
FALLBACK:
的局限性：
FALLBACK:
只能为单个资源或路径提供一个备用页面，无法实现更复杂的离线逻辑。
为什么现在不推荐使用AppCache，有什么更好的替代方案？
坦白讲，AppCache在设计上有一些固有的缺陷，加上其复杂的更新机制和调试难度，导致它在实际应用中经常让人抓狂。所以，现在前端社区普遍不推荐使用AppCache，它甚至已经被Web标准废弃了。
主要原因有：
更新机制的复杂性： 强制两次刷新、清单文件自身缓存等问题，极大地影响了用户体验和开发效率。调试困难： 缺乏强大的开发者工具支持，排查问题非常痛苦。灵活性不足： 只能通过静态清单文件来控制缓存，无法实现更精细的缓存策略，例如根据请求头、URL参数动态缓存，或者在网络可用时主动更新特定资源。控制力弱： 开发者对缓存过程的控制力非常有限，很多行为都是浏览器自动完成的，缺乏拦截请求、自定义响应的能力。
更好的替代方案：Service Worker
毫无疑问，Service Worker 是AppCache的完美继任者，也是现代Web应用实现离线能力和高性能的关键技术。
Service Worker 本质上是一个在浏览器后台运行的JavaScript文件，它充当了Web应用和网络之间的代理。它能拦截所有的网络请求，并决定如何响应这些请求。这带来了巨大的灵活性和控制力：
强大的缓存控制： 你可以编写JavaScript代码来决定哪些请求需要缓存，如何缓存（例如，缓存优先、网络优先、Stale-While-Revalidate等策略），以及何时更新缓存。事件驱动： Service Worker通过事件（如
install
、
activate
、
fetch
）来管理其生命周期和网络请求，提供了极高的可编程性。后台同步和消息推送： 除了离线缓存，Service Worker还能实现后台数据同步、接收推送通知等高级功能，极大地扩展了Web应用的能力。更好的调试工具： 现代浏览器（如Chrome）提供了非常强大的Service Worker调试工具，可以清晰地看到注册状态、拦截请求、缓存内容等。渐进增强： Service Worker是一个渐进增强的技术。如果浏览器不支持Service Worker，网站仍然可以正常运行，只是没有离线功能。
虽然Service Worker的学习曲线比AppCache陡峭一些，但它提供的强大功能和灵活性，绝对值得投入时间去学习和掌握。现在几乎所有的渐进式Web应用（PWA）都离不开Service Worker。
以上就是HTML5应用程序缓存怎么用_ApplicationCache应用指南的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1577124.html
微信扫一扫 
支付宝扫一扫 
