min()和max()在只需单向限制时更合适，如容器宽度封顶或字体保底可读，配合相对单位（vw、%）实现响应式，比媒体查询简洁易维护。
min() 和 max() 什么时候比媒体查询更合适
当你只需要「单向限制」时，min() 或 max() 就够了——比如容器宽度不能超过 1200px，但可以随视口缩小；又或者字体最小不能小于 1rem，但可以随视口变大。这种「一端固定、一端流动」的场景，min() 和 max() 比写 @media 简洁得多，也更易维护。
常见错误是把多个绝对值塞进 min()，比如 width: min(300px, 500px, 800px) ——这等价于 width: 300px，毫无响应意义。真正有效的用法必须至少含一个相对单位（如 vw、%）：
-
width: min(100%, 600px)：窄屏占满，宽屏封顶 600px -
font-size: max(1rem, 2.5vw)：小屏保底可读，大屏随视口放大 -
padding-inline: min(16px, 5vw)：边距不随小屏缩得过小
注意：min() 和 max() 支持任意数量参数，但只有混用相对/绝对单位才有实际响应效果；纯绝对值列表只是静态取值，没意义。
clamp() 的三个参数到底怎么填才不翻车
clamp(min, preferred, max) 不是「最小、中间、最大」的线性插值，而是「下限、理想值、上限」的裁剪逻辑。浏览器先计算 preferred，再把它卡在 min 和 max 之间。关键约束是：三者单位必须兼容（比如都可用 px 或都含 vw），否则整条声明会被忽略。
立即学习“前端免费学习笔记（深入）”；
典型踩坑点：
- 把
preferred写成calc(1rem + 2vw)是合法的，但若混入em（如1rem + 1em），因em依赖上下文，部分浏览器会静默失效 - 旧版 Safari（iOS 13.0–13.3）不支持
clamp()在@media块内使用，也不支持和var(--size)直接组合 -
line-height用clamp()时，务必用无单位值（如1.4），否则会和字体单位冲突
推荐写法：font-size: clamp(1rem, 1.2rem + 0.3vw, 1.8rem) —— 这样既保最小可读性，又让中段有平滑增长，上限防过大破坏行高。
用 clamp() 替代多断点媒体查询的真实成本
设计师给的边距需求：手机 16px、平板 48px、桌面 120px，加一个超大屏 160px。用媒体查询要写 4 个断点；用 clamp() 只需一行：padding-inline: clamp(16px, 10vw + 8px, 160px)，但前提是算准线性关系。
怎么推导那个 10vw + 8px？找两个关键点：在 640px 时要 ≈ 48px，在 1024px 时要 ≈ 120px。解方程 a × 640 + b = 48 和 a × 1024 + b = 120，得 a ≈ 0.1875（即 18.75%），换算成 vw 就是 18.75vw，但这样斜率太陡。更稳妥的做法是用在线工具（如 min-max-calculator）生成带缓冲的表达式，例如 clamp(16px, -12px + 3.2vw, 160px)。
注意：这种推导依赖像素级对齐，如果设计稿本身是弹性网格或基于 rem，直接套用 px 值可能在高 DPR 设备上偏小。建议统一用 rem 或 px，别混用。
Clamp() 在真实项目里最容易被忽略的兼容性细节
不是所有浏览器都“开箱即用”支持 clamp()。Safari 13.1+ 才开始支持，但 iOS 13.4 之前的 WebKit 有解析 bug：当 clamp() 出现在 @supports 或嵌套自定义属性中时，可能被丢弃而不报错。
实操建议：
- 降级写法必须用两行：
padding-inline: 48px; padding-inline: clamp(16px, 3.2vw, 120px);—— 第一行是 fallback，第二行覆盖 - 避免
font-size: clamp(var(--min), var(--pref), var(--max))，改用 JS 注入或构建时展开为具体数值 - 如果用 PostCSS 插件自动转译，确认它不把
clamp()错误地拆成min(max(...))—— 这种模拟在 Safari 13.0 下反而更不稳定
真正麻烦的不是函数本身，而是它把「数学推导」和「浏览器实现差异」绑在了一起：你得同时懂设计规范、像素换算、WebKit 行为，缺一不可。
