src属性格式顺序重要是因为浏览器从左到右尝试加载，成功即停止；应按woff2→woff→truetype→svg顺序排列以兼顾性能与兼容性。
font-face 声明里 src 属性的格式顺序为什么重要
浏览器对 @font-face 的 src 声明是按从左到右顺序尝试加载的，一旦某个格式成功解析就停止后续尝试。如果把兼容性差的格式（比如 woff2）放在最前面，而旧版 Safari 或 IE 不支持它，又没 fallback，字体就会直接失效成系统默认字体。
实操建议：
- 始终把
woff2放最前（现代浏览器压缩率高、加载快） - 紧跟
woff（IE9+、iOS 5.1+、Android 4.0+ 都支持） - 再放
truetype（.ttf，兼容老 Android 和部分桌面端，但无压缩） - 最后可选
svg（仅 iOS
示例写法：
@font-face {
font-family: 'MyFont';
src: url('myfont.woff2') format('woff2'),
url('myfont.woff') format('woff'),
url('myfont.ttf') format('truetype');
}
font-display 属性不设或设错会导致文字闪动或长时间空白
没加 font-display 时，Chrome/Firefox 会阻塞文本渲染最多 3 秒（FOIT），等字体加载完才显示；设成 swap 后，立即用备用字体显示，等自定义字体就绪再替换（FOUT）。但若设成 block 且网络慢，用户可能看到长达 3 秒白屏。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 多数场景用
font-display: swap—— 平衡可读性与品牌一致性 - 对 logo 或标题字体要求极高时，可考虑
font-display: optional（字体加载超时即放弃） - 避免用
block，除非你明确接受 FOIT 行为
本地开发时 font-face 路径 404 的常见原因
不是字体文件不存在，而是路径解析和服务器策略导致：Webpack/Vite 默认不处理 url() 中相对路径；开发服务器（如 vite dev server）默认禁止跨域字体请求；CSS 文件所在目录层级影响相对路径计算。
实操建议：
- 字体文件统一放
src/assets/fonts/，CSS 中用绝对路径url('/src/assets/fonts/myfont.woff2') - Vite 项目需在
vite.config.ts中配置server.headers: { 'Access-Control-Allow-Origin': '*' }（仅开发） - Webpack 项目确保
file-loader或asset module已启用，并匹配.woff2?$/等扩展名 - 检查浏览器 Network 面板里字体请求是否返回 200，注意响应头是否有
Content-Type: font/woff2
font-weight 和 font-style 必须和字体文件内嵌元数据严格匹配
很多免费字体只包含 Regular 字重（400）和 normal 样式，但 CSS 里写了 font-weight: 600 或 font-style: italic，浏览器找不到对应字体文件，就会回退到系统字体——看起来像“字体没生效”。
实操建议：
- 用
font-display: swap+ 浏览器开发者工具的 Fonts 面板，确认实际加载的是哪个字重/样式 - 用
otfinfo -s font.ttf（macOS/Linux）或 FontForge 查看字体文件真实支持的weight和style - 每个字重/样式组合都单独声明一个
@font-face，不要指望浏览器自动模拟斜体或加粗 - 例如：要同时支持 Regular 和 Bold，就得写两个
@font-face，分别指定font-weight: 400和font-weight: 700
字体加载这件事，表面是路径和语法问题，实际卡点常在元数据匹配、服务响应头、以及浏览器对 font-display 的执行差异上。尤其当设计稿用了多个字重+斜体时，漏掉任意一个 @font-face 声明，就等于那一块文字彻底脱离控制。
