Cache-Control响应头不参与DOM构建，仅由网络层读取并控制缓存行为，与document对象无关；DOM解析器只处理HTML字节流中的标签和内容，完全忽略HTTP头。
Cache-Control 响应头不参与 DOM 构建
浏览器解析 HTML 时，Cache-Control 等响应头完全不进入 DOM 树——它只被网络层读取、决策缓存行为，和 document 对象毫无关系。DOM 解析器只处理字节流里的标签、属性、文本，对 HTTP 头视而不见。
常见错误现象：document.querySelector('meta[http-equiv="Cache-Control"]') 能取到节点，但这个 <meta> 标签对真实缓存毫无影响；开发者误以为“写了 meta 就生效”，结果线上 HTML 更新后用户仍看到旧版本。
-
Cache-Control必须由服务器在响应头中返回，不能靠前端代码注入或修改 -
<meta http-equiv="Cache-Control">在 Chrome/Firefox/Edge 中被完全忽略，仅极老 IE 有残缺支持 - 即使你用 JS 动态插入带
http-equiv的<meta>，也不会触发任何缓存策略变更
DOM 结构顺序直接影响首屏资源加载时机
虽然缓存头不进 DOM，但 DOM 的书写顺序直接决定预加载扫描器（Preload Scanner）能否提前发现关键资源。比如 <link rel="stylesheet"> 放在 <body> 底部，CSS 就无法被提前抓取，导致 FOUC 或重绘抖动。
使用场景：首屏按钮、标题、核心文案对应的元素，应尽量靠近 <body> 开头，避免被导航栏、广告位、埋点脚本层层包裹。
立即学习“前端免费学习笔记（深入）”；
-
<main>、<article>这类语义化容器不是“性能优化语法糖”，而是让预加载扫描器更快定位内容区块的信号 -
<script>标签若没加defer或async，会阻塞 DOM 构建，哪怕它只有一行console.log() -
display: none的元素仍参与 DOM 解析和内存占用，列表页中大量隐藏项会拖慢解析速度
HTML 缓存策略错配会让 DOM 变成“过期快照”
当服务端返回了 Cache-Control: public, max-age=31536000 给 /index.html，浏览器就会把整个 DOM 结构连同其中所有内联脚本、data- 属性、甚至 innerHTML 内容一起缓存下来。下次访问时，哪怕服务端已更新，用户看到的仍是旧 DOM 树。
典型坑：表单提交地址写死在 HTML 里，缓存后用户点击按钮却发往旧 API；路由配置硬编码在 <script> 中，缓存导致新页面 404。
-
/index.html应始终返回Cache-Control: no-cache, must-revalidate或max-age=0 - CDN 对 HTML 的缓存必须关闭或设为 0 秒，否则会覆盖源站响应头（Cloudflare 的 “Cache Everything” 规则尤其危险）
- 带哈希的静态资源（如
app.8f3e2d.js）可放心强缓存，但 HTML 本身永远不该被强缓存
验证缓存是否生效，别看 DOM 节点有没有
判断缓存是否起作用，唯一可靠方式是查 Network 面板里 HTML 请求的 Response Headers，而不是检查 DOM 是否包含某个新 class 或文本。
容易踩的坑：刷新页面后看到新内容，就以为缓存失效了——其实可能是内存缓存（200 from memory cache）或协商缓存（304 Not Modified）在起作用；真正要确认的是服务器是否被绕过。
- 打开 DevTools → Network → 刷新 → 找到
index.html请求 → 查Response Headers中的Cache-Control值 - 看 Status 列：如果是
200 OK（非from disk cache），说明没走强缓存；如果是304，说明协商缓存生效 - 注意 CDN 的
x-cache或x-cdn-cache响应头，它可能显示 HIT 却掩盖了源站实际返回的no-cache
location = /index.html 块里漏写的 add_header，它会让整套缓存策略形同虚设。 
