CDN缓存HTML文件是字节流式原样存储与响应，不执行JS、不读取Cookie、不调用API；其缓存依赖Cache-Control头、URL路径为缓存键、失效靠TTL到期或主动刷新，边缘节点无默认JS执行环境，ESI仅限有限模板内联且需厂商支持。
HTML静态页面在CDN节点上不执行JavaScript、不读取Cookie、不调用后端API——它只是被原样缓存并响应，所谓“边缘计算”在此类纯静态场景中基本不参与运算。
CDN如何缓存和分发HTML文件
CDN对HTML的处理本质是“字节流缓存”，而非渲染或解析。只要HTTP响应头允许（如Cache-Control: public, max-age=3600），且请求路径命中缓存规则，CDN边缘节点就会把原始HTML内容存下来，后续相同URL请求直接返回该副本。
- 源站必须返回可缓存的响应：确保
Cache-Control未设为no-store或private，且无Set-Cookie头（否则多数CDN默认跳过缓存） - URL路径决定缓存键：带查询参数的URL（如
/index.html?utm_source=ad）通常被视为不同资源，除非CDN配置了忽略特定参数 - 缓存失效依赖TTL或主动刷新：CDN不会感知源站HTML文件是否被修改，必须靠
max-age到期、手动触发purge或使用版本化路径（如/index.v2.html）来更新
为什么不能在CDN节点上运行JS或服务端逻辑
标准CDN边缘节点不具备执行环境：没有V8引擎、不加载DOM、不维护会话上下文。所谓“边缘计算”能力（如Cloudflare Workers、阿里云EdgeRoutine）需要显式启用并单独部署代码，不是HTML缓存的默认行为。
- 浏览器中的
document.cookie、localStorage、fetch()等操作，全部发生在用户本地，与CDN节点无关 - 如果你看到页面“动态变化”，那一定是前端JS在客户端执行的结果，CDN只负责把那段JS代码（或初始HTML骨架）快速扔给浏览器
- 试图在HTML里写
<script>console.log(location.href)</script>并期望CDN替你执行——它不会，它只会原样转发
ESI或Edge Side Include如何介入HTML组装
ESI是一种由CDN支持的简单模板语言，允许在HTML中插入<esi:include src="/api/user" />这类指令，让边缘节点在响应前发起子请求并内联结果。但它不是通用JS执行环境，仅支持有限指令集，且需CDN厂商明确开启支持（如Akamai、Fastly默认支持，国内多数CDN需单独申请）。
立即学习“前端免费学习笔记（深入）”；
- ESI包含的内容必须是纯文本/HTML片段，不能携带JS执行逻辑；返回体也不能含
Set-Cookie，否则整个响应可能被拒绝缓存 - ESI请求走的是CDN节点到源站的内网链路，延迟远低于用户浏览器直连，但依然存在回源开销，不适合高频或大体积内容
- 现代替代方案更倾向CSR（客户端渲染）+ 静态骨架缓存，而非ESI——因为ESI调试困难、错误不透明、且缺乏浏览器级错误监控能力
真正容易被忽略的一点：HTML静态化 ≠ 页面无状态。即使所有内容都预生成，如果URL里带用户ID、A/B测试标识或UTM参数，CDN仍可能缓存多个变体，导致缓存爆炸或内容错乱。控制缓存键的粒度，比优化单个HTML体积更重要。
