clamp() 能实现真正流畅的响应式字体，但需满足：preferred 必须含动态单位（如 vw），min/max 用固定单位（rem/px）；否则会卡死、跳变或缩到不可读。
直接说结论：clamp() 能实现真正流畅的响应式字体，但前提是 preferred 值必须含动态单位（如 vw），且 min 和 max 必须是固定单位（rem 或 px）——三者单位不兼容、顺序错、或 preferred 写成纯静态值，都会导致“假流体”：要么卡死在最小值，要么跳变，要么在小屏缩到不可读。
为什么 clamp(1rem, 2.5vw, 2rem) 在 iPhone SE 上字特别小？
因为 375px 宽度下 2.5vw = 9.375px，远小于 1rem（通常 16px），浏览器直接取 min；但问题不在“没生效”，而在你误以为它该从这刻开始增长。实际增长起点由 min / vw系数 × 100 决定：16px ÷ 2.5 × 100 = 640px —— 意味着直到 640px 宽才开始线性变化。小屏段全程“冻结”。
- 别用纯
vw当 preferred，改用calc(1rem + 0.8vw)，把增长起点提前到约 320px -
min别设 1rem 就完事，实测小屏可读下限：iPhone SE 竖屏下 14px（0.875rem）已接近极限，再小字形细节就糊 - 避免
min: 12px; max: 40px; preferred: 3vw这种混单位写法，部分安卓 WebView 会整条忽略声明
preferred 用 calc(1rem + Xvw) 而不是纯 Xvw 的真实原因
纯 Xvw 是一条过原点的直线，而文字可读性需求不是——你需要的是“从某宽度起开始放大”，不是“宽度为 0 时字号也为 0”。calc(1rem + Xvw) 把截距锚定在根字号上，让响应曲线真正贴合人眼对尺寸变化的感知。
- 例如
calc(1.125rem + 0.6vw)：在 320px 时 ≈ 16.3px，在 1440px 时 ≈ 27.5px，中间平滑过渡 - 斜率
X不是拍脑袋定的，而是按设计断点反推：(目标大屏字号 − 小屏字号) ÷ (大屏宽度 − 小屏宽度) × 100 - Sass 中用插值写
#{$base}rem + #{$slope}vw，别漏掉单位拼接语法，否则编译报错
line-height 怎么跟 font-size 一起“活”起来？
font-size 流体了，line-height 还写 1.5 是安全的，但它只是“可用”，不是“精准适配”。真正同步响应需要克制地干预：无单位值足够应对多数场景，只有当行高在极端视口下明显失衡（比如小屏挤、大屏空）时，才考虑用 clamp() 控制。
立即学习“前端免费学习笔记（深入）”；
- 优先用无单位
line-height: 1.35—— 它自动乘以当前font-size，零成本同步 - 若需微调，
line-height: clamp(1.25, 1.15 + 0.0015vw, 1.45)比直接套font-size的clamp更稳，因行高对视口敏感度低于字号 - 绝对禁止
line-height: 24px+font-size: clamp(...)组合，小屏下 24px 行高会把 16px 字撑得稀疏，大屏下又压扁 - 遇到
transform: scale()或 iframe 场景，vw仍按原始视口算，此时line-height用无单位值反而更可靠
真正难的从来不是写出那行 clamp()，而是确认 min 和 max 是否经得起实机测试：14px 在 OLED 屏上是否还保有字形锐度？2.5rem 在 4K 屏上是否吃掉太多垂直空间？这些数值无法靠 DevTools 里的像素值验证，得拿真机横竖屏反复划动看。
