vw是纯数学缩放，不感知阅读舒适区、设备能力与系统设置；小屏字太小、大屏字爆炸，违背可读性原则，需用clamp()并统一基准单位配合text-size-adjust锁定。
因为vw是纯数学缩放，不感知阅读舒适区、不响应设备能力、不尊重系统设置。 它只做一件事：把视口宽度除以100再乘上系数。你给4vw，浏览器就老老实实算——375px屏上是15px，3840px屏上就是153.6px，中间没有任何干预逻辑。
小屏下字太小，大屏下字爆炸
直接写font-size: 2vw在iPhone SE（320px）上只有6.4px，远低于可读下限；而4K屏（3840px）下4vw直接飙到153.6px，标题顶穿导航栏、撑破容器、line-height完全失配。这不是响应式，是“裸奔式缩放”。
- 可读下限通常在14–16px（中文），
1.5vw在320px屏上仅4.8px，肉眼几乎不可辨 - 视觉上限建议控制在32–48px（标题）或18–24px（正文），
clamp()的max值必须卡死在这个区间 - 别信“设计稿说用4vw就行”——它没测过4K屏，也没考虑横竖屏切换时vw不刷新
clamp()里单位混用导致跳变
常见错误是写clamp(1rem, 2em, 2.5rem)。问题不在函数本身，而在em依赖父级font-size，而父级可能被其他CSS规则覆盖、重设甚至继承自body——结果中间值忽高忽低，字号在临界点跳变。
- 安全写法必须统一基准：
min用14px或1rem（固定保底），preferred用2.8vw或calc(1rem + 0.3vw)（不依赖父级），max用2.2rem（防高分屏溢出） - 避免
clamp(16px, 4vw, 32px)这种写法：在800px宽视口下4vw == 32px，刚好顶到上限，再宽1px就卡死不动，失去响应意义
真机上字体突然变小，和vw无关但你逃不掉
DevTools里看着正常，一上Android Chrome或Samsung Internet，字体莫名缩水——大概率是浏览器启用了Font Boosting。CSS单位再准也没用，text-size-adjust必须显式锁定。
- 加这条规则：
html { -webkit-text-size-adjust: 100%; text-size-adjust: 100%; } - 别用
none，它会破坏视障用户系统字号设置 - 这个设置不解决vw计算问题，但能防止浏览器“好心办坏事”，是上线前必查项
真正麻烦的不是clamp()怎么写，而是设计稿没给横屏字体规范，开发只能硬套竖屏逻辑；等发现横屏标题挤成一行、行高全乱，再补CSS就晚了——这时候你得回溯整个排版链路，而不是只调一个vw值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
