应使用 clamp() 配合 vw 和 rem 实现真响应式字体，避免纯 vw 导致小屏过小（如 iphone se 仅 6.4px）或大屏过大（如 4k 屏达 51.2px），同时兼顾系统字体缩放与横竖屏兼容性。
直接用 clamp() 配合 vw 和 rem，别写纯 vw 字体，也别只靠媒体查询硬切断点——前者在 iPhone SE 上能小到 6px，后者在断点之间是跳变，都不是真响应。
为什么纯 vw 字体在手机上常小到看不见
因为 1vw = 视口宽度的 1%。iPhone SE（320px 宽）上 font-size: 2vw 渲染出来只有约 6.4px，远低于可读下限（通常 ≥12px）。这不是 bug，是单位本身没设底线。
- 小屏风险：
320px × 2% = 6.4px；414px × 2% = 8.28px—— 都低于系统默认最小字号 - 大屏风险：
2560px × 2% = 51.2px，正文用这个值会撑爆行高和容器 -
vw不继承系统字体缩放设置，视力障碍用户调大系统字号时，vw字体完全无反应 - 旧版 Safari 在横竖屏切换时对
vw重绘有延迟，文字可能卡顿半秒
clamp() 三个参数怎么填才不翻车
clamp(min, preferred, max) 看似简单，但中间项写错就失去平滑意义。重点不在“写出来”，而在“测出来”。
- min 和 max 必须用固定单位（
rem或px），比如1rem和2.5rem；不能写clamp(12px, 2.5vw, 32px)然后指望它适配系统缩放——它不会 - preferred 必须含动态单位（如
2.5vw + 0.5rem），纯rem或纯px就退化成静态值 - 要模拟线性放大：先算设计稿基准（比如 375px → 16px，1920px → 24px），推导出 vw 系数，再套进
clamp() - 必须在真实设备上验证：320px 宽时是否 ≥12px？2560px 宽时是否 ≤28px？开了系统「更大字体」后是否还能正常阅读？
要不要用 JS 动态改 document.documentElement.style.fontSize
能跑通，但代价明显：首屏渲染时 JS 未执行，rem 字体全按浏览器默认 16px 渲染，布局可能闪动；resize 频繁触发重排，在低端安卓机上卡顿肉眼可见。
- SSR 或静态页首屏文字错乱概率高，尤其带骨架屏时更突兀
- 横竖屏切换瞬间，
window.innerWidth可能返回错误值（如 iOS Safari 地址栏收起前），导致根字号归零或跳变 - 现代 CSS 已支持
clamp()（Chrome 88+/Safari 14.1+/Firefox 79+），除非要严格匹配设计稿缩放曲线，否则没必要 JS 干预 - 如果必须用 JS，至少加节流 + 初始化 fallback：比如先设
:root { font-size: clamp(16px, 2.5vw, 24px); }保底，JS 加载后再接管
真正难的不是写出那行 font-size，而是想清楚：这个标题在 320px 宽的 iPhone SE 上最小不能低于多少像素，在 2560px 宽的 4K 屏上最大不能超过多少像素，以及用户开了系统「更大字体」后是否还能正常阅读——这些数值得从真实设备上量，不是凭感觉填进去的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
