clamp()做流体字号需确保min、preferred、max在视口范围内连续过渡；min取最小可读字号（如1.125rem），preferred用vw/svw，max设合理上限，避免单位混用与基准失效。
clamp() 的三个参数到底怎么配才不翻车
直接说结论：用 clamp() 做流体字号，核心不是“写对语法”，而是让 min、preferred、max 三值在真实视口范围内形成连续、无跳变的过渡。常见翻车是 min 太小（比如 1rem）而 max 又太大（比如 4rem），结果在中等屏幕下字体突然“卡住”不再缩放——本质是线性插值区间被硬生生切掉了。
实操建议：
-
min应取你设计系统里最小可读字号（如1.125rem对应 18px），不是“理论上能写的最小值” -
preferred推荐用相对单位（vw或svw），典型写法是clamp(1.125rem, 4vw, 2.25rem)；其中4vw意味着在 100vw=1000px 时约等于 40px，需结合基准屏宽反推 - 别用
%或em当 preferred，它们不随视口独立变化，会破坏流体逻辑 - 用
svw（small viewport width）替代vw可规避 iOS Safari 地址栏收缩导致的视口抖动，但兼容性略低（iOS 15+）
为什么在某些手机上字体根本不缩放
现象：开发时在 Chrome DevTools 模拟器里一切正常，真机（尤其老款安卓或 iOS 14）上 clamp() 完全失效，字体始终卡在 min 或 max。
原因和对策：
立即学习“前端免费学习笔记（深入）”；
- CSS 自定义属性（
--fs-title）里嵌套clamp()时，部分旧版浏览器解析失败，必须展开为直写值：font-size: clamp(1.125rem, 4vw, 2.25rem);而非font-size: var(--fluid-title); - 父容器设置了
font-size: 0;（常见于清除 inline-block 间隙），会导致rem基准归零，整个clamp()计算坍塌 - 使用了
text-size-adjust: none;（尤其在 meta viewport 里加了user-scalable=no），会强制禁用用户缩放，连带干扰clamp()的响应行为 - 检查是否误将
clamp()写在@supports查询里但没覆盖 fallback，例如只写了@supports (font-size: clamp(...)) { ... }却没给不支持的浏览器设font-size: 1.5rem;
与媒体查询对比：什么时候该换回 @media
clamp() 不是万能替代品。当你的字号需要非线性变化（比如在 320–480px 区间平缓增长，481–768px 突然加大步进，769px+ 又放缓），clamp() 的单一线性插值就力不从心。
更现实的判断点：
- 如果设计稿明确标注了 3 个以上断点字号（如 320px→18px，480px→20px，768px→24px，1024px→28px），优先用
@media分段控制，比硬凑多个clamp()嵌套更清晰、易维护 - 需要同步调整行高、字间距等其他排版属性时，
@media能批量作用于一个选择器，而clamp()只管单个属性，容易造成节奏脱节 - 做无障碍适配时，用户系统级字体放大（如 iOS “更大字体”开启）会直接影响
rem基准，此时clamp()中的rem部分会被放大，但vw部分不变——混用单位可能意外破坏可访问性，这时纯rem+@media更可控
实际项目里最该盯住的两个细节
一是 viewport meta 标签必须包含 width=device-width，否则 vw 单位计算基准错乱，clamp() 直接失效；二是所有参与计算的单位必须可比较——不能把 px 和 rem 混在同一个 clamp() 里，浏览器虽不报错但行为不可预测（例如 clamp(16px, 4vw, 2rem) 在不同 root font-size 下结果飘移）。
真正难的不是写对那一行代码，而是想清楚：这个字号到底要响应谁的变化？是设备宽度？容器宽度？还是用户当前的阅读距离？选错响应维度，再漂亮的 clamp() 也只是精致的错。
