浏览器缓存机制核心是强缓存与协商缓存：强缓存通过Cache-Control（优先）和Expires控制本地直接读取，不发请求；协商缓存则在强缓存失效后，用ETag/If-None-Match或Last-Modified/If-Modified-Since向服务器验证，未变则返回304复用缓存。
HTML缓存机制不是“把整个网页存起来就完事了”，而是由浏览器根据服务器返回的HTTP响应头，**自动决定要不要用本地副本、什么时候该去问服务器、问什么问题**。核心逻辑就两条：强缓存优先走本地，协商缓存再找服务器确认。
强缓存靠Cache-Control和Expires直接跳过请求
浏览器拿到资源时，如果响应头里有Cache-Control: max-age=3600，它就会记下“这个文件未来1小时内不用重下”，下次访问同一URL，连网络请求都不发，直接从内存或磁盘读取。同理，Expires给的是绝对时间点（如Expires: Wed, 22 Oct 2026 08:00:00 GMT），但它的优先级低于Cache-Control，且依赖客户端时间准确——一旦用户设备时间错得离谱，缓存就可能提前失效或永久不更新。
常见错误现象：
- 改了
index.html但用户刷新还是旧版 → 很可能服务器配了Cache-Control: public, max-age=86400，而HTML本该设成max-age=0或no-cache - CDN上资源明明更新了，用户端却没生效 → CDN节点缓存了
max-age，但源站没变，CDN不会主动刷新
协商缓存靠ETag和Last-Modified做轻量验证
当强缓存过期，浏览器不会直接重下整个文件，而是带着验证信息发起一次“条件请求”：比如在请求头里加If-None-Match: "abc123"（对应服务器之前返回的ETag），或者If-Modified-Since: Tue, 08 Oct 2026 10:20:00 GMT（对应Last-Modified）。服务器比对后，若资源未变，就只返回304 Not Modified，浏览器继续用本地副本；变了才返回200和新内容。
立即学习“前端免费学习笔记（深入）”；
关键差异：
-
ETag是服务端生成的唯一标识（如文件内容哈希），精度高，适合内容可能被修改但时间戳不变的场景（例如gzip压缩开关切换） -
Last-Modified只精确到秒，且依赖文件系统mtime，容易误判（比如部署时touch了文件但内容没变） - 两者可共存，但
ETag优先级更高；若都不存在，浏览器只能无脑重下
no-cache不等于“不缓存”，而是“每次都要验证”
这是最容易误解的点。Cache-Control: no-cache的意思是“允许缓存，但每次用之前必须向服务器验证 freshness”，它依然会存下资源副本，只是绕过了强缓存阶段，强制进入协商缓存流程。真正禁止缓存的是no-store——浏览器连副本都不留，所有请求必走网络。
典型使用场景：
- 登录态相关的HTML页面 → 设
no-cache，确保每次打开都检查session是否过期 - 实时行情页的JSON接口 → 必须
no-store，避免敏感数据滞留在磁盘或代理中 - 静态JS/CSS文件带版本号（
app.123456.js）→ 可放心用public, immutable, max-age=31536000，因为URL已变，旧缓存自然失效
真正难处理的从来不是“怎么设缓存”，而是当多个缓存层叠加时（浏览器 + CDN + 反向代理 + Service Worker），一条响应头在某一层被覆盖、忽略或解释不一致，导致行为偏离预期。比如Nginx配了expires 1y，但后端PHP又输出Cache-Control: no-cache，最终以谁为准？答案是：HTTP规范规定Cache-Control优先，但某些老旧CDN会无视它——这时候得看实际抓包里的响应头到底是什么。
