clamp()三参数顺序为“下限-首选-上限”，非直觉的最小-中间-最大；下限和上限常用固定单位（px/rem），首选用流体单位（vw/calc）；Safari需降级+避免嵌套calc；line-height宜用无单位值或em；须实机测试边界宽度。
clamp() 里三个参数到底怎么填
直接说结论：clamp(最小值, 建议值, 最大值) 不是“最小-中间-最大”的直觉排序，而是“下限-首选-上限”，浏览器会在这个范围内弹性缩放。常见错误是把 rem 和 vw 混搭时单位写错，比如 clamp(16px, 2.5vw, 24px) 看似合理，但 2.5vw 在小屏可能低于 16px，导致字号卡死在 16px —— 这其实是设计意图，不是 bug。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
最小值一般用固定单位（px或rem），确保极小屏可读，比如14px或0.875rem -
建议值优先用流体单位（vw、vh或rem计算式），例如calc(1rem + 0.5vw)，避免纯vw在中等屏产生跳跃 -
最大值用固定单位封顶，防止大屏字号过大，比如28px或1.75rem - 别用
%或em作clamp()参数，它们相对计算复杂，容易失控
为什么 font-size: clamp(...) 在 Safari 里不生效
老版本 Safari（iOS 13.4 / macOS 10.15.4 之前）根本不支持 clamp()，连 @supports 都检测不出。更隐蔽的问题是：Safari 对 clamp() 中的 calc() 表达式解析更严格，比如 clamp(1rem, calc(1rem + 0.25vw), 1.5rem) 在某些 Safari 版本会直接忽略整条声明。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 必须加降级：
font-size: 1.125rem; font-size: clamp(1rem, calc(1rem + 0.25vw), 1.5rem); - 避免在
clamp()里嵌套多层calc()，Safari 容易崩，改用简单线性表达式，比如calc(1rem + 0.2vw)而非calc(calc(1rem) + calc(0.2vw)) - 用
@supports (font-size: clamp(0px, 0px, 0px))检测支持性，但注意这个特性查询本身在旧 Safari 里也无效，所以降级样式必须写在前面
配合 line-height 实现真正响应式排版
只调 font-size 不够，line-height 固定会导致小屏行距过紧、大屏过松。但 line-height 不支持 clamp() 直接作用（它只接受无单位数值或长度值），得换思路。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用无单位
line-height（如1.4），它会随font-size自动缩放，最省事也最可靠 - 如果必须精确控制，把
line-height改成em单位，比如line-height: 1.4em，它会基于当前元素的font-size计算 - 绝对不要用
px固定line-height，否则clamp()缩小时行高不变，文字会挤在一起 - 标题和正文建议分开处理：标题用
clamp()+ 无单位line-height，正文用rem基础字号 +em行高微调
viewport width 变化太敏感？加个 min-width 保险
clamp() 响应的是视口宽度，但用户横屏/竖屏切换、浏览器窗口拖拽时，vw 值频繁跳变，可能导致字号闪烁。尤其在 Chrome 移动端，快速滚动时偶发重绘异常。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 给根元素加
min-width: 320px（或你支持的最小宽度），限制vw下限，减少极端缩放 - 用
font-size: clamp(1rem, 1rem + 0.5vw, 1.5rem)比纯vw更平滑，因为加法项让变化斜率更缓 - 如果项目用 CSS 自定义属性，别这样写：
--fs-title: clamp(...); font-size: var(--fs-title);—— 部分浏览器对自定义属性里的clamp()解析不稳定，直接写在font-size上更稳妥
真正麻烦的不是写法，是测试——得在 iPhone SE（375px）、iPad（768px）、27寸显示器（2560px）上逐个看字号是否连续过渡，而不是在某个宽度突然跳变。很多人卡在这里，不是不会写 clamp()，是没真正在边界宽度下点开开发者工具量像素。
