提到“嵌H5如何缓存”，很多同学第一反应就是“用localStorage”或者“加个manifest”。但真正在嵌入场景（比如App的WebView、小程序Web组件、甚至桌面客户端的内嵌浏览器）里，你会遇到一堆“标准方案”解决不了的坑。今天咱们就围绕这个具体场景，把缓存这件事讲透，从原理到实操，让你看完就能用，用了就能解决实际问题。

一、认清“嵌H5”的缓存困境：你面对的不是普通浏览器

普通浏览器缓存，你可以依赖Service Worker、HTTP强缓存协商缓存、甚至IndexedDB。但嵌入环境里，很多能力是被阉割的。举个例子：
- 微信小程序里的web-view，Service Worker基本不能用，因为小程序对网络请求有自己的一套管控。
- 部分App的WebView为了安全，会禁用File API，你没法直接读写本地文件。
- 甚至有些老旧Android系统WebView，连localStorage的容量限制都比标准浏览器更严格（比如只有2MB而不是5MB）。

所以，“嵌H5缓存”本质上是在一个受限的沙箱里，用最保险的方式保存离线数据。我的建议是：不要追求“全量缓存整个站点”，而是“按需缓存核心资源+数据”。

二、最稳的兜底方案：localStorage + 版本号控制（90%场景够用）

虽然localStorage老土，但它是所有WebView都支持的。关键在于怎么用它来缓存“动态数据”而不是静态文件。静态文件（JS、CSS、图片）的缓存，优先交给HTTP头里的Cache-Control，但很多嵌入环境会忽略这些头，所以需要双保险。

实操步骤：
1. 在页面加载时，先检查localStorage里有没有一个叫“app_version”的字段。
2. 如果有，对比当前版本号（写在JS文件里的常量）。如果一致，直接从localStorage读取缓存的JSON数据；如果不一致，清空所有缓存，重新请求。
3. 对于静态资源（比如一个图标、一个CSS文件），可以用“base64嵌入”的方式存进localStorage，但注意体积。超过100KB就别这么干了，会拖慢首次加载。

代码示例（核心逻辑）：
const CACHE_KEY = 'myAppData';
const VERSION_KEY = 'myAppVersion';
const CURRENT_VERSION = '2.1.3'; // 每次发版手动更新

function getCachedData() {
const version = localStorage.getItem(VERSION_KEY);
if (version !== CURRENT_VERSION) {
localStorage.removeItem(CACHE_KEY);
localStorage.setItem(VERSION_KEY, CURRENT_VERSION);
return null;
}
return JSON.parse(localStorage.getItem(CACHE_KEY));
}

这种方式的独特价值在于：它解决了“缓存污染”问题。很多开发只用过期时间，结果用户更新App后，H5里还是旧数据，因为localStorage里的数据没有随版本失效。版本号对比是简单但极其有效的手段。

三、进阶方案：利用“预加载”模拟缓存（针对无法用Service Worker的环境）

如果你遇到连localStorage都被限制的环境（比如某些金融类App的WebView），那就得换个思路：“预先把内容注入到页面中”。这需要App原生开发配合，但效果最好。

具体操作：
- 在App启动时，原生端通过接口提前下载一个zip包，里面包含H5的静态资源（HTML、JS、CSS）。
- 当用户打开H5页面时，原生端拦截所有网络请求，如果本地有匹配文件，直接用file://协议返回，否则走网络。
- H5端完全不用感知缓存逻辑，因为所有资源都是“本地文件”。

这个方案虽然需要原生开发，但解决了所有缓存问题：没有容量限制（只要手机存储够），没有跨域问题，也没有版本更新延迟。而且，你可以把“热更新”做到极致——App每次启动时检查服务器上的zip版本，有更新就后台下载，下次打开H5自动用新版本。

对比一下：
- 纯前端缓存：灵活，但受限于沙箱。
- 原生预加载：稳定，但需要两端配合。
如果你的团队能调动原生资源，我强烈推荐后者，特别是那些对实时性要求不高的H5页面（比如帮助中心、活动页面）。

四、数据缓存：IndexedDB的“嵌入环境”适配技巧

