must-revalidate 要求缓存过期后必须验证有效性，不可直接使用旧内容；需搭配 max-age 或 expires 使用，依赖 ETag 或 Last-Modified，验证失败时禁止降级使用过期缓存。
must-revalidate 不是让浏览器“跳过缓存”，而是明确约束：缓存可以存，但一旦过期，绝不能直接用旧内容——必须先向服务器验证有效性，收到 304 才能复用，收到 200 就必须更新。
must-revalidate 的生效前提是缓存已过期
它只在缓存“变 stale”（即超过 max-age 或 expires 时间）后起作用。过期前，浏览器照常使用本地副本，不发起验证；过期那一刻起，每次使用前都强制触发条件请求（如带 If-None-Match 或 If-Modified-Since）。
- 单独写
Cache-Control: must-revalidate没有效果——必须搭配max-age或expires明确有效期 - 例如：
Cache-Control: public, max-age=60, must-revalidate表示：缓存 60 秒内直取；第 61 秒起，每次使用前都必须验证 - 若服务器宕机或网络异常导致验证失败，浏览器不得降级使用过期缓存（这是它比 no-cache 更严格的地方）
必须有校验依据：ETag 或 Last-Modified
没有 ETag 或 Last-Modified，验证就无从谈起——must-revalidate 会形同虚设。
- Nginx 对静态文件默认生成 ETag；动态接口（如 /api/order）需后端在响应头中主动设置
ETag或Last-Modified - 验证请求发出后，服务器必须正确识别
If-None-Match或If-Modified-Since，并按规范返回 304（未修改）或 200（新内容） - 若后端忽略验证头、一律返回 200，浏览器会更新缓存，但失去“仅验证不传体”的带宽优化效果
避免与其他指令冲突
must-revalidate 的语义会被更强限制的指令覆盖，配置时需注意兼容性。
- 不要和
no-cache同时用：no-cache 要求每次使用前都验证，与 must-revalidate 的“仅过期后验证”逻辑不同，且部分实现可能优先执行 no-cache - 绝对不要加
no-store：它禁止任何缓存，直接废掉 must-revalidate 的存在前提 - 慎用
private或no-transform等修饰符，确保它们不干扰验证流程
验证是否生效的简单方法
用 curl 模拟两次请求，观察状态码和响应头变化，是最直接的确认方式。
- 首次请求：
curl -I https://yoursite.com/status，确认响应含Cache-Control: ..., must-revalidate和ETag - 等待超时（如 max-age=60，则等 61 秒），再发带验证头的请求：
curl -I -H 'If-None-Match: "xxx"' https://yoursite.com/status - 若返回 304 → 验证机制工作正常；若返回 200 + 新 ETag → 说明资源已更新，缓存被刷新
