浏览器缓存流程分三步：先判强缓存，失效后走协商缓存，两者都失效才发起新请求；f5跳过强缓存但走协商缓存，ctrl+f5强制发完整请求；html建议设no-cache或max-age=0。
浏览器缓存流程到底分几步？
浏览器加载一个 HTML 页面时，并不是简单“有缓存就用、没缓存就拉”，而是严格按顺序走一套决策链。关键在于：强缓存先判，不命中才进协商缓存，两者都失效才发起新请求。这个流程不可跳过、不可颠倒。
- 首次访问：无本地缓存，直接发请求，服务器返回资源 +
Cache-Control或Expires等响应头，浏览器据此存入缓存并记录有效期 - 后续访问：浏览器先检查强缓存是否有效——比对当前时间与
max-age起始时间，或与Expires绝对时间；若未过期，直接从内存/磁盘读取，不发任何网络请求 - 强缓存失效后：浏览器自动带上
If-None-Match（对应ETag）或If-Modified-Since（对应Last-Modified）发起条件请求；服务器比对后，若资源未变，返回304 Not Modified，浏览器复用本地副本；若已变，返回200+ 新内容
为什么 F5 刷新和 Ctrl+F5 行为完全不同？
这是最常被误解的操作——它们触发的缓存路径根本不同，不是“刷新力度大小”的问题，而是强制绕过的层级不同。
-
F5（普通刷新）：浏览器会忽略强缓存（即跳过max-age判断），但依然发送带If-None-Match或If-Modified-Since的请求，走协商缓存流程；如果服务器返回304，页面看起来“没变”，其实仍是缓存内容 -
Ctrl+F5（强制刷新）：浏览器清空所有缓存判断逻辑，既不查强缓存，也不发条件请求，而是直接发完整 GET 请求，带Cache-Control: no-cache和Pragma: no-cache头，服务器必须返回全新响应（200） - 注意：
Ctrl+F5不能绕过 Service Worker 的拦截——如果页面注册了 SW 且它主动fetch并返回缓存，那依然可能拿到旧内容
HTML 文件本身该设多长缓存？
HTML 是页面的入口，它的缓存策略直接影响用户能否看到最新结构和链接。设太长（比如 max-age=31536000）极易导致用户卡在旧版页面，连新 JS/CSS 链接都拿不到。
- 生产环境建议：HTML 响应头设
Cache-Control: no-cache或max-age=0，强制每次进入都走协商缓存；配合服务器正确返回ETag或Last-Modified，变更时自然更新 - 绝对不要用
no-store：它禁用所有缓存（包括内存缓存），每次都要重新下载整个 HTML，对首屏性能伤害很大 - 开发阶段可临时设
Cache-Control: max-age=5，方便快速验证，但上线前必须改掉
怎么确认当前请求走的是哪一层缓存？
光看 Network 面板里的 “Size” 列是不够的——from memory cache 和 from disk cache 都属于强缓存命中，但 304 是协商缓存，而 200 才是全新响应。真正要看的是请求的完整生命周期。
- 打开开发者工具 → Network → 刷新页面 → 点击某个 HTML 请求 → 查看 Headers 标签页：
• 如果Response Headers里有Cache-Control且max-age值较大，再看Size显示from memory cache，说明强缓存生效
• 如果Request Headers里出现If-None-Match或If-Modified-Since，且响应状态是304，说明走协商缓存
• 如果Request Headers里有Cache-Control: no-cache，且响应是200，那就是强制刷新或服务端禁用了缓存 - 容易被忽略的一点：某些 CDN 或反向代理会在响应头里覆盖原始
Cache-Control，务必检查最终到达浏览器的响应头，而不是只看自己服务器的日志
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
