HTML缓存收益低且风险高，真正提升二次访问速度的是index.html及时更新+静态资源长期安全缓存；配错策略会导致HTML与JS/CSS版本不一致，引发白屏、404等问题。
HTML 文件本身缓存收益低、风险高，真正能提升二次访问速度的，是让 index.html 及时更新，同时确保它引用的 main.js、app.css 等静态资源被长期、安全地缓存。配错一步，用户就可能加载旧 HTML 执行新 JS，或加载新 HTML 却执行旧 JS——白屏、404、按钮无响应全由此来。
为什么直接给 index.html 设 Cache-Control: public, max-age=3600 是高危操作
这个配置会让浏览器和所有中间代理（比如 CDN）把 index.html 缓存一小时。问题在于：index.html 通常不带内容哈希，而它引用的 main.8f3a2d.js、app.b9e1c7.css 却可能已更新。结果就是用户卡在旧 HTML 里，JS 已变但 HTML 还在拉旧路径，或者 HTML 已更新但 JS 被强缓存未更新，导致资源 404 或逻辑错乱。
- 纯静态站点（如文档页）可设
public, max-age=300（5 分钟），前提是所有 JS/CSS 路径含 content hash - 带登录态、实时数据的页面（仪表盘、订单列表），必须用
private, max-age=0, must-revalidate：允许浏览器缓存，但每次访问都向服务器验证是否变更 - 支付确认页、密码重置页等敏感页，直接上
no-store：禁止任何缓存，连内存都不许留副本 -
meta http-equiv="Cache-Control"在现代浏览器中基本无效，Chrome/Firefox/Edge 都会无视它
Nginx 中如何精准控制 index.html 的缓存头
服务端必须通过响应头设置，前端无法用 HTML 标签覆盖。Nginx 是最常见且可控的落地方案：
- 针对
/index.html单独配置，避免影响其他 HTML 文件：location = /index.html {<br> add_header Cache-Control "no-cache";<br>} - 若需兼容老旧代理或强调验证语义，改用更明确的写法：
location = /index.html {<br> add_header Cache-Control "max-age=0, must-revalidate";<br>} - 务必确认未被其他
add_header指令覆盖（Nginx 的add_header不继承，子块会覆盖父块） - CDN 层常会忽略或覆盖源站 header，必须在 CDN 控制台显式配置缓存规则，不能只信 Nginx 配置
静态资源必须配合内容哈希 + immutable 才算真正生效
光把 index.html 设成 no-cache 不够，如果它引用的 main.js 每次都被当作新文件下载，缓存就形同虚设。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- Webpack 需启用
contenthash：filename: "[name].[contenthash:8].js" - Vite 默认输出带 hash 的文件名，无需额外配置
- Nginx 静态资源缓存推荐配置：
location ~* \.(css|js|woff2|png|jpg|gif)$ {<br> expires 1y;<br> add_header Cache-Control "public, immutable";<br>} -
immutable很关键：它告诉浏览器“这个 URL 永远不会变内容”，后续访问可跳过If-None-Match验证请求，省掉一次往返 - 不用内容哈希却配
immutable，反而危险——改了文件内容但 URL 不变，用户永远拿不到新版本
协商缓存失效的典型原因与修复点
当 Cache-Control 过期后，浏览器会发起条件请求（If-None-Match 或 If-Modified-Since）验证缓存有效性。但如果服务器没返回有效 ETag 或 Last-Modified，或返回了但值恒定不变，浏览器就只能重新下载整个 HTML。
- Nginx 默认开启
etag on，但需确认未被etag off覆盖 - 对动态生成的 HTML（如 PHP/Node 渲染页），用内容哈希生成
ETag，而不是时间戳；否则内容未变但时间戳变，也会触发重载 - 若后端无法准确提供最后修改时间，宁可只用
ETag，也不要返回一个假的、总在变的Last-Modified头 - CDN 常会剥离或伪造
ETag，需检查其缓存行为是否保留源站 ETag
缓存不是单点设置，而是链路配合：构建工具输出带 hash 的资源 → Nginx 正确设置响应头 → CDN 不覆盖或误删关键 header → 浏览器按规范执行。任一环节断掉，前面所有配置都白搭。最容易被忽略的是 CDN 和源站策略不一致，以及误信 meta 标签能起作用。