当数据量超过localStorage的5MB限制（比如要缓存用户的历史订单列表、地理位置轨迹），IndexedDB是唯一选择。但嵌入环境里，IndexedDB有一个常见坑：某些App在销毁WebView时会把IndexedDB数据库一起删掉，导致下次打开时数据丢失。

解决方案：
1. 不要把IndexedDB当作“永久存储”，而是“会话级缓存”。每次页面打开时，先尝试从IndexedDB读取，同时发起网络请求更新。网络请求成功后，再覆盖IndexedDB里的数据。
2. 在存储关键数据时，额外保留一份到localStorage（只存关键字段，比如“最近一次同步时间戳”）。这样即使IndexedDB被清，也能知道数据是否过期。

举个例子：
你缓存了一份地图瓦片数据到IndexedDB。如果WebView被销毁重建，IndexedDB没了，用户看到的就是空白。但如果你在localStorage里存了“lastSyncTime”，你可以在页面加载时发现“上一次同步是3天前”，然后提示用户“正在更新离线地图”，而不是直接显示空白让用户困惑。

五、一个被忽视的细节：缓存策略要区分“首次加载”和“二次打开”

很多教程只讲“怎么存”，不讲“什么时候存”。嵌入场景里，首次加载的体验直接决定用户是否愿意再打开这个H5。

我的做法是：
- 首次加载：只缓存“骨架屏”和“核心配置数据”（比如页面主题色、API地址）。其他所有图片、富文本内容，等用户滑动到再懒加载并缓存。这样首次打开时间能控制在1秒内。
- 二次打开：直接从缓存读取骨架屏和配置，同时后台静默更新全量数据。更新完成后，用一个小红点提示“有新内容，点击刷新”。

这种“渐进式缓存”比“一次性缓存所有”更实用。因为嵌入环境里，用户可能网络很差，你一次性缓存10MB数据，很可能导致页面卡死或崩溃。

六、特殊场景：离线表单提交（数据暂存）

这是嵌H5里很常见但很少被讲透的需求——用户在H5里填写表单，突然断网了，怎么保证数据不丢？

我的做法：
1. 在表单每个输入框的“change”事件里，把当前表单数据序列化，存入localStorage。注意用“防抖”，避免频繁写入。
2. 提交按钮点击时，先检查网络状态（navigator.onLine）。如果断网，把整个表单数据存到一个“待提交队列”里（用数组形式存进localStorage）。
3. 下次网络恢复时（监听window.online事件），自动从队列里取出数据提交。提交成功后删除队列项。

这里有个容易踩的坑：如果用户填到一半切换到其他App，再回来时WebView可能被销毁。所以每次输入变化都存一次，而不是只在提交时存。另外，表单数据可能包含图片，图片可以用FileReader转成base64再存，但注意base64体积很大，建议限制图片大小（比如压缩到200KB以内）。

七、终极建议：不要“过度缓存”

很多同学觉得缓存越多越好，结果把整个H5页面都缓存了。但在嵌入环境里，缓存越多，出问题的概率越大。比如：
- 你缓存了一个JS文件，但服务器更新了，你的版本号没变，导致用户用的还是旧JS，功能报错。
- 你缓存了大量图片，结果用户手机存储不足，WebView被系统强制清缓存。

所以，我的原则是：缓存那些“不变”或“变化可预测”的东西。比如：
- 版本号、配置项（缓存时间可设长一点，比如7天）。
- 用户头像、常用地址（缓存到用户主动清除或更新）。
- 而像新闻列表、实时数据，只缓存“上一次看过的内容”作为降级展示，不要当作主力数据源。

最后送你一个检查清单，当你做完缓存后，逐条验证：
□ 关闭网络，页面能否显示核心内容？
□ 更新H5版本后，用户是否能看到新内容（而不是旧缓存）？
□ 在弱网环境下（比如模拟3G），首次加载时间是否小于3秒？
□ 如果用户清除了App数据，H5是否能正常降级（显示空白还是显示“加载失败”的友好提示）？

做到这几点，你的嵌H5缓存方案才算真正“有实际价值”，而不是网上那些复制粘贴的代码段。