谈谈 HTTP 的缓存机制，服务器如何判断缓存是否过期？

HTTP 缓存＝“先看本地冰箱够不够新鲜(强缓存)；不够再打电话问超市要不要换(协商缓存)”。服务器判断是否过期靠 Expires / Cache-Control 给出的“保质期”，以及 ETag / Last-Modified 做“指纹校验”。

一、缓存流程图解（关键决策链）

二、服务器判断缓存过期的核心机制

1. 强缓存阶段（无需询问服务器）

• Cache-Control 响应头（优先级最高）：

  Cache-Control: max-age=3600 // 资源有效期3600秒（1小时）

  • max-age=[秒]：资源有效期（从请求时间开始计算）

  • s-maxage=[秒]：仅对公共代理缓存有效（CDN专用）

  • no-store：禁止任何缓存（敏感数据场景）

  • no-cache：跳过强缓存，直接进入协商缓存

  • public：允许任何缓存方（浏览器/CDN）存储

  • private：仅允许用户浏览器缓存（禁止CDN）

• Expires 响应头（HTTP/1.0遗留）：

  Expires: Wed, 24 Jul 2024 08:30:00 GMT // 绝对过期时间

  • 缺陷：依赖客户端时钟同步，已被 Cache-Control 取代

2. 协商缓存阶段（需向服务器验证）

当强缓存失效时，客户端携带验证头发起条件请求：

• Last-Modified + If-Modified-Since

  # 响应头（服务器返回）
  Last-Modified: Wed, 17 Jul 2024 12:00:00 GMT
  ​
  # 请求头（客户端后续携带）
  If-Modified-Since: Wed, 17 Jul 2024 12:00:00 GMT

  • 服务器对比当前资源的修改时间

  • 问题：1秒精度不足，文件内容不变但修改时间可能变化

• ETag + If-None-Match（优先级更高）

  # 响应头（服务器返回）
  ETag: "33a64df551425fcc55e4d42a148795d9"
  ​
  # 请求头（客户端后续携带）
  If-None-Match: "33a64df551425fcc55e4d42a148795d9"

  • ETag 是资源内容的哈希值（如MD5）

  • 内容变化时 ETag 必变，精确判断内容变更

  • 分强弱验证：

    • 强ETag：字节级匹配（"xyz"）

    • 弱ETag：内容语义匹配（W/"xyz"，前缀 W/）

三、缓存决策关键头组合示例

场景1：静态资源（JS/CSS）长期缓存

HTTP/1.1 200 OK
Cache-Control: public, max-age=31536000 // 1年有效期
ETag: "fd562e25w5e41"

场景2：用户私密数据

HTTP/1.1 200 OK
Cache-Control: private, no-cache // 仅浏览器缓存且跳过强缓存

场景3：频繁变化的API数据

HTTP/1.1 200 OK
Cache-Control: no-cache           // 强制每次协商验证
ETag: "a3f5gd8e9k2"

四、缓存生效全流程演示

五、缓存陷阱与解决方案

六、最佳实践策略

📊 性能收益：合理缓存可使重复访问速度提升 300%+（HTTP Archive 数据）

七、调试技巧（Chrome DevTools）

缓存配置口诀：

静态资源长缓存，动态数据短校验， 哈希指纹破更新，HTML入口永不存。