cdn.bootcdn.net对国内用户更快，因其DNS解析返回北京、上海等就近国内节点，实测TTFB为20–45ms；而jsDelivr部分场景分至香港或新加坡节点，TTFB波动达60–120ms。
国内用户直接用 cdn.bootcdn.net，国际用户优先选 cdn.jsdelivr.net——这不是主观推荐，而是实测首字节时间（TTFB）和节点调度策略决定的。
为什么 cdn.bootcdn.net 对国内用户更快
BootCDN 的 DNS 解析会主动返回离你最近的国内边缘节点（北京、上海、广州等），实测 TTFB 普遍压在 20–45ms；而 jsDelivr 虽然也覆盖国内，但其智能调度对中国电信/联通/移动的线路识别略保守，部分二三线城市用户可能被分到香港或新加坡节点，TTFB 波动常达 60–120ms。
- 确认是否真走国内节点：打开浏览器开发者工具 Network 面板，查看
bootstrap.min.css请求的Remote Address，若显示为114.114.*.*或223.5.5.5等国内 DNS 解析结果，基本可判定命中本地化调度 - 避免混用协议：如果页面是
https://，但引用了http://cdn.bootcss.com（已停服多年），浏览器会直接拦截资源，控制台报Mixed Content错误 - 别信“latest”路径：
https://cdn.bootcdn.net/ajax/libs/twitter-bootstrap/latest/css/bootstrap.min.css不稳定，可能指向 v4.x 或 v5.x 的非预期版本，必须写死如5.3.3
jsDelivr 为什么更适合海外或混合流量项目
jsDelivr 的底层是 Cloudflare + MaxCDN 双回源，对 GitHub 仓库变更响应极快（通常 1 小时内同步），且支持 @version 精确锁定，比如 bootstrap@5.3.3 和 bootstrap@5.3.3/dist/css/bootstrap.min.css 路径完全可预测——这点比 BootCDN 更适合 CI/CD 自动化校验。
- 它能自动协商 Brotli 压缩，相同 CSS 文件体积比 gzip 小 15% 左右，对高延迟链路更友好
- 若项目含大量 npm 包（如
chart.js、moment），统一用 jsDelivr 可复用同一域名的 TCP 连接池，减少preconnect开销 - 注意：不要把
preconnect写成https://cdn.jsdelivr.net/npm，正确写法是https://cdn.jsdelivr.net（少/npm），否则预连接失效
怎么验证 CDN 到底快不快
不能只看“加载完成时间”，要盯住三个关键点：DNS 查询耗时、TCP 连接建立时间、首字节时间（TTFB）。用 curl -w "@curl-format.txt" -o /dev/null -s https://cdn.bootcdn.net/ajax/libs/twitter-bootstrap/5.3.3/css/bootstrap.min.css 配合格式文件，提取真实指标。
-
Content-Type必须是text/css，不是text/html——后者说明 CDN 返回了 404 页面，路径写错了 - 检查响应头是否有
CF-Cache-Status: HIT（Cloudflare）或X-Cache: HIT（BootCDN），没命中缓存的“快”是假快 - 用不同运营商网络（移动/联通/电信）各测一次，单次测试没意义；国内用户若在联通网络下
cdn.jsdelivr.net比cdn.bootcdn.net快，大概率是临时 DNS 劫持或节点异常，不是常态
真正影响“快”的从来不是 CDN 域名本身，而是你写的路径对不对、协议配不配、有没有让浏览器提前建连。一个错写的 dist/css/ 少了 dist/，404 后重试就拖慢整页；一个漏掉的 crossorigin="anonymous"，可能导致字体或 JS 模块加载失败——这些细节比选哪家 CDN 更容易卡住上线节奏。
