@font-face 中 url() 路径必须相对于 CSS 文件位置而非 HTML；需通过 Network 面板查 404 请求定位错误路径，验证字体可直接访问，确保 font-family 名称（含引号、空格、大小写）定义与引用完全一致，并注意构建工具对路径的自动处理。
检查 @font-face 中的 url() 路径是否为相对路径且基于 CSS 文件位置
浏览器解析 @font-face 的 url() 时，路径是相对于 CSS 文件所在目录计算的，不是 HTML 页面或服务器根目录。常见错误是把字体路径写成相对于 HTML 的路径（比如 ./fonts/icon.woff2），结果 CSS 在 /css/style.css 里，实际却去请求 /css/fonts/icon.woff2。
- 打开开发者工具 → Network 标签页 → 刷新页面 → 筛选
woff、woff2、ttf等字体类型，看哪些请求返回 404 - 点击 404 请求，看 “Initiator” 列指向哪行 CSS；再点开该 CSS 文件，定位到对应
@font-face块里的url() - 确认当前 CSS 文件的 URL（比如
https://example.com/assets/css/main.css），那么url(../fonts/regular.woff2)就会尝试加载https://example.com/assets/fonts/regular.woff2
验证字体文件是否真能被直接访问（绕过 CSS）
如果路径看起来没错但字体仍不生效，很可能是文件权限、服务器配置或拼写问题。最直接的办法是把 url() 里的路径拼成完整 URL，在新标签页中手动打开。
- 例如 CSS 中写的是
url(../fonts/Inter-VariableFont.ttf)，而 CSS 地址是/static/css/app.css，那就手动访问https://yoursite.com/static/fonts/Inter-VariableFont.ttf - 若返回 404 或下载失败，说明文件不存在、路径错、大小写不一致（Linux 服务器区分大小写！），或服务器未配置字体 MIME 类型（如 Nginx 需添加
types { font/woff2 woff2; }） - 若能正常下载，说明路径正确，问题可能出在字体格式兼容性或
font-family引用不匹配
对比 font-family 名称是否完全一致（含引号与空格）
定义和使用必须严格一致。很多问题不是路径错，而是定义时用了引号，调用时没加，或中间多了一个空格。
@font-face {
font-family: "My Custom Font";
src: url("../fonts/myfont.woff2") format("woff2");
}
- 上面定义了带双引号的
"My Custom Font"，那么在font-family中也必须写成font-family: "My Custom Font"; - 不能写成
font-family: My Custom Font;（会被解析为三个独立关键字）或font-family: 'My Custom Font';（单引号虽语法允许，但部分旧环境有差异） - 推荐统一用双引号，并在所有地方保持完全相同（包括连字符、空格、大小写）
注意构建工具（Vite / Webpack / Next.js）对 url() 的自动重写行为
现代构建工具常会把字体文件复制进输出目录并重命名（如加 hash），同时自动改写 CSS 中的 url()。如果你手写路径又没走构建流程，或路径写死在未被处理的 CSS 文件中（比如 index.html 里内联的 style），就会失效。
立即学习“前端免费学习笔记（深入）”；
- Vite 项目中，确保字体放在
public/下并用绝对路径（url(/fonts/xxx.woff2)），或放在src/assets/并用url('@/assets/fonts/xxx.woff2')（需支持别名解析） - Webpack 中若用
file-loader或asset-module，检查rules是否覆盖了字体后缀，否则url()不会被重写，导致路径残留源码路径 - Next.js 的
app/目录下，字体建议放public/fonts/，用绝对路径引用；CSS 模块中若用url(./fonts/...)，需确认是否启用css-loader的url处理
