min()控制上限、max()控制下限，二者须含至少一个相对单位才响应式；纯像素值组合退化为静态值；clamp()更安全明确，推荐替代嵌套min/max。
直接说结论：min() 控制上限，max() 控制下限，二者必须至少含一个相对单位（如 vw、%、rem）才真正响应式；纯像素值组合会退化为静态值，失去伸缩意义。
为什么 width: min(90%, 1200px) 比 max-width: 1200px 更早介入计算
浏览器解析 CSS 属性值时，min() 是在「计算值（computed value）阶段」就完成比较并固定结果的；而 max-width 是布局阶段才起作用的约束条件。这意味着：
- 当父容器被
flex压缩或grid分配了窄轨道时，width: min(90%, 1200px)仍按当前上下文实时取较小值，比如父宽仅 600px → 结果是540px - 但
width: 90%; max-width: 1200px在父宽 600px 时也得 540px，可一旦父容器本身被设为width: 0或未定义，90% 就算成 0，max-width完全不生效 - 调试时务必看「Computed」面板里的最终值，而不是「Styles」里写的原始表达式——因为
min()和max()的结果是不可逆的静态值
font-size: max(16px, 2.5vw) 为何不能写成 font-size: 2.5vw; min-width: 16px
min-width 只作用于宽度属性，对 font-size 完全无效，这类写法会直接被浏览器忽略。正确做法是：
- 下限兜底必须用
max()，且至少一个参数是绝对单位（如16px），另一个是相对单位（如2.5vw） - 用户开启系统「更大字体」设置时，
2.5vw仍按视口算，但max(16px, 2.5vw)至少保底 16px，比纯vw更鲁棒 - 避免写
max(1rem, 2.5vw)—— 若父元素font-size动态变化（如用户缩放），1rem基准漂移，比较结果不稳定；优先用px+vw组合
嵌套使用 min(max(), ) 容易漏掉中间态，clamp() 更安全
想实现「最小 280px、理想 80vw、最大 400px」的宽度，别手写 min(max(280px, 80vw), 400px)。原因：
立即学习“前端免费学习笔记（深入）”；
- 可读性差，调试时容易看错括号层级
- 语义模糊：到底是先保下限再截上限，还是反过来？实际执行顺序是先算
max()再算min()，但人脑不易校验 -
clamp(280px, 80vw, 400px)等价且明确，Safari 15.4+ 已完整支持，旧版 Safari（15.2–15.3）可用max(280px, min(80vw, 400px))降级 - 注意：所有三个参数单位不必一致，但混合单位（如
clamp(1rem, 4vw, 24px)）在部分旧 Chrome（≤98）中可能解析失败，建议统一用px或vw
@supports 检测和降级必须写在关键样式外层
不能只给某条规则加 @supports，否则老浏览器会跳过整块样式。正确姿势：
- 用
@supports (width: min(0px, 0px))包裹整个响应式容器规则集 - 内部写降级方案，比如 fallback 用
max-width+ 固定width，而非留空 - 特别注意：IE 全系不支持，Firefox 79+ 才完整支持
clamp()，iOS Safari 13.4+ 才开始支持min()/max() - 不要在
@keyframes中用min()—— 部分 Android WebView 会直接跳过该帧，导致动画断裂
最常被忽略的点是：min() 和 max() 的结果是静态的，它们不监听 resize，也不重计算，只是在初始渲染或重排时算一次。如果你依赖 JS 动态改父容器尺寸又期望子元素自动响应，得靠触发重排（比如改 class 或强制 offsetHeight），而不是指望 min/max 自动刷新。
