CDN字体被浏览器拦截的直接原因是字体文件跨域且响应头缺失Access-Control-Allow-Origin；需在CDN服务器针对.woff/.woff2等路径配置该响应头并刷新缓存，或换用已预配CORS的CDN（如jsdelivr）。
CDN字体文件被浏览器拦截的直接原因
因为浏览器对 @font-face 加载的字体（.woff、.woff2 等）实施了比图片或 JS 更严格的跨域策略。即使 CSS 文件本身加载成功，只要它内部通过 url() 引用的字体文件来自不同域名（比如 Bootstrap CSS 在 cdn.jsdelivr.net，而字体实际托管在 fonts.gstatic.com 或 CDN 的另一个子域），且响应头缺失 Access-Control-Allow-Origin，浏览器就会静默拒绝加载——控制台只报 Font from origin 'xxx' has been blocked...，不提示具体哪个请求失败。
为什么换 CDN 就能绕过问题？
不是所有 CDN 都默认为字体资源开启 CORS。部分 CDN（如早期百度 CDN apps.bdimg.com）未配置或错误配置字体路径的响应头；而另一些（如 cdn.bootcss.com、cdn.jsdelivr.net）已对常见字体路径（*.(woff|woff2|ttf)）统一设置了 Access-Control-Allow-Origin: * 或指定域名。
- 检查你当前使用的 CDN 是否明确声明支持 Bootstrap 字体的 CORS —— 官方文档或 GitHub README 常会注明
- 用浏览器开发者工具 → Network → 找到失败的
.woff2请求 → 查看 Response Headers 里是否有Access-Control-Allow-Origin - 如果 header 缺失，换 CDN 是最快见效的方案，例如改用
https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css
自己配置 CDN 时容易漏掉的关键点
即使你有权限配置 CDN，也常因以下细节失效：
-
add_header必须作用于字体文件路径匹配规则下（如 Nginx 中location ~ \.(woff2?|ttf|eot)$），而不是全局或仅 CSS 路径 - CDN 缓存会固化旧的响应头，修改后必须手动刷新对应路径的缓存，否则浏览器拿到的仍是无 CORS 头的旧响应
- 某些 CDN（如阿里云）限制只能填一个精确域名，不支持通配符
*或泛域名（如*.example.com），填错格式（比如带http://协议前缀）会导致配置不生效 - 如果源站是 OSS 或对象存储，需确认 OSS 本身的 CORS 规则是否与 CDN 层配置冲突——CDN 的设置通常会覆盖 OSS
本地开发时字体突然不显示的典型诱因
当你把 Bootstrap CSS 从本地文件改成 CDN 引入，但没同步调整字体引用路径，就容易触发跨域：
立即学习“前端免费学习笔记（深入）”；
- Bootstrap 官方 CSS 中的
@font-face默认指向相对路径（如url("../fonts/glyphicons-halflings-regular.woff2")），一旦 CSS 来自 CDN，这个相对路径就变成向 CDN 域名下找字体，而非你的本地服务器 - 解决办法不是硬改 CSS 内容，而是：要么换用已配好 CORS 的 CDN，要么下载完整 Bootstrap 包并把字体文件和 CSS 放在同一域名下，确保同源
- 注意：使用
integrity属性时，若手动替换 CSS 文件内容（比如删掉字体引用），会导致哈希校验失败，反而触发另一类报错
