移动端文本可读性差主因是行高、字体加载时机与视口控制未适配设备特性：需分层写系统字体栈、用无单位line-height、配font-display: optional/block、结合clamp()响应式调控字号与行高，并验证viewport缩放稳定性。
移动端文本可读性差，多数不是字体选得不好，而是行高、字体加载时机和视口控制没对齐设备特性。iOS 和 Android 的渲染机制不同，靠一套 CSS 通吃所有机型注定会模糊、挤行或闪跳。
font-family 要按系统分层写，别只堆英文名
直接写 "Helvetica Neue", Arial, sans-serif 在安卓上可能 fallback 到 Roboto，在 iOS 上却可能降级到更细的 San Francisco 变体，导致小字号下字干发虚、间距失衡。
- 优先用系统字体栈：
-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "PingFang SC", "Microsoft YaHei", sans-serif - 中文字体必须显式包含，比如
"PingFang SC"（iOS）、"HarmonyOS Sans"（华为）、"MiSans"（小米），不能指望sans-serif自动兜底 - 避免在
body一级统一设font-family，p、li、caption等容器要单独声明——不同语义元素对字重、字宽敏感度不同
line-height 必须用无单位值，且避开 padding 模拟行距
用 line-height: 24px 或 line-height: 150% 在高 DPR 屏幕（如 iPhone 15 Pro）上会因缩放错位；用 padding-top + padding-bottom 拉开视觉行距，会让屏幕阅读器误判段落结构，也破坏基线对齐。
- 一律用无单位数值，如
line-height: 1.6——它始终是当前font-size的倍数，不随缩放抖动 - 正文建议 1.5–1.7，标题可略低（1.2–1.4），避免大字号下空洞感过强
- 别在
line-height外叠加margin控制段间距：段间距应由margin-bottom单独管，和行高解耦
font-display 决定模糊期长短，不是 font-smoothing
-webkit-font-smoothing: antialiased 在 iOS Safari 里完全无效，加了也没用。真正造成“刚打开字发灰”的，是自定义字体还没加载完时浏览器用系统字体临时渲染，等字体到位后重绘——这个过程就是模糊源头。
- 关键配置只有
font-display：对正文用font-display: optional，iOS 会主动跳过加载慢的字体，直接用系统字体稳住可读性 - 标题类内容可用
font-display: block，最多阻塞 3s，换来的是一次性清晰呈现，避免闪动 - 务必配
@supports (font-variation-settings: normal)检测可变字体支持，再条件加载Inter Variable或HarmonyOS Sans，否则在旧机型上反而多一次 HTTP 请求
clamp() 配 line-height 才真防挤行
只对 font-size 用 clamp(1rem, 1rem + 0.3vw, 1.25rem) 不够——字号缩小时，如果 line-height 还是固定 1.6，行距会相对变大，段落松散；字号变大时，固定行高又可能让行距不够，文字贴边。
- 把
line-height也做成响应式：line-height: clamp(1.4, 1.5 - 0.1vw, 1.6)，小屏收紧，大屏舒展 - 注意
clamp()三个参数单位要一致：都用无单位值，或都用rem，混用会导致计算失效 - 别在
html或body上设全局font-size再指望子元素继承——移动端 viewport 缩放会让根字号不可靠，直接在文本容器上用clamp()
最易被忽略的是 viewport meta 的 initial-scale=1 是否稳定生效，以及用户是否手动缩放过页面——一旦物理像素比和 CSS 像素不匹配，再精细的 line-height 和 font-display 都救不回模糊。每次上线前，真机双指捏合再放开，看文字是否瞬间变糊，是比任何 Lighthouse 报告都直接的验证方式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
