HarmonyOS 7 HTTP 缓存体系：Remote Communication Kit 的内存、磁盘缓存与拦截器设计

同一张图片，每次打开都重新走一遍网络——这就是没做缓存。

做信息流页面的时候，最开始的思路很简单：点请求就发，返回数据就渲染。每次进页面都重新拉一遍数据。

跑了一段时间发现问题：用户来回翻页面，每次都重新请求，流量费了，加载也慢。尤其是图片，同一张图每次都重新下载。

这时候才意识到：HTTP 请求不是每次都要出门的。有一套完整的缓存机制，决定了这个请求到底要不要发网络。

一、一次请求到底要不要出门

先把请求的决策链路理一遍：

应用发起请求
↓
查内存缓存 → 命中？直接返回
↓ 没命中
查磁盘缓存 → 命中？加载并返回
↓ 没命中
查缓存规则 → 要不要请求？
↓
发网络请求
↓
返回数据 → 更新缓存

可以把整个流程想成"查仓库"：

• 内存缓存是桌子上，拿最快；
• 磁盘缓存是仓库，拿稍慢；
• 仓库都没有，才要去外面采购（发网络）。

二、HTTP Cache 的双层结构

Remote Communication Kit 的 HTTP Cache 是双层结构：

两次请求之间，先查内存，命中了直接返回；内存没有再查磁盘，磁盘有就加载；都没有才发网络。

三、缓存命中的判断依据

不是所有请求都该缓存。系统是根据 HTTP 头里的 Cache-Control 来判断的：

很多人做缓存的时候，自己写了一套规则，不管服务端的 Cache-Control。这不对——服务端说这个资源不能缓存，你自己缓存了，那数据就不对了。

四、缓存一致性的问题

缓存最大的问题不是"怎么存"，是"怎么保证一致"。

最容易踩的坑就是：所有接口一律缓存。那接口更新了，用户看到的还是旧数据。

正确的做法是：

• 静态资源（图片、配置）可以长缓存；
• 动态接口（用户信息、列表）要短缓存或者不缓存；
• 敏感数据绝对不能缓存。

五、Session 间共享缓存

如果你的应用里有多个 RCP Session，每个都建一套缓存，那就是重复了。

正确的做法是：所有 Session 共享同一个缓存实例。这样一次请求，所有地方都能用。

还有个坑：缓存目录无限增长。存的东西越来越多，磁盘空间占满了。要做合理的淘汰策略，缓存满了自动清理旧的。

六、自定义拦截器

有些场景需要自己控制缓存策略。这时候可以用自定义拦截器。

比如：

• 带用户 token 的请求，缓存 key 里要带上用户 ID，不然 A 用户的缓存被 B 用户用了；
• 特定接口强制刷新，忽略缓存；
• 特定接口完全不走缓存。

这些都可以在拦截器里自己控制。

七、几个容易踩的坑

第一个坑：所有接口一律缓存。动态接口也缓存，数据更新了用户看不到。

第二个坑：只根据 URL 判断缓存。URL 一样但用户不一样，缓存串了。

第三个坑：登录用户之间共享敏感缓存。A 用户的缓存被 B 用户用了，这是安全问题。

第四个坑：接口更新后旧缓存长期不失效。没有过期策略，一直用旧数据。

第五个坑：多个 Session 各建一套缓存。重复存储，浪费空间。

这次做缓存最大的体会是：缓存不是"存下来就能用"，是一套完整的决策系统。什么时候存、存多久、什么时候更新、什么时候不用缓存，每一步都有讲究。加缓存很简单，加对缓存很难。