结论：用 clamp() 实现响应式字体需确保中间值含可变单位且能在视口变化时突破边界，三参数单位统一、边界合理；否则退化为固定值或在旧 safari 中静默失效。
直接说结论：用 clamp() 实现响应式字体大小，关键不是套公式，而是让中间值真正“动起来”，且三参数单位一致、边界合理；否则它会退化成固定值，或在旧 Safari 里静默失效。
为什么 clamp(1rem, 2.5vw, 2rem) 在小屏没缩、大屏没涨
常见错误是把 preferred 当成“默认值”硬写一个固定数，比如 clamp(1rem, 1.5rem, 2rem) —— 浏览器一看：1.5rem 永远在 min/max 之间，直接取它，完全失去响应性。
真正起作用的前提是：中间值必须含可变单位（vw、vmin、calc()），且该值在某些视口下会低于 min 或高于 max，浏览器才会触发裁剪逻辑。
-
2.5vw在 375px 屏上 ≈ 9.4px，低于1rem（16px），所以实际取1rem—— 这不是 bug，是 clamp 的设计行为 - 但若你希望它在 375px 时刚好是 18px（1.125rem），就得反推系数：
18 / 375 = 0.048→ 写成4.8vw - 如果
4.8vw在 1440px 时飙到 69px（远超2rem），那说明max设低了，或系数过大
怎么写出不翻车的 clamp() 字体表达式
别从 “我要多大” 开始，先锚定两个典型宽度点，再线性换算。例如：希望在 480px 显示 20px，在 1200px 显示 28px。
斜率 = (28 − 20) / (1200 − 480) ≈ 0.0111，截距 = 20 − 0.0111 × 480 ≈ 14.7px → 但 14.7px + 0.0111vw 是非法语法，必须用 calc() 拆解：
font-size: clamp(16px, calc(14.7px + 0.0111 * 100vw), 28px);
更常用、也更易维护的写法是：
-
min用1.125rem（≈18px），保小屏可读底线 -
preferred用calc(1.125rem + 0.5vw)，比纯vw更平缓，避免小屏突降 -
max用2.5rem（≈40px），防止 4K 屏下文字撑爆容器 - 所有单位统一为
rem或全用px，禁止混用rem和em或%
为什么 iOS 13.3 及更早的 Safari 里 clamp() 像没写一样
这不是兼容性开关问题，而是 Safari 13.1–13.3 的 WebKit 存在解析缺陷：当 clamp() 出现在 @media 块内，或与 CSS 自定义属性（var(--size)）组合时，整条声明会被静默丢弃，不报错也不渲染。
实操避坑方式：
- 永远在
clamp()前加一行降级：font-size: 1.5rem;，不支持的浏览器自然 fallback - 禁用嵌套写法，如
font-size: clamp(var(--min), var(--pref), var(--max))—— 改为直接数值或 JS 注入 - 确保页面有正确
<meta name="viewport" content="width=device-width, initial-scale=1">，缺这个 Safari 加载初期可能无法正确解析vw - 测试时用真机，模拟器有时会掩盖渲染抖动或首次加载闪屏问题
clamp() 不是万能的，正文段落慎用
标题、卡片主文案、按钮文字适合 clamp()，因为它们需要视觉权重随屏幕自然浮动；但正文段落不行——字号变化会直接影响行高、字间距、行宽可读性，单靠 clamp() 调字体，反而导致小屏挤、大屏散。
真正稳的做法：
- 正文仍用
rem+ 媒体查询做 2–3 档阶梯调整（如1rem/1.125rem/1.25rem） - 配合
max-width: 65ch控制行长，比调字体更重要 - 若坚持用
clamp()，必须同步处理line-height：用无单位值（如1.4），它会随font-size缩放自动调整倍数 - 别在大量列表项或表格单元格里滥用
clamp()，尤其含vh时，可能触发频繁重排
最常被忽略的一点：clamp 的“平滑”是数学意义上的连续，人眼对小于 0.1rem 的变化基本无感；如果你的设计系统只定义了三档字号，强行用 clamp 反而增加不可控变量。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
