前言

网络请求一多，性能问题很快就会冒出来。列表反复刷新，详情页来回进入，首页数据频繁重拉，这些场景都会把同一份内容一遍遍从网络取回来。流量会增加，请求时延会堆起来，弱网下的体验也会明显变差。

鸿蒙 6.0.0(20) 已经把 HTTP 缓存能力放进了 Remote Communication Kit，应用可以通过 ResponseCache 给 Session 配置缓存。缓存能力从这一版本开始进入正式支持范围。缓存一旦接到 Session 上，后续请求就能走统一的缓存链路，不需要每个业务模块各写一套本地缓存逻辑。

一、先把 ResponseCache 的能力边界看清楚

ResponseCache 适合处理重复读取、更新频率可控、命中后能直接复用的 HTTP 响应。接口接入方式也很直接，先创建 ResponseCache，再把它放进 createSession 的 requestConfiguration.cache 里。当前参考文档和搜索结果里都已经给出了这套写法，持久化缓存的文件路径通过 persistent.kind = 'file-system' 和 pathToFolder 指定。

这套能力能解决很多工程上的重复劳动。Session 层拿到缓存之后，请求是否复用缓存、缓存记录放在哪里、过期策略如何落地，都会统一收口到同一层。项目里如果原来把 HTTP 响应缓存拆在页面、仓储层和工具函数里，后面维护会很累，ResponseCache 正好适合把这部分逻辑收回来。

缓存也有边界。更新频率特别高、每次请求都依赖强实时返回的数据，不适合盲目缓存。缓存适合解决重复读取，不适合替代业务层的数据一致性判断。项目里最好先把接口按内容类型分开，再决定哪些 Session 或哪些请求应该挂缓存。缓存是基础设施，业务策略仍然要在应用层自己定。

二、基础接入先做好，过期策略再跟上

最基础的接法，就是先创建一个带持久化目录的 ResponseCache，再把它挂进 Session。

import { rcp } from '@kit.RemoteCommunicationKit';

const responseCache = new rcp.ResponseCache({
  persistent: {
    kind: 'file-system',
    pathToFolder: context.filesDir + '/http_cache'
  }
});

const session: rcp.Session = rcp.createSession({
  requestConfiguration: {
    cache: responseCache
  }
});

这段代码接好之后，缓存链路就已经开始工作了。后面要细化控制，重点会落到过期策略。当前 API 已经提供 defaultExpirationPolicy，并且支持多种时间策略类型。搜索结果和 API 差异页能确认，时间限制策略至少包含 relative、absolute、sliding 和 never 这几种 kind，时间单位支持 seconds、minutes、hours、days。

如果你的接口适合做相对时间缓存，比如资讯流、榜单页、配置数据，这类内容最常见的写法就是相对时间策略。

import { rcp } from '@kit.RemoteCommunicationKit';

const responseCache = new rcp.ResponseCache({
  persistent: {
    kind: 'file-system',
    pathToFolder: context.filesDir + '/http_cache'
  },
  defaultExpirationPolicy: {
    kind: 'relative',
    time: {
      units: 'minutes',
      value: 30
    }
  }
});

const session = rcp.createSession({
  requestConfiguration: {
    cache: responseCache
  }
});

过期策略定得太短，命中率会很差。定得太长，数据陈旧的风险会变高。工程里更稳的做法，是按接口类型拆 Session，给资讯、图片、配置、用户态数据分别设不同策略，而不是把所有请求都压到一套缓存时间上。官方文档已经确认 defaultExpirationPolicy 属于 Session 缓存配置的一部分，这种拆分方式后面会更好维护。(华为开发者)

三、Session 间共享缓存能省很多重复请求

项目只要稍微复杂一点，就很容易同时存在多个 Session。比如一个 Session 走普通业务请求，一个 Session 走图片或文件下载，一个 Session 走登录态隔离请求。Session 多了之后，相同内容被重复拉取的问题会更明显。鸿蒙文档已经给出了 Session 间缓存共享的正式能力，而且路径说得很清楚。

