clamp()字体不动的根本原因是preferred值未落在min和max之间，如2.5vw在375px下仅约9.4px，低于min:16px，浏览器取min值属正确行为。
clamp() 能实现平滑缩放，但直接套用 clamp(16px, 2.5vw, 24px) 大概率失效——小屏字太小、大屏卡死、横屏跳变，根本原因不是函数有问题，而是 preferred 值没落在 min 和 max 之间。
为什么写了 clamp() 字体却不动？
常见现象：iPhone SE（375px）上字体始终是 16px，拖动窗口也无变化；iPad 上突然卡在 24px 不再增长。
- 根本不是浏览器不支持，而是
2.5vw在 375px 下 ≈ 9.4px，低于min: 16px，浏览器直接取 min 值——这是正确行为，不是 bug - 用 DevTools 查看该元素的
computed font-size，如果数值完全不随视口宽度变化，说明preferred始终未进入区间 - 反推合理系数：想在 375px 达到 16px，需
16 ÷ 375 × 100 ≈ 4.27vw，实际可取4vw；若想在 414px 达到 18px，则用18 ÷ 414 × 100 ≈ 4.35vw - 别信“通用系数”，不同设计稿基准不同：正文常用
clamp(1rem, 3.8vw, 1.25rem)，标题可用clamp(1.5rem, 5.2vw, 2.5rem)，必须按项目实测
clamp() 的三个参数单位怎么配才不出错？
单位混用是静默失效的高发区，比如 clamp(1rem, 2em, 2rem) 或 clamp(16px, 2rem, 24px)，浏览器会整个忽略该声明。
- 优先全用
rem：配合html { font-size: 100%; }，能响应系统字号放大（如 iOS「更大字体」），可访问性更好 - 全用
px最可控，适合对像素级精准有要求的场景，但绕过系统设置 -
preferred必须含动态单位：vw最常用，calc(1rem + 0.5vw)更稳妥，避免纯vw在极小屏下跌破 min - 绝对不要混写：
clamp(14px, 2.5vw, 1.5rem)是无效的——单位不可比，整条声明被丢弃
父容器窄、Flex 子项、侧边栏里 clamp() 失效怎么办？
vw 永远基于视口宽度计算，和元素实际渲染宽度无关。一个 200px 宽的 sidebar 里写 font-size: 4vw，在 1920px 屏幕上就是 76.8px，显然失控。
- 先检查 computed 样式中该元素的
width：如果不是接近视口宽度，说明父容器截断了上下文 - Flex/Grid 子项加
flex: 1或width: 100%强制撑开；移除flex: 0 0 auto、max-width、overflow: hidden等限制 - 真要按容器缩放，改用
cqw（容器宽度单位）：font-size: clamp(1rem, 2.5cqw, 1.5rem)，但要求父容器有明确width（非fit-content） - 窄区域（导航菜单、弹窗按钮）慎用
vw，改用rem/em+ 媒体查询兜底更稳
旧版 Safari 和安卓 WebView 怎么 fallback 才不白忙？
iOS 13.0–13.3、部分国产安卓 WebView 会静默忽略整条 font-size: clamp()，回退到浏览器默认 16px，排版直接崩。
- 必须前置降级：先写
font-size: 1.25rem;，再覆盖font-size: clamp(1rem, 4vw, 1.5rem);，CSS 解析器天然兼容 - 别用
@supports (font-size: clamp(0, 0, 0))包裹——它在不支持的环境里根本不会生效，且部分构建工具（如 PostCSS）可能错误编译 -
line-height要同步适配：始终用无单位值，如line-height: 1.4，它是相对于当前font-size的倍数，天然联动 - 测试重点不是“能不能用”，而是“fallback 后是否仍可读”：降级值得在 iPhone SE 和 iPad 上都肉眼验证
真正难的不是写出 clamp()，而是让 preferred 在真实设备宽度范围内稳定浮动——这需要你亲手拖动 DevTools 视口、查 computed 值、反推系数，而不是复制粘贴示例代码。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
