纯rem或纯vw都不够用，因rem依赖js易在横竖屏切换等场景失效，vw无边界控制导致可读性崩坏；应以clamp(14px,4vw,20px)设html字体大小，使rem具备视口感知能力，并配transition缓解ios safari跳变、保留js fallback兼容旧环境。
为什么纯rem或纯vw都不够用
纯rem依赖JS动态设置html字体大小，但横竖屏切换、缩放、无障碍模式下容易失效；纯vw又没边界控制，iPhone SE上4vw只有约12px，桌面端可能飙到48px，可读性崩坏。真正稳定的做法是让rem提供基准弹性，vw提供连续响应，两者不互斥，而是分层协作。
怎么把vw塞进rem的根字号里
核心思路不是在文字上直接写vw，而是把vw用在html的font-size上，让后续所有rem计算自动带上视口感知能力。例如：
html {
font-size: clamp(14px, 4vw, 20px);
}
这样写之后，1rem就不再是固定值，而是在14px–20px之间随屏幕宽度线性变化；所有用rem写的字体（比如h1 { font-size: 2rem; }）自然获得动态缩放效果。
-
clamp()三个参数单位必须一致，这里全用px是为了兼容老浏览器，且避免rem嵌套计算干扰 - 别写
font-size: clamp(1rem, 4vw, 1.25rem)——rem在根元素上会递归引用自身，结果不可控 - 如果设计稿基准是375px，可先算出理想比例：比如希望375px时为16px，则
4vw≈375 * 0.04 = 15px，接近目标，微调即可
移动端必须处理的两个隐藏坑
iOS Safari在横屏→竖屏切换瞬间，vw值会短暂卡住，导致html字号跳变，文字闪烁。这不是bug，是渲染机制限制。
- 加一层
transition: font-size 0.2s ease在html上，能明显缓解跳变感 - 别用
vw做行高、间距等对齐敏感的属性，只用于字体大小这类允许小幅浮动的场景 - 父容器若用了
display: inline或未设width: 100%，vw仍以整个视口为基准，但文字实际渲染宽度受限于容器，造成“缩了却看不出”的假象
要不要保留JS fallback
要。尽管现代iOS/Android Chrome都支持clamp()和vw，但部分低端安卓WebView（如UC内核旧版本）对vw解析不准，clamp()则完全不支持。
- 用
@supports (font-size: clamp(1px, 1px, 1px))包裹CSS方案，里面再套一层媒体查询降级 - JS fallback只需极简逻辑：
document.documentElement.style.fontSize = Math.min(Math.max(window.innerWidth / 375 * 16, 14), 20) + 'px'; - 注意监听
resize和orientationchange，但不用防抖——字体重排本身开销低，过度节流反而导致横竖屏切换后延迟生效
真正难的不是写对clamp()，而是确认你的html元素宽度就是视口宽度——任何外层框架、iframe、微信内置浏览器的UI遮罩，都可能悄悄截断这个链路。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
