推荐用 clamp() 限制 vw 字体缩放范围，如 clamp(16px, 4vw, 32px)；标题与正文应设不同基准，优先采用 rem + 媒体查询控制根字号，慎用 vh，须兼顾系统字体设置与可访问性。
用 vw 实现等比缩放字体，但要注意基准和断点
vw 是视口宽度的 1%，100vw 就是整个屏幕宽。直接写 font-size: 4vw 确实能让字体随屏幕变大而变大，但问题很实际：小屏下字太小（比如手机上 4vw ≈ 15px），大屏下又爆炸（4K 屏上可能超 80px）。这不是“自动缩放”，是“无约束放大”。
推荐做法是加限制：
- 用
clamp()锁定范围：font-size: clamp(16px, 4vw, 32px)—— 最小 16px，最大 32px，中间按 4% 视宽线性变化 - 避免全站统一用
vw，标题和正文对缩放敏感度不同：一级标题可用clamp(24px, 6vw, 48px)，正文字体更适合clamp(14px, 3.2vw, 18px) - 注意设计稿基准：如果按 375px 设计，
4vw在 iPhone 上≈15px，但实际渲染受系统字体缩放、用户设置影响，vw不会尊重这些
em 和 rem 配合媒体查询才是可控响应式字体的核心
em 相对父元素，rem 相对根元素（html），它们本身不“响应”，但和 @media 搭配就非常稳定。
典型做法是先设根字号，再用 rem 写所有字体：
立即学习“前端免费学习笔记（深入）”；
html {
font-size: 16px;
}
@media (max-width: 768px) {
html { font-size: 14px; }
}
@media (min-width: 1200px) {
html { font-size: 18px; }
}
然后所有字体用 rem：h1 { font-size: 2.5rem; }（即小屏 35px，中屏 40px，大屏 45px）。这样缩放有依据、可预测、兼容老浏览器，也支持用户手动调大系统字体。
- 别在
html上直接用vw改font-size（如font-size: 4vw），会导致子元素计算混乱，尤其嵌套深时 -
em更适合局部微调，比如按钮内图标字号随按钮大小变化：.btn { font-size: 1rem; } .btn i { font-size: 0.8em; }
慎用 vh 调整字体，它和滚动、地址栏隐藏强相关
vh 是视口高度单位，看似能做“全屏适配”，但实际非常脆弱。iOS Safari 地址栏收起/展开时，100vh 会突变（比如从 640px 变成 720px），导致字体闪跳；Android 也有类似问题。
除非你明确需要“铺满视口高度”的展示型标题（如 landing page 主标题），否则不要用 vh 控制常规文本。
- 若真要用，必须配合
min-height和max-height保底，例如：font-size: clamp(20px, 8vh, 60px) - 绝对避免在
body或通用段落上设vh字号，用户滚动时字体抖动会直接引发可访问性问题 - 测试时务必在真机 Safari 手动拖动地址栏，看是否触发重排
真实项目里，混合方案比单一单位更可靠
纯 vw 太激进，纯 rem + media 更新成本高，实际项目往往分层处理：
- 基础字号用
rem+ 媒体查询控制（保障可读性和兼容性） - 关键标题用
clamp(最小值, vw 中间值, 最大值)做视觉强化 - 禁用用户缩放的场景（如数据仪表盘）才考虑
vh，且必须加overflow: hidden防滚动干扰 - 永远检查
font-size计算结果：Chrome DevTools 的 Computed 面板里看最终像素值，别只信 CSS 写法
最常被忽略的是系统级干预——iOS「更大字体」设置、Windows 缩放比例、Chrome 的字体缩放选项，都会覆盖 CSS 单位逻辑。所以响应式字体的终点不是“怎么缩”，而是“缩完还是否可读”。
