clamp()比media query更适合响应式字体，因其支持最小值—首选值—最大值的连续过渡，浏览器实时计算，而media query仅能阶梯式跳变且需多组规则。
clamp() 为什么比 media query 更适合响应式字体
因为 clamp() 能在单个声明里完成「最小值—首选值—最大值」的连续过渡，浏览器按视口实时计算，不依赖断点切换。media query 只能做阶梯式跳变，缩放过程生硬，且要反复写多组规则。
- 常见错误现象：
font-size: clamp(16px, 2.5vw, 24px)在超小屏（比如 iPhone SE）下文字仍偏大——问题出在2.5vw的基准没压住，2.5vw在 375px 宽度下是 9.375px，低于16px下限，所以实际取的是16px；但用户误以为它会“自动适配”，结果发现小屏没变小 - 使用场景：标题、卡片主文案、表单标签等需要随屏幕平滑缩放的文字，不适用于固定字号需求（如图标字体、代码片段）
- 参数差异：
clamp(min, preferred, max)中preferred必须是相对单位（vw、vh、rem），min和max推荐用绝对单位（px）或rem，避免嵌套计算失真
怎么算出靠谱的 vw 值，不让文字忽大忽小
靠拍不行，得锚定一个参考尺寸。比如你希望在 1440px 屏幕上显示 28px 字体，那就用 28 / 1440 = 0.0194，约等于 1.94vw。这样在 1440px 时刚好是 28px，更宽时略增、更窄时略减，再配合 clamp() 收束边界。
- 容易踩的坑：
clamp(16px, 3vw, 32px)看似合理，但在 500px 屏幕下3vw = 15px，低于16px，最终恒为16px——结果就是“小屏不缩”，白写了 - 实操建议：先定好目标视口（比如设计稿宽度），算出该处对应的
vw值；再测试两端极限（320px和1920px），看是否触达min或max；最后微调preferred的系数 - 性能影响：
clamp()是 CSS 运行时计算，现代浏览器优化得很好，无明显开销；但别在大量元素（如每行列表项）上滥用，尤其配合vh时可能触发重排
兼容性差怎么办？必须支持 Safari 13 以下或旧 Edge
老版本 Safari 和 IE 完全不认 clamp()，会直接忽略整条声明。不能只写 clamp()，得降级。
- 正确写法：先写降级值，再覆盖
clamp()，例如：font-size: 20px;<br>font-size: clamp(16px, 2.1vw, 24px);
浏览器从上到下解析，不支持的跳过第二行 - 不要用
@supports (font-size: clamp(...))包裹——部分旧版 Safari 对@supports解析有 bug，反而导致降级失效 - 兼容性影响：iOS 13.4+、Chrome 88+、Firefox 75+ 原生支持；Safari 13.1 开始支持但存在渲染抖动（首次加载闪一下），可加
transform: translateZ(0)强制 GPU 加速缓解
和 rem + 媒体查询混用时，哪个优先级更高
clamp() 是最终计算值，只要它被成功解析，就会覆盖前面所有 font-size 声明，包括通过 rem 设置的根字体或媒体查询里的规则。
- 典型冲突场景：全局设了
html { font-size: 62.5%; }，又在@media (max-width: 768px)里把html改成50%，但某标题用了clamp(1.6rem, 4vw, 2.4rem)——此时rem基准已变，但clamp()里的1.6rem和2.4rem会随根字体缩放，而4vw不会，三者不再对齐 - 实操建议：在
clamp()中统一用px写min/max，preferred用vw；或者全程用vw，避免混用单位引发比例错乱 - 容易被忽略的点：
clamp()不继承父元素的font-size缩放逻辑，它是独立计算的——这意味着你不能靠改html的font-size来批量调控所有clamp()文字，每个都得单独调
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
