协商缓存是发轻量请求验证，非跳过网络通信；浏览器携带if-none-match或if-modified-since头向服务器验证，服务器返回304复用缓存或200下发新内容。
协商缓存不是“不发请求”，而是“发轻量请求验证”
很多人误以为协商缓存能像强缓存一样跳过网络通信，其实不然。当强缓存失效（比如 Cache-Control: no-cache 或 max-age=0）后，浏览器一定会发起一次 HTTP 请求，但它带的不是完整取资源的意图，而是两个关键验证头：If-None-Match 或 If-Modified-Since。服务器收到后不返回内容体，只比对、判断，再决定返回 304 Not Modified（复用本地缓存）还是 200 OK（下发新内容）。
ETag 比 Last-Modified 更可靠，但得配对使用
ETag 是服务端为资源生成的内容指纹（如 "abc123"），精度高、不依赖时间；Last-Modified 只精确到秒，且构建过程重写文件时间戳会导致误判。但注意：两者不能混用——如果响应里同时返回了 ETag 和 Last-Modified，浏览器优先用 ETag 发起 If-None-Match；如果只返回 Last-Modified，才退而用 If-Modified-Since。Nginx 默认开启 ETag，Apache 需确认未禁用 FileETag。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
HTML 文件必须走协商缓存，否则用户看不到更新
HTML 是整个页面的入口，它的内容变化往往意味着 JS/CSS 路径、版本号或结构已更新。如果给 HTML 配了 max-age=3600，用户刷新时可能还在用旧 HTML，导致加载老路径的 JS，进而白屏或功能异常。正确做法是：Cache-Control: no-cache（强制走协商）+ 服务端生成 ETag（基于 HTML 内容哈希）。这样每次用户刷新，浏览器都发一个带 If-None-Match 的请求，服务器一比对就知道该返回 304 还是新 HTML。
协商失败的典型现象和排查点
常见错误表现包括：改了 HTML 内容但刷新没反应、Network 面板里 HTML 状态一直是 200 (from disk cache)、明明加了 ETag 却从不返回 304。可能原因有：
- 服务端没真正生成
ETag（比如 Nginx 配了etag off;，或静态文件服务直接透传但没计算哈希） - 反向代理（如 CDN）剥离或覆盖了
ETag响应头 - 开发环境 Webpack Dev Server 返回了
Cache-Control: no-store，但你本地又手动加了缓存头，导致磁盘缓存残留 - HTML 里内联了时间戳或随机数（如
<script src="app.js?t=123"></script>），让每次 URL 都不同，协商逻辑根本没机会触发
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
