HTTP缓存机制：强缓存与协商缓存

可视化演示

\u5c55\u793a32\u4f4d\u5355\u7cbe\u5ea6\u6d6e\u70b9\u6570\u7684\u5b58\u50a8\u683c\u5f0f\uff1a1\u4f4d\u7b26\u53f7\u4f4d\u30018\u4f4d\u6307\u6570\u4f4d\u300123\u4f4d\u5c3e\u6570\u4f4d\uff0c\u8c03\u6574\u6570\u503c\u53ef\u5b9e\u65f6\u67e5\u770b\u4e8c\u8fdb\u5236\u5206\u89e3\u8fc7\u7a0b\u3002

缓存初识

继续我们的图书馆。你发现管理员有一套“常借图书登记册”：你第一次借《深度学习》时，管理员从总馆调来一本，并告诉你：“这本书我复印了一份放你桌上，下次直接看复印件。”此后再借，如果复印件还能用，你连管理员都不用找——这是强缓存找副本的直觉。

但在计算机网络里，“复印件”就是浏览器本地磁盘上的缓存文件。HTTP协议设计者们意识到：Web页面里90%的资源（图片、CSS、JS）在短时间内根本不会变化，每次访问都从服务器重新下载，是巨大的浪费。于是有了缓存机制——把服务器返回的资源连同“保鲜期”一起存下来。

HTTP缓存分两大类：强缓存（浏览器自认为副本新鲜，完全不发请求）和协商缓存（浏览器不确定副本是否新鲜，发一个轻量请求让服务器做裁决）。两者的共同点是都用上了本地副本；区别在于，强缓存省掉了整个网络往返，协商缓存则多了一次“确认”。

那么，是不是缓存越多越好？也不是。缓存就像复印本——如果原著已经修订，你还捧着旧复印件，就会看到过时信息。这就是缓存与“新鲜度”的永恒矛盾：缓存要快，就必须大胆复用；但要准确，就必须小心验证。强缓存与协商缓存，正是解决这一矛盾的两把尺子。

强缓存规则

现在管理员给了你一张“绿色通行证”：某些书，你在借阅期内可以直接从桌上拿走副本，连登记都省了。这张通行证上写着有效期——这就是强缓存。HTTP协议里，服务器通过响应头告诉浏览器：“这个资源，在过期之前你都别来问我，直接用本地副本。”

强缓存的核心指令是Cache-Control，它是HTTP/1.1时代制定的标准，也是最灵活的缓存控制头。它的取值组合非常丰富：max-age=3600表示副本在3600秒内新鲜；public表示任何节点（包括代理服务器）都能缓存；private表示仅供单个用户缓存。与之相对的是HTTP/1.0时代的Expires，它用一个绝对时间戳（如Wed, 21 Oct 2025 07:28:00 GMT）指定过期时刻。

如果响应头同时出现了Cache-Control和Expires，以Cache-Control为准——它是更现代的规则，能处理时区、时钟偏移等问题。比如Expires是绝对时间，一旦用户电脑时间不准，强缓存就立刻失效；而max-age是相对时间，从响应时刻开始计时，天然免疫时钟错误。

强缓存的命中不需要任何网络请求，浏览器直接从本地读取文件。所以你在DevTools里常见的"200 (from disk cache)"，就是强缓存命中的标志。它的速度极快，近乎瞬时。但代价是：在保鲜期内，服务器即使更新了资源，你也看不见。

协商缓存规则

借阅期的概念再推进一步：假设管理员说，“这些书你桌上的副本可以一直用，但我要求你每次来还书时，顺口问我一句'这书改过没'？如果我说没改，你就继续用旧副本。”这就是协商缓存——本地副本可能过期，但浏览器愿意先花一次轻量请求，换取“可能不用下载完整资源”的机会。

协商缓存有两个判据：Last-Modified（最后修改时间）和ETag（实体标签）。Last-Modified是服务器返回资源时附带的“最后修改时间”，浏览器下次请求时通过If-Modified-Since把这个时间带回给服务器，服务器对比当前资源的修改时间，若未变化则返回304状态码。

ETag则更精确——它是服务器为资源内容生成的哈希指纹（如"33a64df5"），只要内容变了，ETag就变。浏览器通过If-None-Match把ETag带回，服务器比对当前资源的ETag：

那Last-Modified和ETag谁更好？ETag更可靠——因为文件可能改了又改回原样，修改时间变了但内容一致；或者修改时间精度不够（如1秒内多次修改）。但ETag需要额外计算哈希。实践中通常同时使用：请求时两个验证头都带上，服务器先比对If-None-Match，若不一致再比对If-Modified-Since。只要任意一个验证通过，就返回304。

协商缓存的价值在于“用一次轻往返换掉一次重下载”。对于大体积的静态资源（几MB的JS文件），304省下的流量和带宽相当可观。它不像强缓存那样零请求，但比完全重新下载高效得多。

优先级判定

现在你手上有两本规则手册：一本写着“绿色通行证优先，过期了再去问管理员”，另一本写着“就算没过期，管理员也可能要求你验证”。当资源同时带有强缓存和协商缓存的条件时，浏览器遵循一个严格的顺序——先强缓存，后协商缓存。

这个优先级顺序是浏览器内置的：

特别注意：Cache-Control内部也有优先级。比如no-cache这个指令，它的意思是“可以用缓存，但每次都得先验证”，所以它实际上会强制跳过强缓存、直接进入协商缓存阶段。而max-age=0也有类似效果——剩余寿命恰好为0，强缓存失效，转入协商。

