clamp() 比 media query 更适合响应式字号，因其支持最小值—首选值—最大值的连续平滑过渡，避免断点跳跃；需按设计稿基准反推参数，统一用 px 更稳妥，禁用 em 和纯百分比，慎用于正文等对可读性敏感的场景。
clamp() 为什么比 media query 更适合响应式字号
因为 clamp() 能在单个声明里完成「最小值—首选值—最大值」的连续过渡，避免媒体查询断点跳跃导致的文字大小突变。它不是替代 media query，而是补足了「区间内平滑缩放」这个长期缺失的能力。
常见错误现象：用 vw 单独做字号（比如 font-size: 4vw;），结果小屏上文字过小、大屏上又过大，根本不可控。
- 使用场景：标题、卡片标题、按钮文字等需要随视口宽度自然缩放但又必须保底/封顶的文本
-
clamp()三个参数必须是同单位（都用px、都用rem或混用带计算的em/vh，但不能px和%混） - 性能影响几乎为零——它是 CSS 原生函数，浏览器直接解析，不触发重排
怎么写一个真正可用的 clamp 字号
别抄网上那些「clamp(1rem, 2.5vw, 1.5rem)」的万能模板。实际要根据设计稿基准和目标设备范围反推数值。
假设设计稿宽 375px（iPhone SE），标题字号 20px；目标最大屏宽 1440px，字号上限 32px；中间用线性比例过渡：
立即学习“前端免费学习笔记（深入）”；
h1 {
font-size: clamp(20px, 16px + 0.28vw, 32px);
}
说明：16px + 0.28vw 是从 375px 到 1440px 区间拟合出的斜率表达式（可用工具如 clamp.darrenbachan.com 辅助生成）。
- 参数差异：第一个值是下限（小屏保底），第三个是上限（大屏封顶），中间那个才是「理想值」，它可含单位混合计算，但不能是纯百分比或 em（除非上下文明确）
- 容易踩的坑：把
min设太小（如12px），iOS Safari 在高倍屏下可能渲染模糊；建议下限不低于14px（iOS 可读性底线） - 兼容性：Chrome 88+、Firefox 79+、Safari 14.1+ 支持；旧版 Safari 需加
-webkit-clamp()前缀（但已基本可忽略）
和 rem/vw 混用时要注意什么
很多人想让 clamp() 和根字体挂钩，比如「在 1rem=16px 基础上动态缩放」。可以，但必须显式换算，不能指望浏览器自动理解。
错误写法：font-size: clamp(1rem, 1.5rem, 2rem); —— 这等于固定三档，毫无响应性。
正确思路：把 rem 当作单位容器，数值仍需按像素逻辑计算：
html { font-size: clamp(14px, 4vw, 18px); }
h1 { font-size: clamp(1.25rem, 1.5rem + 0.1vw, 2rem); }
- 注意：第二行里的
1.5rem + 0.1vw实际是24px + 0.1vw（假设根字号为 16px），所以必须确保根字号本身也是响应式的，否则中间项会失准 - 更稳妥的做法：统一用
px写clamp()，再用rem控制其他间距——避免嵌套响应带来的不可预测性 - 不要在
clamp()里用em，它会相对于父元素字号计算，极易失控
哪些地方不该硬套 clamp()
正文段落、表格单元格、表单输入框内的文字——这些内容对可读性敏感，且用户可能主动缩放页面。硬套 clamp() 会让用户缩放失效或产生意外截断。
- 使用场景限制：只推荐用于「视觉层级明确、尺寸变化不影响信息密度」的元素，比如
h1～h3、banner 标题、卡片主文案 - 无障碍影响：如果
clamp()导致小屏下文字小于 16px，配合系统「更大字体」设置时可能进一步缩小，破坏可访问性 - 真正复杂的响应逻辑（比如横竖屏切换、折叠屏多窗口），还是得靠 JS 监听
resize或matchMedia，clamp()不是银弹
最常被忽略的一点：clamp() 的「首选值」不是随便估的，它决定了整个区间的缩放斜率。没算好这个值，响应式就只是看起来动了而已。
