浏览器缓存机制

在HTTP缓存机制中，强缓存和协商缓存是控制资源缓存的两种核心方式，目的是减少重复请求、降低服务器压力、提升页面加载速度。

强缓存

强缓存由客户端（浏览器）自主判断是否使用本地缓存，无须向服务器发送请求。依赖于HTTP响应头中的缓存时效字段，若资源未过期，则直接从本地缓存读取<状态码通常为200 OK（from cache）或200 OK （memory cache）>。

控制字段

• Expires（HTTP/1.0）

​ 一个绝对时间，表示资源在该时间前有效。

​ 缺点：依赖客户端本地时间，若客户端时间与服务器时间不一致，可能导致缓存失效或过期缓存被误用。

• Cache-Control（HTTP/1.1，优先级高）

  用相对时间和指令控制缓存，更灵活可靠。

  • max-age=<second>资源有效期（秒），从请求成功时间开始计算。
  • public允许客户端和中间代理（如CDN）缓存该资源。
  • private仅允许客户端（如浏览器）缓存，中间代理不可缓存。
  • no-cache不使用强缓存，需进入协商缓存（强制验证缓存有效性）。
  • no-stroe禁止任何缓存（每次都需要从服务器获取最新资源）。

协商缓存

当强缓存失效（资源过期或被指令禁止）时，客户端会携带缓存标志向服务器发送请求时，由服务器判断缓存是否仍可用。

• 若缓存有效，服务器返回304 Not Modified，客户端复用本地缓存。
• 若缓存无效，服务器返回200 OK和新资源，客户端更新本地缓存。

缓存标识与验证机制

• Last-Modified & If-Modified-Since
  • 服务器响应时通过Last-Modified告知资源最后修改时间。
  • 客户端再次请求时，通过If-Modified-Since携带该时间，服务器对比：若资源未修改，返回304；否则返回新的资源和新的Last-Modified。
  • 缺点：无法识别秒内的修改（精度低），且资源内容未变但修改时间变了，会误判为无效。
• Etag & If-None-Match（优先级高）
  • 服务器响应时通过Etag生成资源唯一标识（如哈希值）。
  • 客户端再次请求时，通过If-None-Match携带该标识，服务器对比：若标识一致，返回304；否则返回新资源和新的Etag
  • 优点：精度高，能识别内容未改变但修改时间变化的情况。

协作流程

• 客户端首次请求资源，服务器返回资源和缓存规则（强缓存字段+协商缓存标识）。
• 再次请求时，先检查强缓存：若有效，直接使用本地缓存；若无效，进入协商缓存。
• 协商缓存中，服务器验证标识：有效则返回304，无效则返回新资源并更新缓存规则。

应用场景

• 强缓存：适用于静态资源（如图片、JS、CSS）内容变化不频繁，可设置较长max-age，配合文件名哈希实现更新时失效。
• 协商缓存：适用于动态内容或变化较频繁的资源（如API数据），通过Etag确保内容更新，同时减少重复传输。