真正可用的 vw 字体适配方案是 html { font-size: clamp(16px, 4vw, 24px); }，辅以 -webkit-text-size-adjust: 100%、正确 viewport meta 及统一 rem 体系，缺一不可。
用 vw 直接设 font-size 会缩得太小
直接在 html 或 body 上写 font-size: 4vw; 看似简单，但实际中多数屏幕下文字会过小（比如 iPhone SE 的 375px 宽度下，4vw = 15px），而大屏又可能撑到 30px+，阅读体验断裂。这不是“适配”，是“乱缩”。
真正可用的方案是加一个基准值和合理区间限制：
-
html { font-size: clamp(16px, 4vw, 24px); }—— 浏览器原生支持，低于 16px 按 16px 显示，高于 24px 截断，中间线性响应 - 不支持
clamp()的老浏览器（如 IE、旧版 Safari）需配合 JS 回退，仅靠纯 CSS 无法安全兜底 -
vw基于视口宽度，横屏/竖屏切换时字体突变明显，对长文本段落尤其不友好
rem + vw 动态根字号才是稳妥做法
把 vw 用在 html 的 font-size 计算上，再让所有 rem 值基于它，既保持可维护性，又避免全局样式被 vw 直接冲垮。
推荐写法（CSS）：
立即学习“前端免费学习笔记（深入）”；
html {
font-size: calc(16px + 0.25vw);
}
解释：
– 16px 是最小字号（对应 320px 宽度）
– 0.25vw 表示每增加 100px 视口宽，根字号 +25px，实际增长平缓（768px → ~18px，1440px → ~22px）
– 比纯 4vw 更可控，也比 clamp() 兼容性更好
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 后续所有
font-size: 1.5rem;都会自动按比例缩放 - 注意：不要在同一个项目里混用
px、em、rem做字体主控，容易失控 - 如果用了 CSS-in-JS 或框架（如 Vue 的 scoped style），确保
html的计算没被隔离或覆盖
移动端 text-size-adjust 会干扰 vw 效果
iOS Safari 默认开启文字缩放保护，哪怕你写了 font-size: 4vw;，用户双指放大后，整个页面文字仍可能被强制重排，导致布局错乱或字号失真。
必须加这行来禁用非用户主动触发的缩放：
html {
-webkit-text-size-adjust: 100%;
text-size-adjust: 100%;
}
- 缺了这句，
vw在 iOS 上基本等于“半残” -
100%表示允许用户手动缩放（Accessibility 合规），none会被部分 iOS 版本忽略且影响可访问性 - 该属性只对
或生效，设在子元素无效
别忘了 viewport meta 是前提
没有正确的 <meta name="viewport">，vw 根本不工作——它依赖视口宽度计算，而很多安卓 WebView 或 QQ 浏览器默认用桌面模式渲染，视口宽度可能是 980px 而非设备物理宽度。
务必确认页面 head 中有：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
-
width=device-width是关键，缺了它1vw = 980px / 100 = 9.8px，完全失准 -
user-scalable=no可选，但若业务允许用户缩放，就别加；加了反而可能被系统忽略或触发警告 - 某些 Hybrid 容器（如微信内嵌 WebView）会劫持 viewport，此时需 Native 侧配合透出真实设备宽度
真正难的不是算出那个 vw 系数，而是让每个环节都稳住：meta 正确、root font-size 可控、text-size-adjust 关闭、rem 链路干净。漏掉任意一环，屏幕上看到的就只是“好像动了，但总不对劲”。
