HTML不应依赖Vary缓存协商，而应优先使用no-cache、must-revalidate、max-age=0配合ETag或Last-Modified；仅当后端根据Accept-Language、User-Agent或Accept-Encoding动态生成不同HTML时才需Vary。
HTML 本身不该依赖 Vary 做缓存协商——它该用 no-cache, must-revalidate, max-age=0 配合 ETag 或 Last-Modified，而不是靠 Vary 区分内容。
Vary 是给「同一 URL 返回不同内容」的场景准备的，比如压缩版本、语言版本、设备适配版。HTML 页面若真需要按 User-Agent 返回桌面/移动版，那才轮到 Vary；但现代 SPA 几乎都由前端路由或响应式 CSS 处理，后端 HTML 通常统一输出，此时加 Vary 只会降低缓存命中率，还可能引发 CDN 缓存分裂。
什么时候必须加 Vary？
只有当 Nginx / 后端根据请求头动态生成 HTML 内容时，才需要 Vary 确保缓存不混用：
- 服务端根据
Accept-Language渲染中/英文首页 → 需Vary: Accept-Language - Node.js 服务检测
User-Agent返回精简版 HTML（非 JS 路由）→ 需Vary: User-Agent - 使用 Brotli 压缩且 Nginx 未自动设置
Vary: Accept-Encoding→ 必须补上，否则 gzip 版本可能被错发给不支持的客户端
Vary 在 Nginx 中怎么写才不踩坑？
Nginx 的 add_header 默认不继承，容易漏配或被 upstream 覆盖。正确写法要满足三点：
- 放在
location块内，且紧贴内容处理逻辑之后（如proxy_pass或try_files后） - 多个值用英文逗号+空格分隔：
add_header Vary "Accept-Encoding, Accept-Language";（注意引号和空格） - 避免重复设置：如果上游（如 FastCGI 或反向代理）已发
Vary，Nginx 再add_header会覆盖而非合并 —— 此时改用more_set_headers（需安装headers-more-nginx-module）
Vary: Cookie 是高危操作，慎用
除非你明确知道每个用户看到的 HTML 都因 Cookie 完全不同（比如 SSR 渲染登录态 header），否则不要加 Vary: Cookie：
- 绝大多数站点的 HTML 是静态或仅含通用占位符，
Cookie只影响后续 API 请求，不影响 HTML 本身 - 加了
Vary: Cookie后，CDN 和浏览器会为每个不同Cookie值存一份 HTML 缓存副本，极易导致缓存雪崩、命中率归零 - 真要个性化 HTML，优先走前端 hydration + CSR，或用 ESI/Edge Side Includes，而不是让 HTML 缓存失效
验证 Vary 是否生效且合理
别只看响应头有没有 Vary 字段，重点看它是否导致缓存碎片化：
立即学习“前端免费学习笔记（深入）”；
- 打开 Chrome DevTools → Network → 刷新页面 → 找到
index.html请求 → 检查Response Headers中Vary值是否符合预期 - 在不同条件（如禁用 JavaScript、切换浏览器语言、用 curl 模拟不同
Accept-Encoding）下请求同一 URL，观察返回内容是否真有差异；若内容完全一样，Vary就是冗余甚至有害的 - 检查 CDN 后台缓存统计：如果某 HTML 资源的缓存 Key 数量随用户数线性增长，大概率是
Vary: Cookie或过度泛化的Vary导致的
真正难的是判断「这个 HTML 到底算不算动态」——很多团队误以为带登录态就该 Vary: Cookie，结果把首页缓存全搞垮。先确认后端是否真根据请求头生成不同 HTML 字节流，再决定要不要 Vary。没做这一步，直接加 Vary 就等于主动放弃缓存收益。
