clamp() + vw 是最稳妥起点，但必须配 viewport meta 标签，否则自适应失效；单独用 4vw 会导致小屏过小、大屏过大、跳变及不响应系统字体设置。
直接用 clamp() + vw 是最稳妥的起点，但必须配 <meta name="viewport" content="width=device-width, initial-scale=1">，否则所有自适应逻辑全失效。
为什么 font-size: 4vw 单独写会出问题
它在小屏下缩得太狠：iPhone SE（375px 宽）时只有 15px，320px 屏更是掉到 12.8px，逼近 Chrome 强制渲染下限（12px），文字发虚；桌面端拉宽窗口又可能飙到 100px+，压垮布局。滚动或缩放时还会“呼吸式”跳变，打断阅读。更关键的是，它完全不响应系统字体放大设置（如 Windows 的“放大文本”设为 125%），损害可访问性。
这些现象不是偶然——是 vw 基于视口宽度、无视内容容器和用户偏好导致的必然结果。
clamp() 三个参数怎么填才不翻车
顺序固定：min、preferred、max，单位必须统一（别混用 px 和 rem），且 preferred 推荐用 vw 或 rem，禁用 em（会继承父级，链式放大风险高）。
-
font-size: clamp(14px, 2.5vw, 18px)：安全兜底，小屏不跌破14px，大屏不超18px - 设计稿基于 750px？可用
clamp(14px, 1.866vw, 18px)（因为750 × 1.866% ≈ 14），比硬套公式更直观 - 别写
clamp(12px, 4vw, 24px)：320px 屏下4vw = 12.8px已临界，2560px 屏则达102.4px，标题直接溢出
兼容性与降级必须手动加
clamp() 在 Safari 13.1+、Chrome 78+、Firefox 75+ 才稳定支持；旧版 Android WebView（6–9）完全不识别。不能指望浏览器自动 fallback。
正确做法是：
- 把降级规则写在前面：
font-size: 16px;，再跟font-size: clamp(...); - 或用
@supports包裹：@supports (font-size: clamp(1rem, 1vw, 1rem)) { ... } - 漏掉
<meta>标签？vw和clamp()全部按 980px 视口计算，根元素基准错乱，自适应彻底崩盘 - Safari 横屏时
vw基于总屏幕宽度（含状态栏），可用@media (min-aspect-ratio: 1/1)微调
真正难的不是写出那行 clamp()，而是判断要不要引入 JS：只有当你需要响应横竖屏切换、系统字体放大、DPR 变化或动态主题时，才值得动用 ResizeObserver 控制根字号；其余情况，纯 CSS 就够了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
