max()设下限、min()设上限比clamp()更轻量可控，但需单位一致且不能替代媒体查询；max(16px,2.4vw)保底防过小，min(2rem,5vw)限顶防过大，混用或依赖动态值易失效。
直接说结论：用 max() 设下限、min() 设上限，比 clamp() 更轻量且更可控；但两者不能混用单位，也不能替代媒体查询处理结构性变化。
为什么 max() 是字体最小尺寸的可靠选择
浏览器在计算 font-size: max(16px, 2.4vw) 时，会实时比较两个值：当视口窄到 2.4vw 小于 16px（比如在 375px 宽屏上，2.4vw ≈ 9px），就取 16px；宽到足够大时（如 1200px 屏，2.4vw ≈ 28.8px），就取 2.4vw。这能确保文字始终可读，不会因缩放失效或被用户系统字号覆盖而过小。
- 必须用同类单位：两个参数都得是长度单位（
px、rem、vw等），不能混入%或无单位数字 - 避免写成
max(1rem, 16px)：不同基准（根字体 vs 绝对像素）在高DPI屏或用户缩放下可能行为不一致，推荐统一用px或统一用rem - 它不插值，只做“保底”——适合你只需要守住下限、其他交给布局或设计系统的情况
min() 控制字体最大尺寸的实际效果
min() 常被误认为“限制最大值”，但它真正做的是「选最小的那个」。比如 font-size: min(2rem, 5vw)，在小屏上 5vw 很小（375px × 5% = 18.75px），所以取它；大屏上 5vw 变大（1920px × 5% = 96px），而 2rem 通常是 32px，此时就取 2rem。也就是说，它天然实现了“放大到某点就停住”的效果。
- 别指望它和
max()对称使用：比如font-size: min(2rem, max(1rem, 3vw))虽然语法合法，但逻辑绕、调试难，多数场景不如直接上clamp() - 注意视口单位精度：
vw基于整个视口宽度，如果元素在窄容器内（比如 sidebar），实际可用空间远小于视口，这时vw值会偏大，导致字体撑出容器 - 移动端 Safari 对
min()在font-size上的支持稳定，但 iOS 15 以下需测试是否触发重排抖动
常见错误：单位错配与计算时机陷阱
最典型的失败案例是 font-size: max(16px, 2em) ——2em 依赖父级 font-size，而父级本身又可能由 max() 或 clamp() 动态生成，形成循环依赖，最终浏览器按初始值（通常是 16px）计算，结果就是静态的 32px，完全失去响应性。
立即学习“前端免费学习笔记（深入）”；
- 所有参与
min()/max()的值，必须是浏览器能在样式计算阶段独立求值的，不能依赖运行时布局（如fit-content、ch单位在某些上下文中不可靠） - 不要在同一个属性里混用
calc()和min()的嵌套，例如font-size: min(calc(1rem + 1vw), 2.5rem)，部分旧版 Chrome 会降级为1rem - 如果用了 CSS 自定义属性，确保 fallback 值类型匹配：
--fs-base: max(16px, 2.2vw); font-size: var(--fs-base, 16px);中的16px必须和前面单位一致
真正难的不是写出这行代码，而是判断该用 max() 还是 min()，或者干脆该退回到媒体查询——比如标题层级需要阶梯式跳跃（h1/h2/h3 各自断点不同），这时候函数反而增加维护成本。单位一致性、计算上下文、以及是否真需要“连续变化”，才是决定用不用的关键。
