本地字体加载失败的核心原因是file://协议被浏览器安全策略禁止、服务器未配置正确MIME类型或CSS路径解析错误。Chrome/Edge自2019年起禁用file://下字体加载；Nginx等需配置add_type font/woff2 .woff2；相对路径以CSS文件位置为基准，非HTML文件。
本地字体在部分电脑上无法加载，核心原因不是字体文件本身有问题，而是路径解析、协议限制或 MIME 类型缺失导致浏览器根本没发出有效请求，或者发出了但被拒绝。
为什么 file:// 协议下字体必失败
双击 HTML 文件用百度浏览器、Edge 或 Chrome 直接打开（地址栏显示 file:///D:/xxx/index.html），所有 @font-face 中的 url() 都会静默失效——这是浏览器安全策略，不是 bug。Chrome 和 Edge 从 2019 年起就默认禁用 file:// 下的字体加载；百度浏览器更严格，连 .ttf 都拦。
- 现象：Network 面板里字体请求状态码为
(failed)或0，无响应头 - 验证方式：把同一页面用
http-server、live-server或 XAMPP 启起来，地址变成http://localhost:8080/，问题立刻消失 - 别试图改 Chrome 启动参数绕过——生产环境不可行，且新版已废弃
--allow-file-access-from-files
路径写错：相对路径基准永远是 CSS 文件位置
很多人以为 url('./fonts/my.woff2') 是相对于 HTML，其实它从 style.css 所在目录算起。CSS 在 /assets/css/main.css，字体在 /assets/fonts/my.woff2，就必须写 url('../fonts/my.woff2')。
- 错误示例：
url('/fonts/my.woff2')→ 浏览器请求http://localhost/fonts/my.woff2（404） - 正确做法：打开 Network 面板 → 找到字体请求 → 点击 Headers → 复制
Request URL粘贴到新标签页，看是否真能下载 - 构建工具（Vite/Webpack）不会自动重写 CSS 里的
url()，除非你显式配置了asset规则并启用url()解析
服务器没配 MIME 类型，字体被当成普通文件拒收
即使路径对、文件存在，Nginx、Apache、IIS 或某些静态服务（如早期 Python SimpleHTTPServer）若未声明字体后缀的 Content-Type，Chrome/Firefox 就会直接丢弃响应。
立即学习“前端免费学习笔记（深入）”；
- 必须返回的类型：
.woff2→font/woff2，.woff→font/woff，.ttf→font/ttf - Nginx 示例配置：
add_type font/woff2 .woff2;加在http或server块里 - IIS 用户：进「MIME 类型」界面手动添加，别只加
.woff2，顺手补上.woff、.ttf、.eot - 用
curl -I http://localhost/font.woff2检查响应头里是否有Content-Type: font/woff2
字体格式或声明不全，老系统/旧浏览器直接跳过
仅提供 .woff2 在 Windows 7 + IE11 或 macOS 10.12 + Safari 10 上会彻底失效。而且 format() 缺失或写错，也会让部分浏览器识别失败。
- 必须写
format('woff2')，不能只写url('my.woff2') - 兼容链建议按顺序：
woff2→woff→truetype（即.ttf），IE 可选eot - 别用
local()：比如src: local('PingFang SC'), url('./fonts/my.woff2')，部分 Windows 机器会因系统字体名不匹配导致整条src被忽略 - 加
font-display: swap，避免白屏；不加的话，Chrome 默认阻塞 3 秒再 fallback，体验极差
最容易被忽略的是：你以为路径对了，其实 Network 里那个字体请求压根没发出去——先确认协议是不是 file://，再查 MIME，最后才是路径和格式。三者缺一，字体就只是 CSS 里一段安静的代码。
