HTML5本地媒体缓存需分层设计：元数据用localStorage，二进制资源用IndexedDB，离线场景结合Service Worker+Cache API；IndexedDB支持Blob/ArrayBuffer高效存取，Service Worker可实现无网播放，localStorage仅适合轻量状态存储。
HTML5 提供了多种本地存储能力，针对文件与媒体资源（如图片、音频、视频）的缓存，不能只依赖单一机制。真正实用的本地化媒体缓存，需要分层设计：小量元数据用 localStorage 或 sessionStorage，中高频访问的二进制资源适合 IndexedDB，而整站离线可用场景则需结合 Service Worker + Cache API（AppCache 已被废弃，不再推荐）。
媒体资源优先走 IndexedDB 存储
localStorage 只支持字符串，无法直接存 Blob 或 ArrayBuffer 类型的音视频文件；强行 base64 编码会膨胀体积、拖慢读写。IndexedDB 是浏览器原生支持的事务型数据库，能高效存取二进制数据。
- 使用
indexedDB.open()创建数据库，定义 objectStore 存储媒体文件（如mediaFiles），以 URL 或 hash 为 key - 下载媒体资源后，用
fetch().then(res => res.arrayBuffer())转为 ArrayBuffer，再通过put()写入 - 播放时通过
get()读取并构造URL.createObjectURL(new Blob([data], {type: 'video/mp4'}))播放 - 配合
clear()或按时间/大小策略定期清理过期缓存，避免占用过多空间
离线页面+媒体资源统一托管用 Service Worker
若目标是“无网也能播视频”或“秒开图文页”，必须用 Service Worker 拦截请求并响应缓存内容。它替代了已淘汰的 AppCache，更灵活、可控性更强。
- 注册 SW 脚本（如
navigator.serviceWorker.register('sw.js')），在安装阶段预缓存 HTML/CSS/JS 和关键媒体资源 - 在
fetch事件中，优先匹配cache.match(request)；未命中再发起网络请求，并将响应cache.put()存入 Cache Storage - 对大媒体文件（如 >5MB 视频），建议设置单独缓存策略（如仅缓存首屏片段、或按 range 请求分片缓存）
- 更新机制靠 SW 版本号变更触发，可监听
controllerchange提示用户刷新
轻量级元数据与播放状态用 localStorage 管理
不存媒体本体，但可存播放记录、进度、收藏状态、封面缩略图 base64（≤100KB）、资源路径映射表等轻量信息。
立即学习“前端免费学习笔记（深入）”；
- 例如：
localStorage.setItem('video-progress', JSON.stringify({url: '/v/123.mp4', time: 128.5})) - 用户切换设备或清除缓存后数据丢失，因此敏感状态（如登录态）不应只依赖它
- 注意同源限制：不同协议、端口、子域名之间 localStorage 不共享
Android WebView 场景需额外启用磁盘缓存
在原生 App 内嵌 WebView 加载 H5 媒体页时，系统级缓存可显著提升复用率。需主动配置：
- 启用 WebView 缓存：
webView.getSettings().setAppCacheEnabled(true)，并指定缓存路径和大小 - 配合 OkHttp 设置响应缓存（
Cache(cacheDir, 10 * 1024 * 1024)），让网络层也参与媒体资源复用 - 注意 Android 9+ 默认禁用明文 HTTP 缓存，HTTPS 资源才受完整缓存策略控制
