结论：min()控制上限、max()控制下限，二者在属性解析阶段动态计算单个静态值，不监听变化；真正驱动弹性的是vw、%等相对单位。
直接说结论：min() 和 max() 不是“替代媒体查询的银弹”，而是用来在**单个属性值解析阶段动态选数**的工具——它们只管那一刻算出一个静态值，不监听缩放、不响应字体变化、也不驱动弹性；真正让尺寸动起来的，是 vw、% 这类相对单位。
什么时候该用 min() 而不是 max-width
min() 的不可替代性只出现在「上限依赖可变值」的场景。比如：
-
width: min(90vw, 1200px)：小屏取视口 90%，大屏卡死在 1200px，且父容器被flex压缩时仍按实时视口计算 -
width: 90%; max-width: 1200px：语义是“先设 90%，再截断”，但若父容器本身只有 400px，结果就是 400px，根本达不到“占满视口”的意图 - 写成
min(100%, 800px)很容易取到 0px——因为100%是相对于父宽，而父容器可能没设宽、或处于flex中未控flex-shrink，导致百分比基准为 0
max() 容易踩的单位陷阱
max() 对单位混用更敏感，尤其在旧环境里极易整条声明失效：
-
font-size: max(14px, 1.2rem)在 Firefox 75 之前会忽略14px，因为rem是相对单位，浏览器早期实现不统一转换逻辑 -
width: max(320px, 80%)是安全的——两个值单位虽不同，但浏览器能转成同单位比较；而max(1rem, 5vw)在 Android WebView 4.4–6.0 直接跳过整条规则 - 真要兜底最小尺寸，优先用统一单位：
padding-inline: max(1rem, 5vw)比max(16px, 5vw)更鲁棒（rem随根字体缩放，px不）
min() 和 max() 一起用，为什么常漏掉中间态
很多人想模拟 clamp() 效果，写成 max(14px, min(1.2vw, 24px))，但实际容易出错：
- 这个写法在 Safari 13.1 之前会退化为
14px（min()先算，但旧版不支持嵌套函数） - 调试时 computed 样式里看到的是最终数值，不是原始表达式，容易误判哪一层失效
- 更常见问题是“本想保底 + 限顶，却忘了中间值该由谁驱动”——
min()和max()只选极值，不提供弹性区间；真正起弹性作用的是中间那个值（如1.2vw），它必须是相对单位，否则整个逻辑退化为静态判断 - 上线前务必用
@supports (width: min(0px, 0px))包裹关键样式，给不支持的浏览器降级
真正难处理的不是函数本身，而是它和 vw、根字体、用户缩放之间的耦合——比如双指放大页面时，vw 值不变，但渲染尺寸变大，这时 min(100vw, 400px) 的 “400px” 就突然显得太小。这类问题没法靠 CSS 函数单独解决，得结合 <meta name="viewport"> 控制或 JS 监听 resize 补充调整。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
