必须写英文通用字体 fallback，因为中文字体缺失时会降级到等宽默认字体，破坏阅读体验；应按“具体字体→同类字体族→通用字体族”逐级回退，且 sans-serif 不可省略。
font-family 里为什么必须写英文通用字体 fallback？
中文网页的 font-family 如果只写 "PingFang SC" 或 "Microsoft YaHei"，在非对应系统（比如 macOS 用户访问用了“微软雅黑”的 Windows 专属页面）上会直接降级到浏览器默认等宽字体，阅读体验断崖式下跌。
正确做法是按「具体字体 → 同类字体族 → 通用字体族」逐级 fallback：
-
font-family: "Inter", -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;（英文优先场景） -
font-family: "HarmonyOS Sans", "OPPO Sans", "MiSans", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif;（中英混排主流方案）
注意：中文字体名带空格必须用引号；sans-serif 是最后兜底，不能省略，否则某些旧浏览器可能渲染异常。
line-height 设多少才不挤也不飘？
line-height 不是越大越好。设成 2 看似宽松，实际段落会显得松散无力；设成 1.2 又容易让中文行间粘连，尤其在小字号（如 14px）下字形上下紧贴，识别困难。
立即学习“前端免费学习笔记（深入）”；
推荐按字号分层设置：
-
font-size: 12–14px→line-height: 1.5（保证基础可读性） -
font-size: 16–18px（正文常用）→line-height: 1.6～1.7（视觉呼吸感刚好） -
font-size: 20px+（标题）→line-height: 1.3～1.4（避免过大留白割裂层级）
别用 px 固定值写 line-height，它不会随字号缩放；用无单位数值（如 1.6），才能继承父级字体大小做相对计算。
font-family 和 line-height 在移动端为什么更敏感？
移动设备屏幕窄、像素密度高、用户常斜持或远距浏览，微小的行距偏差或字体缺失更容易引发疲劳。iOS 的 -apple-system 和安卓的 Roboto 默认渲染逻辑不同，光靠系统字体名不够稳定。
实操建议：
- 对
<p></p>、<article></article>等正文容器单独设置font-family和line-height，别全站只靠body统一继承 - 用
@supports (font-variation-settings: normal)检测是否支持可变字体，条件性加载Inter Variable或HarmonyOS Sans提升细腻度 - 避免在
line-height上叠加padding或margin模拟行距——这会让行高计算不可控，且影响可访问性（屏幕阅读器依赖真实行高语义）
为什么 font-display: swap 是字体加载的底线配置？
没加 font-display: swap 的自定义字体（如从 Google Fonts 或 CDN 加载的 .woff2），首次访问时会触发「FOIT（Flash of Invisible Text）」：文字空白几秒再突然出现，打断阅读节奏，还可能触发布局偏移（CLS）指标恶化。
只需在 @font-face 规则中加这一行：
font-display: swap;
它让浏览器先用系统字体渲染，等自定义字体加载完成再无感替换。注意：swap 不等于“随便换”，仍需确保 fallback 字体与目标字体在 x-height、字宽上接近，否则替换时会有明显跳动。
真正难的是平衡——中文字体文件大，全量加载不现实；但只加载常用字又得配合子集化工具（如 glyphhanger）和 unicode-range 切分，这部分很容易被忽略，却直接影响首屏文字是否“一眼可读”。
