HarmonyOS鸿蒙Next中请问CacheMode.Default的缓存刷新机制是什么样的,是优先使用未过期的缓存。如果缓存不存在,则从网络获取吗?但是过期还是不过期你们是怎么判断的呢?怎么界定是不是有没有过期?
HarmonyOS鸿蒙Next中请问CacheMode.Default的缓存刷新机制是什么样的,是优先使用未过期的缓存。如果缓存不存在,则从网络获取吗?但是过期还是不过期你们是怎么判断的呢?怎么界定是不是有没有过期? 【问题描述】:问题详细描述
请问CacheMode.Default 的缓存刷新机制是什么样的,是优先使用未过期的缓存。如果缓存不存在,则从网络获取吗?但是过期还是不过期你们是怎么判断的呢?怎么界定 是不是有没有过期?
【版本信息】:开发工具版本:6.0、手机系统版本;mata60、Api语言版本:api:20
尊敬的开发者,您好,
服务器未配置Cache-Control的话,如果响应包含 Last-Modified,Web 组件将采用启发式缓存算法估算过期时间,RFC 建议的启发式算法为:freshness_lifetime = (Date_value - Last-Modified_value) × 10%,服务器后续修改配置不会自动同步到已缓存的条目中。可以尝试清除缓存后重新请求服务器
更多关于HarmonyOS鸿蒙Next中请问CacheMode.Default的缓存刷新机制是什么样的,是优先使用未过期的缓存。如果缓存不存在,则从网络获取吗?但是过期还是不过期你们是怎么判断的呢?怎么界定是不是有没有过期?的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
使用cacheMode()配置页面资源的缓存模式,Web组件为开发者提供四种缓存模式。
- 当mode为Default时,优先使用未过期的缓存。如果缓存不存在,则从网络获取。
- 有没有缓存和过期不过期是按上次请求返回的缓存策略和当前系统时间计算的。
请求返回后的缓存策略和行为如下表:
| Cache-Control | 本地是否存缓存 | 缓存和请求行为 | 过期行为 |
|---|---|---|---|
| max-age=N | 存内存 + 磁盘 | 有效期内直接读缓存 | 过期走协商 304 |
| no-cache | 缓存 | 每次请求校验 | 永远协商 |
| no-store | 不缓存 | 每次全新请求 | 无缓存 |
| immutable+max-age | 缓存 | 不发请求 | 到期后协商 |
| private / public | 缓存 | 和 max-age 一致 | 和 max-age 一致 |
| must-revalidate | 缓存 | 有效期内走缓存 | 断网不可用旧缓存 |
| 无任何缓存头 | 有 Last-Modified 则缓存 | 启发式 10% 时长内直接读缓存 | 超时协商;无 Last-Modified 仅短期内存缓存 |
CacheMode.Default 基本遵循 Web/HTTP 缓存语义:优先看响应头里的 Cache-Control、Expires、ETag、Last-Modified 等信息,能命中有效缓存就用缓存,否则重新请求。
如果之前服务端没配 Cache-Control,Web 组件可能已经按启发式规则缓存过旧资源;后来再改成 no-cache,并不一定能让已经存在的旧缓存立刻全部失效。建议同时做几件事:1. 资源 URL 加版本号或 hash,例如 app.js?v=20260621;2. 服务端返回 Cache-Control: no-cache 或 no-store,并配合 ETag/Last-Modified;3. 调试阶段可以清 Web 缓存或换一个测试 URL,确认新响应头已经生效。
CacheMode.Default 可以理解成一种默认缓存策略,但它不是简单的“有缓存就用,没有缓存走网络”。
大概逻辑是:
请求 → 检查本地缓存 → 判断缓存是否有效 → 使用缓存或者重新请求
缓存是否过期,不是由你调用接口时判断,而是由缓存机制根据缓存信息判断。
一般会参考这些信息:
- 缓存时间(TTL)
- HTTP 响应头里的缓存控制信息
- 缓存记录保存时间
- 服务端返回的缓存策略
比如:
服务端返回:
Cache-Control: max-age=300
意思就是:
缓存保存 300 秒。
那么:
第一次请求 → 网络获取 → 保存缓存和时间
5分钟内再次请求 → 使用缓存
超过5分钟 → 缓存失效 → 重新请求网络
所以:
缓存存在 + 未过期 → 优先使用缓存
缓存不存在 → 网络请求
缓存过期 → 根据策略重新校验或者重新请求
如果服务端没有返回缓存时间,一般框架会按照自己的默认策略处理,不建议依赖默认过期时间。
实际项目里更推荐:
接口返回明确缓存策略 → 客户端按策略缓存
比如:
天气数据:
缓存10分钟
新闻:
缓存30分钟
用户信息:
短缓存或者不缓存
另外注意:
CacheMode.Default 一般是 HTTP 缓存行为,不是业务缓存。
如果你的需求是:
“这个接口一天只请求一次”
这种不要依赖 Default,需要自己做:
数据 + 时间戳
希望能帮到你~~~
CacheMode.Default 是 Web 组件的缓存模式,官方枚举说明就是“优先使用未过期 cache 加载资源,无效或无 cache 时从网络获取”。也就是说,您理解的“未过期用缓存,不存在走网络”是对的,但“是否过期”不是业务代码随便定的,主要取决于服务端给 Web 资源返回的 HTTP 缓存头。
建议这样排查:1)Web 显式写清模式,避免后续维护误改;2)检查响应头是否有 Cache-Control: max-age、no-cache、no-store、Expires、ETag、Last-Modified;3)需要强刷时临时用 CacheMode.Online 或 URL 加版本号;4)不要把 Web 的 cacheMode 和 @ohos.net.http 的请求缓存混在一起理解。
示例:
Web({ src: this.url, controller: this.controller })
.cacheMode(CacheMode.Default)
// 服务端静态资源示例
// Cache-Control: max-age=600
// ETag: "home-v12"
如果服务端没给明确缓存头,Web 引擎可能按启发式规则处理,不建议依赖这种结果。参考:Web cacheMode 属性 https://developer.huawei.com/consumer/cn/doc/harmonyos-references/arkts-basic-components-web#cachemode ;CacheMode 枚举 https://developer.huawei.com/consumer/cn/doc/harmonyos-references/arkts-basic-components-web-e#cachemode
尊敬的开发者,您好,
关于您反馈的问题
Web的缓存模式由配置cacheMode和服务端返回的Cache-Control决定,默认default模式下,服务端返回Cache-Control携带no-store和no-cache,表示不缓存;Cache-Control: max-age决定缓存时长;
Web组件cacheMode模式为None模式,优先使用缓存,无缓存则从网络获取资源;
Web组件cacheMode模式为Online模式,不使用缓存,从网络获取最新资源;
Web组件cacheMode模式为Only模式,仅使用缓存加载;
这个知道;我们想知道 过期还是不过期你们是怎么判断的呢?怎么界定 是不是有没有过期?
尊敬的开发者,您好
Web组件内部遵循标准的HTTP缓存协议,缓存过期时间取决于服务器设置的cache-control,例如 Cache-Control: max-age=3600表示资源在1小时内未过期,超过1小时缓存过期
在 HarmonyOS 中, CacheMode.Default 的缓存刷新机制需要区分你使用的是 WebView 组件 还是 HTTP 网络请求模块,两者的缓存机制完全不同的。
CacheMode.Default 在 WebView 中是标准 HTTP 缓存行为,过期判断完全依赖服务器响应头;在原生 HTTP 模块中则需要手动实现过期逻辑。你的服务器必须返回正确的 Cache-Control 或 Expires 头,否则缓存可能无法按预期工作。
CacheMode.Default:优先使用未过期缓存,无缓存则走网络。过期判断依据HTTP响应头中的Cache-Control的max-age、Expires、Date/Age等字段计算有效性。若响应无缓存头,则默认不缓存或按系统策略临时存储。本地缓存存在且未超时即视为有效;超时或缺失则重新请求。
在HarmonyOS NEXT中,CacheMode.Default 遵循标准HTTP缓存语义。当发起请求时,会先检查本地缓存:
- 缓存存在且未过期:直接返回缓存数据,不发网络请求。
- 缓存不存在或已过期:从网络获取数据,成功后按响应的缓存规则更新缓存。
过期判断依据:主要看响应头中的 Cache-Control(如 max-age 指令)和 Expires 字段,对比当前时间计算是否超出有效期。如果响应头没有任何缓存控制字段,则默认不缓存或视为立即过期,重新请求网络。
简单说:是否“过期”由服务端返回的缓存策略确定,而不是客户端随意定义。
