最稳妥的移动端系统字体栈写法是：以system-ui为起点，按ios和android平台优先级补全fallback链，必须以sans-serif收尾，并配合适当的font-weight、line-height和text-rendering优化。
移动端 CSS 怎么写系统字体栈才不翻车
直接用 system-ui 是最稳妥的起点，但光写这一项在 iOS 和 Android 上表现不一致，必须补全 fallback 链并按平台优先级排序。
常见错误是把桌面端字体栈（比如 "-apple-system", "Segoe UI"）原样搬进移动端，结果在旧版安卓或微信内置浏览器里回退到丑陋的默认等宽字体；或者漏掉 font-weight: normal 导致部分系统粗体强制加粗、文字发虚。
- iOS 13+ 优先用
-apple-system，不是BlinkMacSystemFont（那是 Chrome 桌面用的） - Android 6+ 推荐
system-ui，它在 Chrome/Edge/Firefox 移动端都映射到本地无衬线体，比硬写Roboto更可靠 - 必须以
sans-serif收尾，不能省略——某些国产浏览器（如 QQ 浏览器 X5 内核）会忽略前面所有项直接 fallback 到这个
微信 / 支付宝小程序里 font-family 怎么写才生效
小程序 WebView 内核版本碎片化严重，system-ui 在微信 iOS 8.0.33 以下、安卓 8.0.30 以下基本不识别，得降级处理。
实测有效的写法是分层兜底：先塞系统关键词，再补一两个高覆盖率的中文字体名，最后用 sans-serif。
- 微信 iOS：优先
-apple-system，次选Helvetica Neue（别写Helvetica，iOS 17 已弃用） - 微信安卓：用
system-ui+HarmonyOS Sans（鸿蒙设备）+Source Han Sans SC（覆盖大部分国产 ROM） - 支付宝小程序需额外加
Alibaba PuHuiTi，这是其自定义默认字体，不加可能被强制替换为黑体
设置 font-size 后文字模糊？可能是 line-height 或 text-rendering 没配好
移动端高 DPR 屏幕下，font-size: 14px 实际渲染可能被缩放成非整数像素，加上默认 line-height: normal 的计算偏差，文字边缘就容易发虚。
这不是字体栈问题，但常被误认为“系统字体显示差”。关键在三处微调：
-
line-height设为无单位数值（如1.4），避免继承父级字号导致倍数错乱 - 加
text-rendering: optimizeLegibility，对 iOS Safari 和 Chrome 移动端的连字和字距有实际改善 - 慎用
-webkit-font-smoothing: antialiased：在深色背景上可能让文字变细发灰，只在浅底+深字时考虑启用
为什么用了系统字体栈，中文还是加载慢或闪动
核心原因是没关掉字体加载阻塞。即使写的是系统字体，浏览器仍可能发起字体发现请求（尤其在 @font-face 存在时），或因首屏文本未声明 font-display: optional 导致重排。
移动端没有“字体加载完成”事件，唯一可控点是 CSS 层级策略：
- 确保全局
body的font-family不依赖任何@font-face定义，全部走系统栈 - 如果项目用了自定义图标字体（如 iconfont），务必给其
@font-face加font-display: optional，否则会拖慢首屏文本渲染 - 避免在
:root或html上用font-family变量，Safari 移动端对 CSS 变量中的字体名解析不稳定
系统字体栈本身没加载成本，但只要混入一个外部字体声明，整个文本渲染流程就可能卡住几百毫秒——这点最容易被忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
