纯 vw 响应式字体是反模式，因小屏过小、大屏过大且无视用户字号偏好；应使用 clamp(1rem, 0.5rem + 2vw, 1.5rem) 结合 rem 与 vw 实现安全缩放，并注意组件、行高及第三方库的适配。
响应式字体缩放为什么不能只靠 vw
直接用 font-size: 4vw 看似简单，但实际会出问题：小屏下文字过小（比如 iPhone SE 的 320px 宽度，4vw ≈ 12.8px），大屏下又可能过大（2560px 屏幕下直接到 102.4px）。更麻烦的是，它完全脱离了用户系统字号偏好（rem 基准）和可访问性设置，导致部分用户根本看不清。所以纯 vw 是反模式，得结合最小值、最大值和相对基准来约束。
用 clamp() + rem 实现安全缩放
clamp() 是目前最简洁可靠的方案，它能同时定义下限、首选值、上限，且原生支持单位混合计算。关键在于把视口单位和 rem 组合起来，让缩放有“锚点”。
html {
font-size: clamp(1rem, 0.5rem + 2vw, 1.5rem);
}这段代码的意思是：字体最终大小不会小于 1rem（约 16px），也不会大于 1.5rem（约 24px），中间按 0.5rem + 2vw 线性过渡。其中 0.5rem 提供基础偏移，2vw 负责随宽度增长——这样既保留了用户设置的根字体基准，又实现了平滑响应。
- 如果用户把系统默认字号调成 20px，
1rem就是 20px，整个缩放区间自动上移 -
clamp()在 Chrome 88+、Firefox 79+、Safari 13.1+ 均已稳定支持；IE 不支持，需 fallback - 避免写成
clamp(16px, 0.5rem + 2vw, 24px)—— 混用绝对像素和相对单位会破坏可访问性
用 CSS 变量 + calc() 手动模拟 clamp()
需要兼容老浏览器（比如旧版 Safari 或微信内置浏览器）时，可以用变量控制断点，再配合媒体查询 + calc() 分段实现。这不是“优雅”，而是务实妥协。
立即学习“前端免费学习笔记（深入）”；
:root {
--fs-base: 1rem;
--fs-min: 1rem;
--fs-max: 1.5rem;
--vw-factor: 2;
}
<p>html {
font-size: var(--fs-base);
}</p><p>@media (min-width: 320px) {
html {
font-size: calc(var(--fs-min) + ((100vw - 320px) * var(--vw-factor) / (1440 - 320)));
}
}</p><p>@media (min-width: 1440px) {
html {
font-size: var(--fs-max);
}
}这里用了两个断点：320px（最小设备宽度）和 1440px（认为足够大），中间线性插值。注意分母 (1440 - 320) 必须是固定值，不能用 100vw 替代，否则会循环计算失败。
- 变量名如
--vw-factor要语义清晰，避免用--a--b这类命名，后续维护容易懵 - 所有
calc()内部的单位必须一致（比如都用px或都用rem），混用会导致整个表达式失效且无报错 - 这个方案在 iOS 12.2 之前的 Safari 中，
calc()里用vw有 bug，建议加@supports (font-size: calc(1rem + 1vw))来检测
字体缩放真正容易被忽略的点
很多人调完 html 的 font-size 就以为结束了，但真实项目里还有三处常被跳过：
- 组件内部若用了固定
px字号（比如按钮写死font-size: 14px），会直接无视根缩放——一律改用em或rem - 行高
line-height如果写成line-height: 20px，缩放后文字挤在一起；应写无单位值（如line-height: 1.5）或rem - 第三方 UI 库（如 Element Plus、Ant Design）默认不响应根字体变化，需要手动覆盖其
font-size类或启用库自身的响应式开关
响应式字体不是“设一个值就完事”，它是贯穿 HTML 结构、CSS 单位选择、第三方依赖适配的连贯链条。漏掉任意一环，用户在某个设备上就会看到突兀的小字或撑破容器的大字。
