clamp() 比单纯用 vw 更可靠，因其能强制限定字体大小范围，避免小屏过小、大屏过大问题，且支持带边界的响应式缩放，而 vw 单独使用存在兼容性、基准偏差和无约束风险。
clamp() 为什么比单纯用 vw 更可靠
直接写 font-size: 4vw 看似简单，但屏幕极小（比如 iPhone SE）时字体可能缩到 10px 以下，阅读困难；大屏又可能撑到 48px 以上，破坏行高和布局节奏。而 clamp() 能强制限定范围：clamp(1rem, 2.5vw, 1.5rem) 表示「最小 1rem、理想值是 2.5vw、最大不超过 1.5rem」——它不是线性拉伸，而是带边界的响应式。
常见错误是把中间值设成固定值（如 clamp(1rem, 1.25rem, 1.5rem)），这就退化成普通媒体查询，失去视口依赖；或者三值单位混用（如 clamp(16px, 3vw, 2em)），CSS 不允许单位不一致，会整个声明失效。
- 中间值必须是相对单位（
vw、vh、rem等），且与首尾单位可比较（浏览器按计算后像素值比大小） - 首尾值建议统一用
rem，便于配合根字体调整（如用户系统放大字体时仍可继承） - 移动端小屏下
vw基数太小，建议中间值用min(4vw, 1.25rem)做兜底，再套进clamp()
vw 单位在真实项目中容易被忽略的兼容性陷阱
vw 在 iOS Safari 9+ 和 Android Chrome 49+ 支持良好，但老版本微信内置浏览器（X5 内核）对 vw 的解析有偏差：竖屏转横屏时不会实时重算，导致字体卡在旧尺寸。更隐蔽的问题是，某些安卓 WebView 会把 viewport 宽度算错（比如包含虚拟导航栏），让 100vw 实际大于屏幕物理宽度，字体意外放大。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 必须加 viewport meta：
<meta name="viewport" content="width=device-width, initial-scale=1.0">，否则vw基准失效 - 避免单独依赖
vw做关键字号（如标题），至少用clamp()包一层，或搭配@supports (font-size: clamp(1px, 1px, 1px))做特性检测降级 - 调试时用 DevTools 强制切换设备尺寸，观察字体是否随窗口 resize 实时变化；若卡住，大概率是 X5 内核或 viewport 配置问题
如何用 clamp() 实现“移动优先 + 桌面增强”的阶梯式响应
真正实用的响应式字体不是平滑过渡，而是分段优化：小屏保可读、中屏适配手指点击、大屏强化信息层级。例如正文 font-size: clamp(1rem, 1.2vw + 0.75rem, 1.25rem) —— 这里用了 calc 表达式作为中间值，让字号随宽度缓慢增长，比纯 2.5vw 更柔和。
典型场景对比：
- 按钮文字：用
clamp(0.875rem, 1.5vw, 1rem)，小屏不小于 14px，大屏不超 16px，保证点击热区和视觉重量平衡 - 卡片标题：用
clamp(1.125rem, 4vw - 1rem, 2rem)，减法公式让中屏增长更快，突出内容主次 - 避免在
h1上无脑套clamp(2rem, 6vw, 4rem)，会导致中等宽度（如 iPad 竖屏）字号突兀跳变，应拆成两段：先用媒体查询切到平板尺寸，再在该断点内用clamp()
line-height 和 font-size 的响应式必须同步处理
只调 font-size 而忽略 line-height 是最常被忽视的坑。当字号从 16px 缩到 14px，若 line-height: 1.5 不变，行距会显得拥挤；反之放大时可能留白过多。更麻烦的是，line-height 不支持 clamp() 或 vw（CSS 规范禁止在 line-height 中使用 vw）。
解决方案有限但有效：
- 用无单位数值（如
line-height: 1.4）而非像素值，让行高随字号自动缩放 - 对需要精细控制的场景（如多行标题），改用
padding或margin调整垂直间距，它们支持clamp() - 若必须动态行高，可用 CSS 自定义属性 + JavaScript 监听 resize，但仅限极端需求（如实时排版工具），普通项目得不偿失
复杂点在于，不同字体的 x-height 差异会让相同 line-height 呈现效果不一，所以最终要真机多测，不能只信设计稿数值。
