不同浏览器字体渲染不一致是常态，根源在于渲染引擎、系统字体栈、抗锯齿策略及font-display行为差异；需用多字体栈、font-display:swap、WOFF2格式、禁用local()、条件启用-webkit-font-smoothing，并通过Computed面板、network验证和document.fonts.check三步确认真实渲染效果。
不同浏览器对同一段 HTML 字体渲染不一致，不是 bug，是常态——根源在渲染引擎、系统字体栈、抗锯齿策略和默认 font-display 行为的组合差异。直接上可落地的解法，别等“统一方案”。
为什么font-family: "Microsoft YaHei"在 macOS 上完全不生效
Windows 系统预装“微软雅黑”，macOS 无此字体，且 Safari/Chrome for iOS 强制走 WebKit，连 fallback 都可能跳过你写的第二项。浏览器不会报错，只会静默回退到系统默认 sans-serif（如 macOS 的 -apple-system）。
- 永远用字体栈，而不是单字体：
font-family: "Microsoft YaHei", "PingFang SC", "Hiragino Sans GB", "Segoe UI", sans-serif; - 中文字体名带空格必须加引号；英文无空格如
Helvetica可不加，但加了更稳妥 - 避免把
"SimSun"放在栈末尾——它在 macOS/Linux 上几乎不存在，反而会拖慢字体匹配流程
@font-face 加载后文字闪动或空白（FOIT）
Chrome 默认阻塞文本渲染直到自定义字体加载完成；Firefox 和 Safari 行为略有不同，但都可能造成“空白一秒再弹出”。这不是网络慢，是字体加载策略未显式声明。
- 必须加
font-display: swap;到每个@font-face规则里，不能只写在全局 CSS 中 - WOFF2 是首选格式（压缩率高、Chrome/Firefox/Safari 15.4+ 全支持），WOFF 作降级，TTF/OTF 尽量不引入
- 不要依赖
local()声明——local("Microsoft YaHei")在非 Windows 设备上永远失败，还可能触发冗余下载
-webkit-font-smoothing 和 text-rendering 怎么设才不翻车
这些属性不是“开个开关就变清晰”，它们在不同系统上效果相反：比如 antialiased 在 macOS 上提升清晰度，在 Windows Chrome 下反而让文字发虚。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 只在 macOS + WebKit/Blink 内核下启用：
@supports (-webkit-font-smoothing: antialiased) { body { -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; } } -
text-rendering: optimizeLegibility对小字号中文帮助有限，且在 Firefox 中可能触发额外字距计算，建议仅用于英文标题类场景 - 禁用
auto值：text-rendering: auto由浏览器自行决定，实际行为不可控，线上环境一律显式指定
检查字体是否真被应用的三步验证法
别信“样式面板里写了就生效”。真实渲染链路是：HTML → 字体栈匹配 → 本地存在？→ 下载 WOFF2？→ 解码 → 渲染 → 抗锯齿介入。中间任一环断掉，都会降级。
- 打开开发者工具 → Elements → 选中文字元素 → Computed → 查
font-family最终值，确认是否落到你预期的字体名上 - 同页面右键 → “查看网页源代码” → 搜索
@font-face，确认 src 路径 200 OK，且响应头含Content-Type: font/woff2 - 在 Console 执行
document.fonts.check('16px "YourFontName"')，返回false表示字体尚未加载或匹配失败
最易被忽略的是字体加载时序与 DOM 渲染的竞态——JS 动态插入内容后立即调用 getBoundingClientRect()，很可能拿到的是 fallback 字体下的尺寸。这类问题不会报错，只能靠 document.fonts.load() + await 显式等待。
