min()取参数最小值而非设最小宽度，正确用法是width: min(100%, 800px)；max()需确保动态值在常见视口下能超越固定值，推荐优先使用clamp()。
min()不是“设最小宽度”，而是选最小值
很多人写 width: min(300px, 100%) 想让元素“至少300px”，结果小屏下直接固定成300px，失去响应性。这是因为 min() 真实行为是：在所有参数中取数值最小的那个参与计算。而 300px 在绝大多数视口下都小于 100%（比如手机上 100% ≈ 375px，但 300px ），所以永远选 <code>300px。
正确用法是把动态值放前面、上限放后面：width: min(100%, 800px)——意思是“最多占满父容器，但绝不超800px”。这时小屏取 100%，大屏到临界点后锁定为 800px。
- 单位必须兼容：不能混用
min(100, 500px)，会整个声明失效 - 参数顺序不影响结果，但语义上建议把相对单位（
%、vw）放前，便于理解意图 - 别单独依赖
min()控制宽度：它不阻止父容器收缩导致的溢出，得配max-width: 100%才稳
max()要防“下限失效”，关键看单位是否真能变大
max() 常被误用于字体或内边距，比如 font-size: max(16px, 2vw)。这看似合理，但若视口太窄（如320px宽），2vw = 6.4px，远小于 16px，结果永远是 16px——等于退化成静态值，没起到“随屏变大”的作用。
真正生效的前提是：至少一个参数在常见视口范围内能超过另一个。例如 max(1rem, 2.5vw)，在桌面端 2.5vw 很快超过 1rem（假设根字号16px，则需视口>640px），才体现响应性。
- 避免用
max()控制margin：部分 Android WebView 对负外边距+max()解析异常，整条声明可能被跳过 - 别和
min-width混用同一属性：两者作用层级不同，max()是计算函数，min-width是布局约束，冲突时后者优先级更高 - 想保底又弹性？优先写
clamp(1rem, 2.5vw, 1.5rem)，比max(1rem, min(2.5vw, 1.5rem))更直观且兼容性更好
嵌套 min/max 模拟 clamp() 时，浏览器先算内层
当需要三段式控制（比如字体：小屏1.2rem、中屏按vw增长、大屏不小于1.5rem），你会写 font-size: max(1.2rem, min(3vw, 1.5rem))。这里解析顺序固定：浏览器先执行 min(3vw, 1.5rem)，再拿结果和 1.2rem 做 max()。
这意味着如果 3vw （比如视口min() 先产出一个小值，max() 再把它拉回 1.2rem——逻辑成立，但可读性差。
- 旧版 Safari（iOS 13.4之前）不支持嵌套函数，
min(calc(100% - 2rem), 400px)会直接失败 - 上线前务必用
@supports (font-size: min(0px, 0px))包裹，给不支持的浏览器降级方案 - Grid 容器中用
minmax()（注意不是min()！）定义轨道尺寸，二者命名相似但语法和用途完全不同
图片和容器最常踩坑：漏掉 max-width: 100%
给图片写 width: min(100%, 600px) 看似完美，但在 Flex 或 Grid 容器里经常失效——因为这些布局模式下，子项默认不继承父容器的 max-width 限制，min() 计算出的值可能被父容器拉伸溢出。
真正可靠的写法是双保险：width: min(100%, 600px); max-width: 100%;。前者设计算上限，后者强制布局约束。
- 内联元素（如
<img>）设width前记得加display: block，否则无效 - 居中图片别只靠
text-align: center，要加margin: 0 auto配合display: block - 如果父容器用了
container-type: size，min()中的%将基于容器而非视口，行为突变，需重新验证
实际项目里，min() 和 max() 的边界感很微妙：它们不改变布局流，只是参与单个属性的值计算；一旦涉及多层嵌套、容器查询或旧浏览器，就容易漏掉兜底逻辑。最常被忽略的是——你写的那个“动态单位”，在目标设备的真实视口下，到底有没有机会真正大于/小于你的固定值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
