字体回退是font-family列表顺序、操作系统字体注册状态与浏览器解析策略共同决定的单向链式匹配，非自动兜底；必须以sans-serif或serif收尾，正确设置font-display:swap，并确保@font-face中src顺序合理、font-weight/font-style与字体文件元数据严格一致。
字体回退不是“浏览器自动兜底”，而是你写的 font-family 列表顺序 + 操作系统字体注册状态 + 浏览器解析策略共同决定的。写错顺序、漏掉通用族、local() 放太前，都会让回退失效。
font-family 列表顺序决定 fallback 路径
浏览器从左到右逐个尝试，找到第一个本机存在的字体就停，后面全忽略。这不是“备选池”，是“单向链”。
- Windows 用户实际看到的是
"Microsoft YaHei"或"SimSun"，不是“黑体”这种模糊名称——后者根本不会被识别为有效字体名 - macOS 用户依赖
"PingFang SC"、"Hiragino Sans GB"，而local("Helvetica")在 Windows 下直接跳过，不报错也不兜底 - 必须以
sans-serif或serif收尾；否则 iOS Safari 在font-style: italic场景下可能 fallback 到Times，导致中英文混排错乱 - 字体名含空格或特殊字符（如
"Noto Sans SC"）必须用英文双引号包裹，写成Noto Sans SC会被解析为三个独立字体：Noto、Sans、SC
@font-face 中 src 顺序决定是否真能 fallback
很多人以为把一堆格式堆进 src 就万事大吉，其实浏览器只加载第一个能成功解析的来源。顺序错了，自定义字体永远不生效。
- 要把网络字体放前面，
local()放后面：src: url('fonts/myfont.woff2') format('woff2'), local("PingFang SC") - 如果第一个是
local("PingFang SC")，那在 macOS 上它就会直接用系统字体，后面所有url()都不会触发——哪怕你本意是想加载自定义字体 -
font-weight和font-style必须和字体文件元数据严格一致；woff2 文件本身是 normal + normal，但 CSS 写了font-weight: 700，浏览器就判定“不匹配”，跳过不用 - IE9 及更早版本只认
.eot，且必须放在src第一位并单独声明一次：src: url(font.eot)，否则整个@font-face被忽略
font-display: swap 是 fallback 生效的前提
不加 font-display: swap，浏览器默认行为是 FOIT（Flash of Invisible Text）：等字体加载完才渲染文字，期间页面一片空白——这时候根本没机会“回退”，因为文本压根没显示。
-
swap让浏览器先用 fallback 字体渲染，等自定义字体加载完成再切换，这才是真正的“回退可见” - 没有
swap，即使你写了完整的 fallback 链，用户也看不到任何文字，直到字体加载完毕（或超时） - 部分安卓 WebView 对
font-display支持不完整，需配合font-loadingAPI 做降级检测
中英文混排时 fallback 容易崩的真实原因
不是字体没写全，而是浏览器对不同 Unicode 区块的字形查找逻辑不同。一个汉字找不到，它不会退到下一个 font-family，而是退到当前字体里“最接近的 fallback 字体”（比如系统默认的 STHeiti），这和你写的列表无关。
- 中文字符优先匹配中文字体，英文字符优先匹配英文字体；但若中文字体里缺某个拉丁字符（如数学符号、emoji），浏览器会按 Unicode 区块切分后单独 fallback
- 顺序错了，中文可能直接 fallback 到英文默认字体（比如
Times New Roman），造成字重、字宽突变 - 某些 Android 系统（尤其旧版）会忽略你写的非系统预装字体名，强行用
Droid Sans或Roboto替代，此时local()几乎无效
真正控制 fallback 的，从来不是“我写了哪些字体”，而是“我写的顺序是否匹配目标环境的字体注册路径”，以及“是否给了浏览器足够早、足够明确的渲染指令”。很多问题表面是字体没显示，实际是 font-display 缺失、local() 位置错误、或结尾没加 sans-serif 导致 iOS/Safari 行为不可控。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
