01

60 秒回答模板

缓存要按资源类型设计：入口 HTML 通常用 no-cache 或短缓存，保证每次发布后能拿到最新资源引用；带内容 hash 的 JS、CSS、字体等静态资产可以 long max-age + immutable，因为内容变化文件名会变；接口缓存要看数据实时性、用户维度和幂等性。强制刷新本质有三类：改变资源 URL，例如文件 contenthash、版本 query、接口版本号；改变缓存策略，例如 Cache-Control: no-cache/no-store 或降低 max-age；清理运行时缓存，例如 Service Worker 的 Cache Storage、IndexedDB、本地版本标记。代码层要避免给 HTML 永久强缓存，也不要指望 location.reload(true) 这种不可控方式解决发布缓存。

考点 核心机制与工程取舍
难度 中高频面试题
回答目标 按定义、机制、场景讲清楚
02

深入解析

01

先按资源类型分策略

HTML 是资源入口，必须容易更新；JS/CSS/字体等文件是静态资产，适合内容 hash 后长缓存；接口响应要按用户、权限、实时性和失败代价决定是否缓存。

02

静态资源靠内容指纹刷新

构建产物文件名带 contenthash，内容不变 URL 不变，浏览器可长期缓存；内容变化 URL 变化，自然绕过旧缓存。入口 HTML 更新后引用新 hash 文件，发布链路就闭合了。

03

入口 HTML 不要永久强缓存

如果 HTML 被 long max-age 缓住，用户拿不到新的资源清单，即使 JS 已经发布新 hash 也不会加载。HTML 更适合 Cache-Control: no-cache，让浏览器每次使用前验证。

04

强制刷新可以改变 URL 或缓存头

临时强制刷新可给资源加版本 query、升级接口路径、调整 Cache-Control 或返回新的 ETag。长期方案仍应回到内容 hash 和清晰的缓存头，而不是手工拼随机参数。

05

Service Worker 要单独处理

如果使用 Service Worker，浏览器 HTTP 缓存之外还有 Cache Storage。发布新版本时要设计 install、activate、skipWaiting、clients.claim、旧缓存清理和兜底刷新提示。

06

接口缓存要关注一致性

GET 接口可以使用 ETag、max-age、stale-while-revalidate 等策略，但用户态数据要带上认证和 vary 维度。强制刷新接口通常用 no-cache 请求头、版本参数或服务端失效缓存。

03

易错点

  • 给入口 HTML 配 long max-age，导致发布后用户仍加载旧资源清单。
  • 认为改 JS 文件内容就一定能让用户更新，忽略用户手里的 HTML 可能还引用旧文件名。
  • 滥用随机 query 让所有静态资源都失去长期缓存收益。
  • 使用 Service Worker 后只看 Network 缓存头，不清理 Cache Storage 里的旧响应。
04

面试官追问

为什么 HTML 不适合长缓存？

HTML 决定加载哪些 JS/CSS。如果 HTML 被旧版本缓存住，用户会一直引用旧资源清单，发布的新静态资源无法被发现。

contenthash 为什么能配合长缓存？

文件内容变化会生成新文件名，URL 变化后浏览器会请求新资源；内容不变则可以放心复用旧缓存。

Service Worker 缓存为什么会让强刷失效？

Service Worker 可以拦截请求并从 Cache Storage 返回旧响应，即使 HTTP 缓存已过期也可能命中自己的缓存策略，所以必须设计版本清理。

接口强制刷新怎么做？

可以请求时带 Cache-Control: no-cache、加版本或时间戳参数、更新 ETag，或在服务端主动失效 CDN/网关/内存缓存。具体取决于缓存在哪一层。