内容页面不宜用强HTML缓存；应设no-cache或max-age=0,must-revalidate并配ETag/Last-Modified，确保动态内容及时更新；真正提速靠带哈希的静态资源长效缓存。
直接给 HTML 文件配强缓存（比如 Cache-Control: public, max-age=3600）对内容页面通常有害无益——它会让用户卡在旧版 HTML 里，哪怕你刚修复了一个按钮跳转 bug 或更新了文章发布时间。
真正能提升内容页面访问速度的，不是缓存 HTML 本身，而是让 HTML 快速、可靠地加载，并确保它引用的资源（CSS/JS/图片）不重复下载。
为什么内容页面不能用 long-term HTML 缓存
内容页面（如博客文章、产品详情页）看似静态，实则常含动态片段：评论数、阅读量、分享按钮状态、CSRF token、时间戳、个性化推荐位。这些字段一旦过期或错乱，轻则显示错误数据，重则导致表单提交失败或权限越界。
-
max-age=3600强缓存会跳过服务器验证，浏览器根本不会发请求，ETag 和Last-Modified全部失效 - 哪怕只改一个字（比如把“已售罄”改成“补货中”），用户刷新后仍看到旧 HTML，直到缓存自然过期
- CDN 节点若缓存了该 HTML，还可能把带用户信息的响应返回给其他访客（
private又被 CDN 忽略）
内容页面 HTML 应该设什么 Cache-Control
核心原则：宁可多一次协商请求，也不能让用户看到错的内容。优先用 no-cache 或 max-age=0, must-revalidate，并确保服务端正确支持 ETag 或 Last-Modified。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
-
no-cache：允许缓存，但每次必须向服务端验证；适合大多数 CMS 输出的页面（如 WordPress、Hugo 静态生成 + 动态评论） -
max-age=0, must-revalidate：语义更明确，兼容性略好，强制走协商流程 - 绝对不要用
private：CDN 不认这个指令，边缘节点可能直接忽略，失去加速意义 - 敏感操作页（如支付确认、账号注销）必须用
no-store，彻底禁用任何中间环节缓存
真正提速的关键在静态资源缓存策略
内容页面的体积大头不在 HTML，而在它引用的 CSS、JS、字体、首屏图片。这些资源变动少、可预测，才适合激进缓存。
- 构建时必须启用内容哈希，例如
article.8f3a2d.css、vendor.b1c9e4.js；文件内容一变，URL 就变，浏览器自动弃旧取新 - Nginx 配置示例：
location ~* \.(css|js|woff2|png|jpg|gif)$ { expires 1y; add_header Cache-Control "public, immutable"; }immutable告诉浏览器“这个 URL 永远不变”，后续访问跳过If-None-Match验证，省掉一次 RTT - HTML 中所有资源链接必须带哈希——如果用了
main.css这种无哈希路径，再配immutable反而危险
meta http-equiv="Cache-Control" 在内容页完全不可信
你在 <head> 里写的 <meta http-equiv="Cache-Control" content="max-age=3600">，Chrome、Firefox、Edge 全部忽略。它只在极少数老旧 WebView 或直接双击打开本地 HTML 文件时起作用，对线上部署的内容页面零影响。
- 真实生效的唯一方式是服务端响应头：Nginx 的
add_header、Express 的res.set('Cache-Control', ...)、或 Vercel 的vercel.json中配置headers - 检查是否生效：DevTools → Network → 点开 HTML 请求 → 查看 Response Headers 里是否有
Cache-Control字段 - 误用
meta会导致你以为缓存开了，实际每次都在重新下载 HTML，问题更难定位
最常被忽略的一点：HTML 缓存策略必须和服务端渲染逻辑、CDN 缓存键、构建产物哈希三者对齐。缺一环，就可能出现“用户看到的是新 HTML + 旧 JS”这种版本错配，功能直接断裂。