第一种做法，是多个 Session 直接引用同一个 ResponseCache 实例。第二种做法，是创建不同的 ResponseCache 实例，但让它们指向同一个缓存目录。只要底层缓存存储路径相同，Session 之间就可以共享缓存数据。

先看最直接的共享方式，同一个缓存实例接到多个 Session：

import { rcp } from '@kit.RemoteCommunicationKit';

const sharedCache = new rcp.ResponseCache({
  persistent: {
    kind: 'file-system',
    pathToFolder: context.filesDir + '/shared_http_cache'
  }
});

const sessionA = rcp.createSession({
  requestConfiguration: {
    cache: sharedCache
  }
});

const sessionB = rcp.createSession({
  requestConfiguration: {
    cache: sharedCache
  }
});

如果项目里不同模块各自创建 Session，不方便共用同一个实例，也可以统一缓存目录：

import { rcp } from '@kit.RemoteCommunicationKit';

const cacheA = new rcp.ResponseCache({
  persistent: {
    kind: 'file-system',
    pathToFolder: context.filesDir + '/shared_http_cache'
  }
});

const cacheB = new rcp.ResponseCache({
  persistent: {
    kind: 'file-system',
    pathToFolder: context.filesDir + '/shared_http_cache'
  }
});

const sessionA = rcp.createSession({
  requestConfiguration: {
    cache: cacheA
  }
});

const sessionB = rcp.createSession({
  requestConfiguration: {
    cache: cacheB
  }
});

这类共享最适合资源重复度高的场景。首页列表和详情页读取同一份摘要数据，多个模块共用同一批图片资源，或者应用内多个业务区都会访问相同配置接口，这些都适合做 Session 间缓存共享。接口已经支持这条路，项目层面更值得花精力的地方，是把共享边界定清楚，避免把登录态隔离要求不同的数据也混进同一份缓存。

四、离线和监控这两件事，别交给默认行为自己完成

很多人一看到持久化缓存，就会顺手把它理解成离线能力已经具备。工程里最好不要这么处理。ResponseCache 负责的是 HTTP 响应缓存，能不能在离线场景下直接用、哪些页面允许展示旧数据、联网后怎样刷新、冲突出现时怎样回滚，这些都还是业务层的问题。

当前官方资料已经补了自定义缓存拦截器能力，从 6.0.0(20) 开始可用，这恰好给了项目一个更灵活的切入点。想做更细的离线策略、缓存命中日志、调试输出，拦截器会比单纯依赖默认链路更好用。

监控这块也一样。文档没有把一整套命中率统计面板直接做成现成 API 交给你。项目里如果需要看命中效果，最稳的做法是结合自定义缓存拦截器，把关键接口的缓存命中、回源、过期重取、异常回退这些动作记到日志里，再按接口维度做统计。这样做虽然多一点工程工作，后面排查缓存失效、缓存目录膨胀、弱网下异常回源这些问题会轻很多。

落到项目实践里，可以先把这四件事定下来。第一，哪些接口必须缓存。第二，哪些接口只允许短缓存。第三，哪些 Session 共享同一份缓存。第四，哪些关键请求要在拦截器里打日志。只要这几条先收住，ResponseCache 的接入价值会很快体现出来。系统已经把 HTTP 缓存基础设施搭好了，项目里更值得关注的是策略分层。

总结

鸿蒙 6 API 20 已经把 HTTP 缓存正式放进 Remote Communication Kit，ResponseCache 可以直接挂到 Session 上使用，持久化缓存目录、默认过期策略、Session 间缓存共享也都已经进入正式能力范围。

工程里更稳的接法很清楚。先把缓存配置收口到 Session 层，再按接口类型拆过期策略，重复资源统一共享缓存，离线和监控通过业务层规则加自定义缓存拦截器补齐。这样处理之后，性能收益、维护成本和后续排查都会更可控。