结论是必须用CSS控制字体且中文字体堆叠顺序错误会导致80%用户看到非预期字体；正确写法需分系统声明如-apple-system, BlinkMacSystemFont, "Segoe UI", "Microsoft YaHei", "PingFang SC", "Hiragino Sans GB", sans-serif，含空格字体名加引号，末尾必带无引号的sans-serif兜底。
直接说结论：别用 <font> 标签，所有字体控制必须走 CSS；中文字体堆叠顺序写错，80% 的用户看到的不是你预期的字体。
font-family 堆叠顺序怎么写才不 fallback 到宋体
浏览器按 font-family 声明从左到右找第一个本地存在的字体。硬写 "Microsoft YaHei" 在 macOS 或 Linux 上会跳过，直接落到 sans-serif（系统默认无衬线字体），结果中英文混排时中文是黑体、英文是 Helvetica，视觉割裂。
- 正确写法要分系统声明：
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Microsoft YaHei", "PingFang SC", "Hiragino Sans GB", sans-serif; - Windows 用户优先匹配
"Microsoft YaHei"，macOS 用-apple-system（即 San Francisco），Linux 退到sans-serif - 含空格的字体名必须加引号，比如
"Helvetica Neue"，否则解析失败 - 末尾的
sans-serif不可省——它不是“备选字体”，而是通用族名兜底，告诉浏览器：“实在没得选，就用系统默认无衬线字体”
font-size 设成 14px 为什么在手机上反而更难读
移动端 Safari 和 Chrome 对 font-size 小于 16px 的文本会强制放大（防误触），导致行高错乱、换行异常，甚至触发双击缩放。这不是 bug，是浏览器主动干预。
- 正文统一用
font-size: 16px，不是“越大越好”，而是平衡识别性与排版密度 - 标题用相对单位：
h2 { font-size: 1.5em; }，继承自根字号，避免 px/rem 混用导致缩放失准 - 别设
html { font-size: 10px; }再全局用 rem——除非你在做整站缩放体系，否则纯属增加调试负担 - 14px 在 Windows 清晰度调低时发虚，18px 在窄卡片里容易挤两行标题，16px 是实测最稳的锚点
line-height 设成 24px 为什么会导致响应式失效
line-height: 24px 是固定像素值，当父元素 font-size 变化（比如媒体查询切换字号），行高不会同比例缩放，文字立刻上下错位。
立即学习“前端免费学习笔记（深入）”；
- 一律用无单位数值，如
line-height: 1.6——它是相对于当前字号的倍数，天然响应 - 1.6 不是玄学：比 1.5 多出 0.1 倍字号间隙，刚好区分「一」和「十」；比 1.7 少 0.1，防止小屏段落被截断
- 不只是
p要设，ul、blockquote、figcaption等块级文本容器都得显式声明，否则继承可能不一致 - Flex 容器里别依赖
align-items: center垂直居中多行文字——它只对单行有效，跨行文本会偏移，老老实实用line-height控制基线
中文网页里用 “微软雅黑” 还安全吗
“微软雅黑” 在 Win7+ 基本全覆盖，但它不是万能解：macOS 没这个字体，Android WebView 可能忽略第二层声明，某些定制 ROM 甚至删掉了预装字体。
- 单独写
font-family: "Microsoft YaHei"= 自毁式写法，必须带兜底链 - 别信“一套字体走天下”的模板，真实环境里字体缺失率远高于预期
- 如果项目要求强一致性（比如金融类后台），考虑用 WOFF2 字体子集 +
@font-face加载，但要注意 FOUT/FOIT 体验 - 开发时打开浏览器开发者工具 → Elements → Computed → Font，直接看最终生效的是哪个字体——这是唯一可信依据
真正麻烦的从来不是“怎么写”，而是“写了之后谁在用、用什么系统、字体是否真存在”。字体声明不是装饰，是排版契约，每一项都要经得起 fallback 链路推演。
