vw单位实现字体响应式缩放需配合clamp()或媒体查询设上下限，正文宜用更小vw值；兼容旧安卓需fallback；JS动态调rem更可控；禁用zoom/scale；字体加载用font-display:swap防跳变。
用 vw 单位直接响应视口宽度
文本随分辨率变化，本质是让字体大小随屏幕宽度缩放。vw（viewport width）单位最直接：1vw 等于视口宽度的 1%。设 font-size: 4vw，屏幕宽 1000px 时字号就是 40px，宽 500px 时变成 20px。
常见错误是只写 vw 忽略最小/最大限制——小屏下可能缩到 12px 难以阅读，大屏又可能撑满半屏。必须配合 clamp() 或媒体查询兜底。
-
font-size: clamp(16px, 4vw, 32px)是目前最稳妥的写法：强制字号在 16–32px 之间，中间用4vw平滑过渡 - 不要单独依赖
vw做标题 + 正文统一缩放，正文通常需要更保守的缩放比例（比如2.5vw），否则小屏阅读体验断崖下跌 - 部分安卓 WebView 对
clamp()支持滞后，若需兼容 Android 6–9，得 fallback 到@media查询
rem 配合根元素动态调整更可控
比起直接操作 font-size，用 JavaScript 动态改 document.documentElement.style.fontSize 再配合 rem，能实现更精细的断点控制和逻辑干预（比如检测是否横屏、是否启用了系统大字体）。
典型场景是适配 iPad 横竖屏切换，或防止用户系统级放大导致文字溢出容器。
立即学习“前端免费学习笔记（深入）”；
- 基础做法：
document.documentElement.style.fontSize = window.innerWidth / 375 * 16 + 'px'（以 iPhone 6/7/8 的 375px 为基准，16px 为 1rem） - 必须监听
resize和orientationchange，但别用debounce过度延迟——字体重排是低成本操作，卡顿感主要来自 layout thrashing，不是计算本身 - 注意 Safari 在地址栏收起/展开时也会触发
resize，导致字号抖动，可加if (Math.abs(window.innerHeight - lastHeight) > 50)过滤
避免用 zoom 或 transform: scale()
这两个看似能“整体缩放文本”，实际会破坏布局流、截断阴影、错位定位元素，且对屏幕阅读器不友好。
典型错误现象：按钮点击热区没跟着缩放、position: fixed 导航栏在滚动时闪烁、box-shadow 变虚或消失。
-
zoom是非标准属性，Chrome 已明确标记为 deprecated，Firefox 完全不支持 -
transform: scale()会让元素脱离文档流，父容器无法正确感知其高度，margin和padding也不再按缩放后尺寸计算 - 如果真要全局缩放（比如网页阅读模式），优先用
html { font-size: ... }+rem，而非视觉欺骗手段
字体加载期间的尺寸跳变怎么稳住
自定义字体（尤其是 woff2）加载完成前，浏览器会先用备用字体渲染，等下载完再重绘——造成文字突然变大/变小，影响阅读连贯性。
这不是分辨率问题，但常被误认为是“缩放不稳定”。关键在字体加载策略和占位控制。
- 用
@font-face的font-display: swap，确保文字始终可见，只是字体不同；别用block或optional（后者可能导致小屏下永远不加载） - 给文本容器设置
min-height或基于行高的padding，预留足够空间，避免重排引起其他元素跳动 - 慎用
font-size-adjust：它只在字体回退时保持 x-height 一致，对响应式缩放本身无作用，且 Safari 支持有限
真正难的不是让字号变，而是变的时候不破坏行高、不挤占空间、不干扰可访问性。很多“响应式字体”方案在 iOS VoiceOver 下会读错字号层级，这点容易被忽略。
