clamp() 三参数须满足 min ≤ preferred ≤ max 且单位尽量统一，否则失效；它仅裁剪不插值，活动区间由首选值与边界的交点决定。
clamp() 的三个参数到底怎么填才不翻车
直接说结论：第一个参数是最小值，第二个是首选值，第三个是最大值，但很多人填错单位或数值关系导致失效。clamp() 不会自动“响应”，它只做区间裁剪——超出范围就卡在边界上，不会插值过渡。
常见错误是写成 clamp(16px, 2vw, 12px)，最大值比最小值还小，浏览器直接忽略整个函数，回退到默认字体大小。必须保证 min ≤ preferred ≤ max，且单位尽量统一（推荐全用 px 或全用 rem，混合 vw 和 px 时要注意视口宽度变化节奏）。
- 首选值建议用相对单位（如
2.5vw或1.25rem），让它随上下文变化 - 最小值设为移动端可读下限（比如
14px），避免小屏缩得太小 - 最大值设为大屏舒适上限（比如
28px），防止超宽屏文字撑爆容器
为什么 font-size: clamp(16px, 2.5vw, 24px) 在某些宽度下没变化
因为 2.5vw 在视口宽度 640px 时等于 16px，在 960px 时等于 24px。也就是说，这个表达式只在 640px ~ 960px 区间内真正“活动”，之外都被钳制住了。这不是 bug，是设计行为。
想让过渡更长、更平滑？得拉宽这个活动区间：clamp(16px, 1.5vw + 1rem, 28px) 这种线性组合更可控。注意加法中单位要兼容——1rem 是根字体大小，如果 :root 设了 font-size: 16px，那 1rem 就是 16px，和 1.5vw 相加才有意义。
立即学习“前端免费学习笔记（深入）”；
- 避免纯
vw单位做首选值，小屏下可能低于最小值，大屏下可能超最大值 - 用
calc()混合单位时，确保加数单位可计算（vw + px合法，vw + em在某些旧浏览器里有问题） - 用浏览器 DevTools 的“响应式模式”拖动宽度，观察 computed 样式里
font-size是否真在变，而不是一直卡在 min 或 max 上
clamp() 配合 rem 实现可访问性缩放的注意事项
用户手动放大系统字体（比如 macOS 的“更大字体”或 Windows 的“显示缩放”）时，rem 会响应，但 vw 不会——它只认视口宽度。所以 clamp(1rem, 2.5vw, 1.75rem) 在高缩放比下可能失效：首选值被固定在某个像素值，不再随 root 字体变化。
更健壮的做法是把所有参数都基于 rem，再用媒体查询兜底：font-size: clamp(0.875rem, 1.125rem, 1.5rem)，然后配合 @media (min-width: 768px) 提升基准 rem 值。这样既保留 clamp() 的区间控制，又不破坏用户缩放偏好。
- 不要在
clamp()里混用rem和vw，除非你明确知道缩放场景下的行为差异 - 检查
:root的font-size是否被 JS 动态修改过，这会影响所有rem计算 - 用 Safari 测试——它是唯一默认禁用
vw在缩放时响应的主流浏览器
性能和兼容性那些没人提但很疼的点
clamp() 本身无性能问题，但高频重排场景（比如滚动时动态改字体）会触发 layout thrashing。更隐蔽的问题是：它不能被 CSS 自定义属性（--size）直接代入，必须写死数值或用 var(--size) 配合预设值列表。
兼容性方面，Chrome 88+、Firefox 79+、Safari 14.1+ 支持，IE 完全不支持。如果项目还要兼容旧 Safari（@supports (font-size: clamp(0, 0, 0)) 包裹，并 fallback 到媒体查询方案。
- 不要在
@keyframes里用clamp()控制动画中的字体大小——多数浏览器不支持动画化clamp()计算结果 - Next.js / Remix 等 SSR 框架里，服务端渲染时无法获取
vw，首次渲染会按最小值显示，等客户端 hydration 后才修正 - 用
getComputedStyle(el).fontSize读取时，返回的是计算后的像素值，不是原始clamp()表达式，调试时别被这个迷惑
