最常见失效原因是误用100%而非100vw：width: min(100%, 768px)实际取父容器宽度，非视口；应改用width: min(100vw, 768px)并注意100vw含滚动条宽度问题。
width: min() 为什么设了却没生效
最常见的情况是误用 100% 当作视口基准：写成 width: min(100%, 768px) 看似限制了宽度，实际它取的是父容器的 100%，不是屏幕宽度。当父容器宽 500px，结果就是 500px；父容器宽 1200px，结果就是 768px——这根本不是流式控制，只是被动跟随父级。
✅ 正确做法是锚定视口：width: min(100vw, 768px)。小屏（如 375px 宽）取 375px，大屏（如 1920px）取 768px，才真正实现“小屏自适应、大屏封顶”。
-
100vw包含滚动条宽度，可能导致横向溢出；可改用100dvw（Chrome/Firefox 支持，Safari 16.4+），或加overflow-x: hidden补救 - 行内元素（如
<span></span>）不支持width，必须先设display: inline-block或display: block - Flex 子项若未设
flex-basis，百分比可能按 0 计算，导致min(50%, 300px)取到0px
max() 控制最小宽度时别和 min-width 混用
max() 是属性值计算阶段的函数，min-width 是盒模型层级的约束，二者作用时机和范围完全不同。比如想让卡片“至少占视口一半，但不超过 600px”，不能写：
width: 50%; min-width: 50vw; max-width: 600px;
这种写法语义混乱，且在 flex 压缩等场景下容易失效。
立即学习“前端免费学习笔记（深入）”；
- ✅ 推荐直接用函数：
width: max(50vw, min(100%, 600px))—— 先取上限，再保下限 - ❌ 不要试图用
min-width: max(300px, 20vw)：语法合法，但浏览器会忽略（min-width不接受函数值） - ⚠️ 单位混用安全：
max(1rem, 16px, 5vw)浏览器会统一转换单位后比较，无需手动换算
嵌套 min/max 实现区间逻辑，但别过度
min() 和 max() 可嵌套，等价于 clamp()，比如 width: max(280px, min(80vw, 400px)) 就是典型的“280–400px 区间弹性宽度”。但它不是万能替代：
- Safari 15.2+ 支持
min()/max()，但clamp()要 Safari 15.4+；若需兼容旧版 Safari，拆解更稳妥 - 多层嵌套（如
min(max(200px, 30%), min(90%, 800px))）可读性差，调试困难，建议只在必要临界点切换时使用 - 函数结果是静态的：窗口 resize 会触发重解析，但函数本身不监听变化；依赖
vw时，iOS Safari 地址栏收起/展开可能漏重算（iOS 16+ 已修复）
移动端真正在意的三个细节
写完 min()/max() 不代表万事大吉，移动端有几个容易被跳过的硬伤：
-
100vw在有垂直滚动条时会多出 ~17px，导致横向滚动；100dvw是更干净的替代，但 iOS Safari 目前仍不支持，得靠overflow-x: hidden或 JS 临时修正 - 字体类属性（如
font-size）用max(16px, 2.5vw)比纯2.5vw更鲁棒——系统开启“更大字体”时，px部分仍兜底 - 不要在
min()里嵌calc()（如min(calc(100% - 20px), 600px)）：旧版 Chrome（≤98）支持不稳定，优先用clamp()或预计算为固定值
真正难的不是写出 min(100vw, 768px)，而是意识到它只在 CSS 计算那一刻取值，之后的一切——滚动条出现、地址栏隐藏、用户缩放、根字体变更——它都不会自动响应。你得提前想好这些边界怎么兜住。
