@font-face字体不生效主因是url()路径错误，须相对于CSS文件而非HTML页面；常见错误包括路径缺失../、误用绝对路径、MIME类型未配置、font-family名称不匹配及跨域限制。
检查 @font-face 中的 url() 路径是否相对于 CSS 文件
字体不生效，八成是 url() 指向的文件压根没加载进来。浏览器解析 url() 时，路径是相对于当前 CSS 文件位置计算的，不是 HTML 页面或 JS 脚本所在位置。
常见错误包括：
- 把
bootstrap.css放在/css/目录，但字体实际在/assets/fonts/，却写成url("fonts/glyphicons.woff2")（少了个../） - 误用绝对路径
url("/fonts/...")，而部署后网站根目录下并没有/fonts/这个物理路径 - Webpack/Vite 构建时未启用
asset或url-loader，导致 CSS 中的url()没被重写，仍指向开发期路径
验证方法：打开 bootstrap.css，复制其中 url(...) 的完整值（比如 url("../fonts/glyphicons.woff2")），把它拼到当前页面 URL 后面，直接粘贴进浏览器地址栏——如果打不开或返回 404，路径就错了。
确认服务器返回了正确的 MIME 类型
IIS、Nginx 或某些静态托管平台默认不识别 .woff2、.woff 等扩展名，会直接返回 404，哪怕文件真实存在。
必须手动配置 MIME 类型：
-
.woff2→font/woff2（推荐用这个，不是application/font-woff2，后者已过时） -
.woff→font/woff -
.ttf→font/ttf -
.eot→application/vnd.ms-fontobject
在 IIS 中：打开「MIME 类型」→ 添加；在 Nginx 中：在 http 或 server 块里加 types { font/woff2 woff2; }。改完别忘了清浏览器缓存，Network 面板里看字体请求的响应头是否有 Content-Type: font/woff2。
验证 font-family 名称与调用是否完全一致
@font-face 里声明的 font-family 是自定义别名，后续所有 CSS 使用它都必须**逐字符匹配**，包括引号、大小写和连字符。
例如：
@font-face {
font-family: 'Glyphicons Halflings';
src: url('../fonts/glyphicons.woff2') format('woff2');
}
那么调用时必须写 font-family: 'Glyphicons Halflings';，不能写成 font-family: Glyphicons Halflings;（缺引号）、font-family: "glyphicons halflings";（大小写错）或 font-family: Glyphicons-Halflings;（用了短横线）。
Bootstrap 3 的图标类如 .glyphicon 就依赖这个精确匹配。如果改过字体名，又没同步更新所有引用处，图标就会退化成方框 □。
排除跨域与本地 file:// 协议限制
字体是少数几种浏览器严格限制跨域加载的资源类型之一。即使服务端加了 Access-Control-Allow-Origin: *，对 @font-face 也基本无效——这是浏览器硬性策略。
典型场景：
- HTML 用
file://协议双击打开，Chrome/Safari 会直接拦截字体请求（报net::ERR_FAILED），这不是 bug，是安全机制 - 字体放在 CDN（如
https://cdn.example.com/fonts/），页面在https://app.example.com，同样无法加载
解决办法只有一条：**必须通过 http(s) 协议访问页面**。开发时用 vite preview、npx http-server 或 VS Code Live Server 启一个本地服务，别双击 HTML。
最常被忽略的是：你以为路径和代码都对，其实 Network 面板里字体请求根本没发出去——可能被 CSP 的 font-src 规则拦了，或者被广告屏蔽插件静默阻止。先关插件、检查 CSP header，再排查其他环节。
