CDN选型应优先确保源站Cache-Control可自定义，否则CDN无法缓存；静态资源需显式设置public/max-age/immutable；URL哈希优于查询参数；需验证边缘节点实际覆盖；HTTP/2推送已废弃，改用preload或preconnect。
CDN选型时优先看 Cache-Control 响应头是否可自定义
很多团队一上来就堆高并发 CDN，结果发现 CSS 文件始终不缓存——根本原因是源站返回的 Cache-Control: no-cache 或 max-age=0 覆盖了 CDN 配置。CDN 不会强行覆盖源站明确禁止缓存的响应。
- 检查真实响应头：
curl -I https://your.com/style.css，重点看Cache-Control和ETag - 静态资源服务器（如 Nginx）必须显式设置：
add_header Cache-Control "public, max-age=31536000, immutable"; - 若用 GitHub Pages、Vercel 等托管服务，需确认其默认策略；Vercel 的
vercel.json中需配headers规则，不能只靠文件后缀 -
immutable关键字能避免浏览器在max-age内发条件请求，但 Safari 11.1+ 才支持，老版本 iOS 需降级为max-age=31536000
URL 中嵌入哈希值比依赖 version=1.2.3 查询参数更可靠
用 ?v=1.2.3 控制缓存更新看似简单，实际常失效：CDN 可能忽略查询参数缓存（尤其开启“忽略 URL 参数”优化时），或代理层主动剥离参数。
- 推荐构建后生成带内容哈希的文件名，例如
main.a8f3b2d.css，再通过 HTML 中引用该路径 - Webpack 用户用
MiniCssExtractPlugin.filename配[name].[contenthash:8].css - Vite 默认启用
build.rollupOptions.output.entryFileNames中的[hash]，但需确认cssCodeSplit: true开启以分离 CSS - 切勿在
link标签中写死哈希——必须由构建工具注入，否则 HTML 与 CSS 文件哈希不同步会导致 404
跨区域访问慢？先查 CDN 的 edge location 节点是否真正命中
全球 CDN 不等于全球低延迟。用户看到“已接入 Cloudflare”，不代表请求真进了离他最近的边缘节点——可能因 DNS 解析、Anycast 冲突或 TLS 握手失败而回源。
- 用
dig +short yourdomain.com看解析到的 IP，再查该 IP 归属（如ipinfo.io/104.16.123.45），确认是否为预期区域节点 - 打开浏览器 DevTools → Network → 找 CSS 请求 → 查看
Server响应头（如cloudflare、AmazonCloudFront）和X-Cache（如HIT from cloudfront-yyz） - 某些 CDN（如阿里云全站加速）需手动开启“智能路由”和“HTTP/2 回源”，否则海外回源走公网，延迟飙升
- 若用户集中在东南亚但 CDN 节点只部署在新加坡，考虑补充 Jakarta 或 Seoul 节点，而非单纯提升带宽
HTTP/2 推送已废弃，别再配 Link: 头推 CSS
Chrome 96+、Firefox 93+ 已完全移除 HTTP/2 Server Push 支持。继续配置不仅无效，还可能干扰资源加载优先级，导致关键 CSS 加载变慢。
立即学习“前端免费学习笔记（深入）”；
- 检查 Nginx/Apache 配置中是否残留
http2_push或Header set Link相关指令，全部删掉 - 替代方案只有两个：
preload（HTML 中<link rel="preload" href="style.css" as="style">）或preconnect（对 CDN 域名） -
preload要慎用：仅对首屏强依赖的 CSS 生效；若 preload 非关键 CSS，会抢占带宽，反而拖慢 JS 执行 - 现代 CDN（如 Cloudflare）支持 “Early Hints”，但需服务端配合发送
103 Early Hints，且浏览器支持度有限（Chrome 101+），不如直接优化 HTML 结构
