正确声明 @font-face 需同时满足五点：格式组合（woff2+woff+ttf）、路径相对CSS文件、font-family名称严格一致、font-weight/style与字体文件匹配、必加 font-display: swap。
如何用 @font-face 正确声明自定义字体
直接在 CSS 中用 @font-face 声明字体，是跨浏览器支持自定义字体最可靠的方式。关键不是“写了就行”，而是字体格式、路径、font-weight 和 font-style 必须和实际使用时严格匹配，否则浏览器会忽略或回退到系统字体。
常见错误：只引入 .ttf，结果 Safari 14+ 或旧版 Edge 不识别；或者 font-weight: 600 声明了，但字体文件本身不包含半粗体字重，导致渲染为普通加粗（伪粗体），失真严重。
- 优先提供
.woff2（现代浏览器） +.woff（兼容老 Chrome/Firefox） +.ttf（Safari 旧版、Android Webview）组合 -
src中多个url()用逗号分隔，浏览器按顺序尝试，遇到第一个能加载的就停 -
font-display: swap必须加上，避免文字长时间空白（FOIT）；不用block或默认值 - 字体名用英文引号包裹，如
font-family: 'MyCustomFont'，且声明和使用时名称必须完全一致（区分大小写）
字体文件路径怎么写才不会 404
路径错误是 @font-face 失效最常见原因。CSS 文件里的 url() 是相对于该 CSS 文件的位置解析的，不是相对于 HTML 页面。
比如 CSS 在 /assets/css/style.css，字体在 /assets/fonts/iconfont.woff2，那 url('../fonts/iconfont.woff2') 才对；写成 url('/fonts/iconfont.woff2') 就依赖服务器根目录配置，容易出错。
立即学习“前端免费学习笔记（深入）”；
- 开发阶段建议全用相对路径，避免部署到子路径（如
/myapp/）时失效 - Webpack/Vite 等构建工具中，如果字体放在
src/assets/fonts/，需确认 loader 是否处理了.woff2后缀（例如asset类型需显式 include） - 检查浏览器 DevTools 的 Network 面板，过滤
font，看请求是否返回 200，响应头是否有Content-Type: font/woff2
为什么设置了 @font-face 但文字还是没变样
声明了 ≠ 生效了。字体加载后还需被 CSS 规则真正“选中”，且没有被更高优先级规则覆盖或触发回退逻辑。
- 确保使用处的
font-family值和@font-face中的font-family完全一致（包括引号、空格、连字符） - 检查是否被浏览器默认样式（如
button的 UA 样式）或框架重置（如 Normalize.css）覆盖，可用 DevTools 的 Computed 面板看最终生效的font-family -
font-weight和font-style不匹配时，浏览器可能跳过该字体——例如你只引入了常规体（normal/400），但写了font-weight: 700，就会回退 - 部分字体（尤其是图标字体）需要设置
font-feature-settings: 'liga'或禁用连字，否则某些字符显示异常
字体加载性能和隐私要注意什么
@font-face 加载是阻塞渲染的（除非用了 font-display: swap），且字体文件体积大时会拖慢 LCP。另外，CDN 字体可能带来跨域和追踪风险。
- 用
font-display: swap是底线，别用optional（可能导致字体永不加载） - 用
unicode-range拆分字体（如中文字体只加载常用字），但注意 Safari 对该属性支持不稳定，慎用于核心文本 - 避免从第三方 CDN（如 Google Fonts）直接加载非必要字体，尤其涉及 GDPR 或国内合规场景；优先本地托管
- WebFont 加载完成前，可监听
document.fonts.load()做降级提示，但注意 IE 不支持该 API
字体不是“放进去就能用”的资源，它牵扯路径、格式、权重、加载策略、调试手段五个层面。漏掉任意一环，都可能让设计稿和页面呈现差一个世界。
