min() 和 max() 是手动定义响应边界的 CSS 函数，需配合 vw/rem/em 或媒体查询使用；单独用 % 无效，正确写法如 width: min(100vw, 768px)；clamp() 更简洁，但 min/max 支持多参数与嵌套；IE 不支持，需回退；慎用单位混用与深层嵌套。
min() 和 max() 在 CSS 中不是“自动适配”，而是手动定义响应边界
它们本身不感知屏幕尺寸变化，必须配合 vw、rem、em 或媒体查询变量一起用，否则只是静态计算。常见错误是写成 width: min(100%, 800px) —— 这在所有设备上都固定为 800px（因为 100% 是父容器宽，非视口），根本没流式效果。
真正起作用的组合是：用相对单位制造弹性，再用 min()/max() 卡死上下限。比如限制字体在小屏不缩太小、大屏不撑爆容器。
-
min()适合设“最大值”：防止元素过大（如font-size: min(4rem, 8vw)） -
max()适合设“最小值”：防止元素过小（如padding-inline: max(1rem, 5vw)） - 三值写法也合法：
clamp(1rem, 2.5vw, 2rem)更简洁，但min/max支持任意数量参数，且可嵌套（如min(100%, max(320px, 50vw))）
用 min() 控制宽度上限时，别混淆 % 和 vw
写 width: min(100%, 768px) 看似合理，实则失效：当父容器宽 500px 时，100% = 500px，min 取 500px；当父容器宽 1000px 时，100% = 1000px，min 取 768px —— 表面像限制了，但实际依赖父级，不是流式。
要真按视口控制，得用 vw：width: min(100vw, 768px)。这时小屏（375vw）取 375px，大屏（1920vw）取 768px，才符合预期。
立即学习“前端免费学习笔记（深入）”；
- 注意
100vw包含滚动条宽度，可能造成横向溢出；可用100dvw（如果支持）或加overflow-x: hidden补救 - IE 完全不支持
min/max，需提供width: 768px回退（现代项目通常可忽略） - 不要在
min-width里嵌min()：浏览器会忽略，应直接用min-width: max(320px, 20vw)
max() 配合 calc() 解决“最小字号+弹性缩放”难题
设计师常要求：“字号不能小于 14px，但要在 320px–1920px 视口间线性缩放”。纯 clamp() 能做，但老项目若只支持 min/max，就得绕一下。
核心思路：先用 calc() 做线性插值，再用 max() 设下限。例如：
font-size: max(14px, calc(12px + 0.12vw));
这里 calc(12px + 0.12vw) 在 320px 时≈15.8px，1920px 时≈35px；max(14px, ...) 确保再小的屏幕也不低于 14px。
- 系数 0.12 来自 (35−14) / (1920−320) ≈ 0.013125，单位是
px/vw，需换算成vw值（即 ×100） - Chrome 110+ 支持
font-size: max(14px, 2.5vw)直接写，更干净，但 Safari 15.4–16.3 有渲染抖动，建议加transform: translateZ(0)强制硬件加速 - 避免在
max()里混用单位类型（如max(1rem, 16px)），部分浏览器解析不一致
嵌套 min/max 容易触发重排和兼容性断层
写 width: min(100%, max(320px, 25vw)) 看似聪明，但 Safari 15.6 之前会把整个表达式当无效值丢弃；Chrome 98–104 对多层嵌套的计算精度也有偏差（尤其涉及 % 和 vw 混用时）。
更稳的写法是拆开：用 min() 控制整体上限，用媒体查询或 clamp() 处理内部逻辑。
- 嵌套层级别超两层，比如
min(100%, max(320px, min(50vw, 768px)))—— 可读性差，调试困难，且无实际收益 - 移动端 Safari 对
min()内含em的计算有延迟，首次渲染可能闪动，建议统一用rem或vw - 服务端渲染（SSR）场景下，
min/max不会被预计算，首屏仍依赖客户端样式注入，别指望它改善 LCP
最麻烦的不是语法，是设计需求本身经常模糊：“流式”到底指缩放比例、断点切换，还是内容自适应。min 和 max 只是工具，得先想清楚边界在哪，再动手填数值。
