CDN缓存决策只依赖HTTP响应头，不解析HTML内容；元标签（如<meta http-equiv="Cache-Control">）对CDN完全无效，HTML结构本身也不影响CDN缓存。
HTML文档结构本身不影响CDN缓存，元标签（如<meta http-equiv="Cache-Control">）对CDN完全无效——CDN只看HTTP响应头，不解析HTML内容。
CDN缓存决策只依赖HTTP响应头，不读取HTML里的<meta>
CDN边缘节点处理请求时，不会执行HTML解析、不加载DOM、不扫描<meta>标签。它只检查源站返回的HTTP响应头（尤其是Cache-Control、Expires、ETag），再结合URL路径和查询参数决定是否缓存、缓存多久。
-
<meta http-equiv="Cache-Control" content="no-cache">在Chrome/Firefox/Edge中被彻底忽略，CDN更不可能识别它 - 哪怕你在
<head>里写了10个<meta>缓存指令，CDN看到的仍是源站实际返回的Cache-Control: public, max-age=3600，就会照此缓存 - 常见翻车点：本地开发用Express设了
res.set("Cache-Control", "no-cache")，但上线后Nginx漏配add_header，或被CDN控制台“默认缓存10分钟”策略覆盖——此时<meta>写得再全也没用
HTML结构影响的是浏览器渲染时机，不是CDN缓存行为
CDN对HTML文件的处理是字节流原样存储与转发，不管你是用<div class="wrapper"><div class="container"><main>.../div></div>还是语义化扁平结构，它都当成一串二进制数据缓存。真正受影响的是浏览器：
- 嵌套过深的
<div>会拖慢DOM构建，首屏内容延迟上屏，间接放大CDN缓存旧HTML的危害（用户卡在旧结构里等JS执行） -
<script>放在<head>顶部会阻塞HTML解析，而CDN缓存的正是这段“卡住”的HTML，导致用户每次拿到的都是未完成渲染的骨架 - 服务端渲染（SSR）输出的碎片若含重复
id="modal"，CDN缓存后直接分发给所有用户——这不是CDN的问题，而是HTML结构没做上下文隔离
CDN缓存键由URL决定，HTML里带查询参数会分裂缓存
CDN默认以完整URL（含查询参数）作为缓存键。这意味着/index.html?utm_source=email和/index.html?utm_source=ad会被视为两个资源，各自独立缓存、各自回源。
立即学习“前端免费学习笔记（深入）”；
- 如果源站对所有
?*都返回相同HTML，却没配置CDN“忽略指定查询参数”，就会造成缓存冗余、命中率下降、回源压力上升 - 某些CDN（如Cloudflare）支持在规则中声明
ignore query string parameters: utm_*, ref；国内厂商需确认是否开启该功能，否则只能靠服务端重写URL或前端用history.replaceState()清理参数 -
<link rel="canonical" href="/index.html">对CDN无影响——它只被搜索引擎用于去重，CDN不读取该标签
真正需要联动配置的三个地方
HTML结构、元标签、CDN设置三者之间没有直接通路。要让缓存策略生效，必须同步确保：
- 源站HTTP响应头正确：Nginx用
add_header Cache-Control "no-cache"，Vercel用_headers文件，Node.js用res.set() - CDN后台设置为“遵循源站响应头”：关闭“强制缓存X秒”、“默认缓存策略”等覆盖选项，否则CDN会无视你的
no-cache - 构建产物与HTML缓存策略匹配：JS/CSS用哈希命名并配
public, immutable, max-age=31536000，而index.html必须短缓存——否则用户拿到的HTML仍引用旧哈希的JS，直接白屏
最容易被忽略的是CDN控制台里的“默认缓存规则”开关。它比任何代码里的<meta>或res.set()都霸道——一旦打开，所有未显式匹配的路径都会被它接管，index.html就可能默默被缓存60秒，连硬刷新都救不了。
