clamp()在移动端字体控制中常“不动”，是因为它仅做数值裁剪：当首选值（如2.5vw）在当前视口下低于min（如16px）或高于max时，直接卡在边界，不插值、不响应；例如iPhone SE（320px）下2.5vw=8px＜16px，恒取16px。
clamp()在移动端字体控制中为什么经常“不动”
因为clamp()不是自动响应式开关，它只做数值裁剪——当首选值（第二参数）在当前视口宽度下算出来小于min或大于max，就直接卡死在边界上，不会“动”。比如clamp(16px, 2.5vw, 24px)在 iPhone SE（320px）下，2.5vw = 8px，低于16px，结果永远显示16px，看起来像没生效。
移动端最小值怎么设才不糊
iOS Safari 默认强制最小字体为16px（可读性限制），Android Chrome 也有类似策略。设低于这个值的min（如14px）可能被浏览器忽略或触发渲染异常。
-
min建议用1rem（前提是:root设了font-size: 16px），或直接写16px - 避免用
0.875rem这类换算值，除非你确认所有用户设备的根字号都是16px - 如果项目支持系统字体缩放（如 macOS “更大字体”），
min必须用rem，否则缩放后可能跌破可读下限
首选值用vw时系数怎么选
盲目套2vw或4vw极易翻车：小屏下太小、大屏下太快触顶。关键是要反推——基于你设计稿里两个关键断点来算斜率。
- 假设你希望：375px宽时字号=18px，1200px宽时=24px → 斜率 = (24 − 18) / (1200 − 375) ≈ 0.0073 → 推荐写成
clamp(16px, calc(15.2px + 0.0073 * 100vw), 28px) - 更常用且安全的写法是
clamp(16px, 2.2vw + 0.5rem, 24px)，加固定偏移防止小屏塌陷 - 测试时拖动 DevTools 响应式面板到
320px、375px、414px，看 computedfont-size是否真在变，而不是一直卡在min
旧版 iOS Safari 里 clamp()失效怎么办
Safari 13.1+ 才原生支持clamp()，但 iOS 14.0–14.4 的 WebKit 存在 vw 解析延迟 bug：首屏加载时vw算出来是 0 或异常值，导致整个clamp()被静默丢弃。
立即学习“前端免费学习笔记（深入）”；
- 必须加降级声明：
font-size: 1.125rem; font-size: clamp(1rem, 2.5vw, 1.5rem); - 删掉所有嵌套写法，比如不要把
clamp()放在@media块里，也不要和var(--size)混用 - 检查
<meta name="viewport">是否完整，缺initial-scale=1会导致vw基准错乱 - 真机调试比模拟器可靠，微信内置 WebView 和 Samsung Internet 也常有类似问题，不能只信桌面 Chrome
真正容易被忽略的是：移动端的“视口宽度”受viewport meta 控制，而用户手势缩放、系统字体设置、第三方浏览器（如 UC、QQ 浏览器）的兼容层，都会让vw行为偏离预期。别只盯着clamp()本身，先确保基础环境可信。