代理缓存的引入让优先级更加复杂：浏览器与源站之间可能还有CDN节点。浏览器先查自己的强缓存，没命中就请求CDN；CDN再查它的强缓存，没命中就回源站验证。每一层都是“先强后协”的递归结构。理解了这点，你就理解了整个Web缓存的骨架。

no-cache辨析

“no-cache“这个名字极具迷惑性——字面意思是”不要缓存“，但它真正的含义是”可以用缓存，但每次用之前必须验证“。这就像图书馆的”禁带出馆”书籍：你可以坐着看，但每次都要跟管理员登记一次。

所以Cache-Control: no-cache的效果是：强制跳过强缓存，每次请求都走协商缓存流程。它不禁止存储，只是禁止“未经验证的直接复用”。而Cache-Control: no-store才是真正的“禁止缓存”——浏览器和中间代理都不得保存任何副本。

这两个指令的误用代价很高。如果给静态资源加了no-store，每次刷新页面都要重新下载全部资源，配置CDN缓存时会被回源请求淹没；如果给包含敏感信息的API响应加了no-cache（而非no-store），虽然每次会验证，但缓存副本仍留在磁盘上，有安全风险。正确的姿势是：静态资源用max-age+指纹，动态HTML用no-cache，敏感数据用no-store。

指纹化策略

图书馆有个聪明的管理员：他给每本书的修订版起了个新名字《深度学习·第3版》。当第4版出来时，读者借的是《深度学习·第4版》，永远不会拿错版本。这就是指纹化——给静态资源的文件名打上内容哈希。

现代前端构建工具（Webpack、Vite）会自动把app.js变成app.a3f9d2.js，其中a3f9d2是文件内容的哈希值。只要文件内容变了，哈希就变，文件名也随之改变。这个新文件名意味着它是一个全新的资源，可以放心地设置超长max-age（比如一年）。

指纹化策略与CDN配合时，威力更大。假设你的静态资源部署在CDN上，CDN节点会缓存app.a3f9d2.js一年。当app.b4c0e1.js（新版本）上线时，用户的浏览器发现需要请求一个全新的URL，于是绕过旧缓存，直接从CDN拉取新文件——这一过程中，CDN的旧缓存依然有效，无需手动刷新。

但这里有个陷阱：index.html本身不能设长缓存。因为HTML是“入口文件”，它引用的JS/CSS文件名会随版本变化，如果HTML被强缓存一年，用户就永远看到旧页面。标准做法是：HTML用no-cache（每次验证），静态资源用指纹+长缓存。这样HTML始终最新，而静态资源只下载一次。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""HTTP缓存机制模拟器:演示强缓存与协商缓存的完整流程"""import hashlibimport time  class CacheEntry:    def __init__(self, data, max_age, etag=None, last_modified=None):        self.data = data        self.max_age = max_age        self.etag = etag or hashlib.md5(data.encode()).hexdigest()[:8]        self.last_modified = last_modified or time.time()        self.stored_at = time.time()     def is_fresh(self):        return (time.time() - self.stored_at) < self.max_age  class Server:    """模拟源站:资源会随时间变化"""     def __init__(self):        self.content = "v1: hello world"        self.updated_at = time.time()     def update(self, new_content):        self.content = new_content        self.updated_at = time.time()     def get_response(self, if_none_match=None, if_modified_since=None):        etag = hashlib.md5(self.content.encode()).hexdigest()[:8]        last_modified = time.strftime(            "%a, %d %b %Y %H:%M:%S GMT", time.gmtime(self.updated_at)        )        if if_none_match == etag:            return 304, None, etag, last_modified        if if_modified_since and self.updated_at <= if_modified_since:            return 304, None, etag, last_modified        return 200, self.content, etag, last_modified  class Browser:    """模拟浏览器缓存行为"""     def __init__(self, server):        self.server = server        self.cache = {}        self.request_count = 0     def fetch(self, url):        self.request_count += 1        entry = self.cache.get(url)         if entry and entry.is_fresh():            return "strong-cache-hit", entry.data         if entry:            status, data, etag, lm = self.server.get_response(                if_none_match=entry.etag,                if_modified_since=entry.last_modified,            )            if status == 304:                self.cache[url] = CacheEntry(                    entry.data, entry.max_age, etag, entry.last_modified                )                return "negotiated-304", entry.data         status, data, etag, lm = self.server.get_response()        self.cache[url] = CacheEntry(data, max_age=10, etag=etag)        return "fresh-200", data  def main():    srv = Server()    browser = Browser(srv)     for i in range(5):        res, body = browser.fetch("/api/news")        print(f"请求{i+1}: {res} | 内容: {body}")        if i == 2:            print("[服务器更新内容]")            srv.update("v2: hello world, refreshed")        time.sleep(0.5)  if __name__ == "__main__":    main()

1. class CacheEntry缓存条目，记录内容、保鲜期（max_age）、ETag指纹和存储时间，对应浏览器缓存的元数据。
2. def is_fresh(self)判断剩余寿命是否大于0，这是强缓存命中的核心条件。
3. class Server模拟源站，维护资源内容和最后修改时间，update方法模拟服务器更新资源。
4. def get_response服务器核心逻辑：先比ETag，再比Last-Modified，条件满足就返回304。
5. if if_none_match == etag:服务器端ETag精准比对，内容只要变过，ETag必然不同。
6. class Browser模拟浏览器，维护本地缓存字典和请求计数器。
7. if entry and entry.is_fresh():第一道闸门：强缓存命中，直接返回本地副本，零网络请求。
8. if status == 304:第二道闸门：协商缓存，服务器确认副本仍有效，用旧的但不重新下载。
9. self.cache[url] = CacheEntry(...)200响应后更新本地缓存，写入新的ETag和保鲜期。

常见误区

面试题