首选 clamp(16px, 4vw + 12px, 24px)，因纯 vw 缺乏锚点易失控，加固定偏移（如+12px）使缩放落在可读区间；Safari 要求单位一致，禁混用 rem/em 与 vw；line-height 也需 clamp 或 em 匹配字号变化；必须前置 px/rem fallback 保障旧浏览器兼容。
直接结论：用 clamp(16px, 4vw + 12px, 24px)，单位全用 px，且必须前置 fallback。
为什么首选值必须带固定偏移（比如 4vw + 12px）？
纯 5vw 在 375px 屏上只有 18.75px，在 1440px 屏上却飙到 72px——它没锚点，缩放完全失控。加一个固定像素（如 +12px）相当于把线性函数平移，让缩放曲线落在可读区间内。
-
4vw是实测较稳的斜率系数，3–5 范围内可调，低于 3vw 小屏启动慢，高于 5vw 大屏易溢出 - 偏移量（
12px）要能保证小屏下首选值 ≥ min，例如4vw + 12px在 320px 时为 24.8px，已超16px，缩放才能真正“动起来” - 别写
clamp(14px, 2.5vw, 20px)——2.5vw 在 320px 仅 8px，浏览器直接取14px，字体卡死不动
为什么 Safari 里 font-size: clamp() 常常不生效？
不是 bug，是 Safari 对单位一致性要求更严：它拒绝解析 rem 和 vw 混用时的隐式上下文依赖。比如 clamp(1rem, 4vw, 1.5rem) 中，1rem 可能随根字号变化，而 4vw 是视口绝对值，Safari 渲染阶段无法同步判定三者是否可比。
- 最稳方案：全用
px，例如clamp(16px, 4vw + 12px, 24px) - 若需适配系统字号放大，可全用
rem，但必须固定根字号：html { font-size: 16px; }，再写clamp(1rem, 4vw + 0.75rem, 1.5rem) - 绝对不要混用
em/rem和vw，尤其当父元素有动态font-size时，em会继承断裂，计算结果不可控
line-height 怎么跟上 font-size: clamp()？
无单位 line-height: 1.5 理论上会乘以当前字号，但实际中容易在小屏下“缩水”：字号压到 14px 时，行高只剩 21px，段落拥挤。它不是自动适配，而是被动缩放。
立即学习“前端免费学习笔记（深入）”；
- 推荐给
line-height也套一层clamp()，例如line-height: clamp(1.4, 0.2vw + 1.3, 1.6)，让行高与字号同节奏变化 - 或统一用
em单位：line-height: 1.5em，因em和font-size同源，计算链更干净 - 检查设计稿的「行高/字号」比值：移动端通常需更高（1.5–1.6），桌面端可略低（1.3–1.4），不能只靠一个固定值硬套
旧浏览器 fallback 必须怎么写才真起作用？
只写一行 font-size: clamp()，iOS 13.3 或 Android WebView 会静默忽略整条规则，回退到浏览器默认 16px，非常危险。
- 必须用层叠顺序：
font-size: 1.125rem;写在前，font-size: clamp(...);写在后，新浏览器覆盖，老浏览器读第一行 - 别用
@supports (font-size: clamp())包裹——iOS 13.0 识别@supports但不识别clamp()，导致 fallback 被跳过 - 微信 X5 内核早期版本解析不稳定，同样建议加 fallback，别赌兼容性
真正难的不是写出 clamp()，而是确认它在 320px、768px、1440px 三个关键宽度下，computed 样式里的像素值是否平滑过渡；以及确保父容器宽度撑开、没被 max-width 或 overflow: hidden 截断计算上下文——这些细节一漏，整个流式就失效了。
