必须用clamp()截断上限，典型写法为font-size: clamp(14px, 2.8vw, 2.2rem)，其中min保小屏可读、preferred避开em依赖视口、max防4K屏溢出。
font-size: 4vw 在 4K 屏上直接飙到 64px 怎么办
这不是设计问题，是数学问题：4K 屏宽 3840px，4vw = 3840 × 0.04 = 153.6px。标题顶穿导航栏、按钮文字撑爆容器、行高错乱——全是 vw 无脑线性缩放的必然结果。
必须用 clamp() 截断上限，不能靠“试试看”或后期加 @media 补救：
-
min设固定像素（如14px）或1rem，保小屏可读 -
preferred用2.8vw或calc(1rem + 0.3vw)，避开em（父级 font-size 不可控） -
max别超过2.2rem（约 35px），否则在 27 寸 4K 显示器上仍会溢出
典型写法：font-size: clamp(14px, 2.8vw, 2.2rem);
clamp() 里混用 rem 和 em 为什么会导致字体跳变
常见错误写法：clamp(1rem, 2em, 2.5rem)。表面看单位统一，但 em 的计算基准是父元素当前 font-size，而这个值可能已被其他 CSS 规则覆盖、JS 动态修改，甚至被浏览器 Font Boosting 干扰。
立即学习“前端免费学习笔记（深入）”；
结果就是：同一段 HTML，在不同嵌套层级下，2em 算出来可能是 32px，也可能是 20px，字体忽大忽小，毫无 predictability。
安全做法只有一条：preferred 必须脱离父级依赖：
- 用
2.5vw（直接锚定视口） - 或用
calc(1rem + 0.2vw)（1rem是根字号，稳定；0.2vw是增量，不依赖父级） - 绝对不要在
clamp()中塞em、%、ch这类相对单位
横竖屏切换时 vw 值卡死不动怎么破
iOS Safari 和部分安卓 WebView 在旋转瞬间不会重算 vw，字体尺寸冻结在旧值——不是 bug，是渲染管线不触发重排。DevTools 里看不出，真机一转就露馅。
纯 CSS 方案最稳：
- 加一句媒体查询兜底：
@media (orientation: landscape) { html { font-size: calc(100vw / 375 * 16); } } - 注意：这里的
375是设计稿基准宽度，16是 1rem 对应像素，按项目实际调整 - 别只写
@media (min-width: 768px)，它无法捕获 iPad 横屏这种“宽度没变但方向变了”的场景
JS 方案仅作备选：document.body.style.transform = 'scale(1)'（空操作强制重排），但需监听 resize 和 orientationchange 两个事件。
text-size-adjust 不设为 100% 会导致真机字体莫名变小
Chrome for Android、Samsung Internet 默认开启 Font Boosting：当检测到行宽过窄或字号过小，会自动放大文字。这时你写的 clamp(14px, 2.8vw, 2.2rem) 全部失效，真机上看比 DevTools 小 20%～30%。
唯一解法是显式锁定：
html { -webkit-text-size-adjust: 100%; text-size-adjust: 100%; }- 别用
none，它会破坏系统辅助功能（如视力障碍用户设置的全局字号） - 这个声明必须放在所有 CSS 最前面，否则可能被后续规则覆盖
真正麻烦的不是代码怎么写，而是设计稿压根没给横屏字体规范——开发只能硬套竖屏逻辑，等 QA 报“iPad 横屏标题挤成一行”才补 clamp()，此时 UI 已上线两周。
