用vw设置html的font-size再统一用rem写尺寸，是最稳、最轻量、无需JS的等比缩放方案；transform:scale()会导致热区错位、fixed漂移、打印失真，生产环境慎用。
直接说结论：用 vw 设置 html 的 font-size，再统一用 rem 写所有尺寸，是当前最稳、最轻量、无需 JS 就能上线的等比缩放方案；transform: scale() 看似简单，但热区错位、fixed 元素漂移、打印/截图失真，生产环境慎用。
为什么不能只用 vw 直接写宽高
vw 单位本身确实能响应视口变化，但直接大量使用会失控：
- 小屏下
font-size: 5vw可能缩到8px，文字糊成一片，iOS Safari 甚至会强制最小字号为11px，导致计算失效 - 大屏（比如折叠屏或横屏 iPad）下
20vw可能飙到40px，按钮撑满半屏，UI 失衡 - 无法统一控制缩放基点——每个
vw值都要单独调参，改设计稿基准就得全局重算 - IE11 完全不支持
vw，若需兼容，fallback 逻辑复杂（比如用@supports包裹 + 媒体查询兜底）
用 vw 驱动 rem 根字号才是正解
核心思路：让 html { font-size } 随视口线性变化，其余所有尺寸用 rem，自然等比缩放。关键不是“能不能”，而是“怎么设才不翻车”：
- 设计稿是
750px（常见二倍图），对应逻辑宽度375px→html { font-size: 26.67vw; }（因为100px / 375px × 100 = 26.67） - 设计稿是
640px→html { font-size: 31.25vw; }（100 / 320 × 100 = 31.25） - 必须加
@media限制极值：@media (max-width: 320px) { html { font-size: 85px; } }防止超小屏文字不可读；@media (min-width: 640px) { html { font-size: 170px; } }防止大屏爆炸 - 别信
calc(100vw / 3.75)这种写法——Safari 对calc中带除法的vw运算兼容差，且部分安卓 WebView 会四舍五入丢精度
body 字号必须单独重置
根字号被拉高后，所有继承自 html 的字体（包括 body、p、span）都会跟着放大，但正文内容不该随屏幕狂涨：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
-
body { font-size: 0.16rem; }是最常用解法（假设你设了html { font-size: 100px; }，那0.16rem = 16px，刚好还原浏览器默认字号） - 如果设计稿里正文字号是
24px（二倍图），则按比例写font-size: 0.24rem;，而不是硬写24px - 注意：图标字体（如 iconfont）通常依赖
font-size渲染，也要用rem控制，否则在不同屏上大小不一
JS 动态方案 vs vw 方案怎么选
两者都能跑通，但适用场景和风险点完全不同：
- JS 方案（如
document.documentElement.style.fontSize = clientWidth / 750 * 100 + 'px'）适合需要精确控制缩放节奏的场景（比如动画中微调），但必须监听resize和orientationchange，Vue/React 里还要注意组件卸载时移除事件，否则内存泄漏 -
vw方案零 JS、无性能开销、天然支持 SSR，但必须接受它“只管宽度”的局限——高度适配得靠vh或媒体查询补足，且对 DPR 变化（比如横竖屏切换）响应不如 JS 精准 - 混合用？可以，但别把
vw当 fallback：比如先写html { font-size: 26.67vw; }，再用 JS 在不支持vw的旧环境里降级，而不是反过来
真正容易被忽略的是：缩放不是目的，可读性与操作准确性才是。哪怕 vw 计算再精准，如果按钮缩到 24px 高（物理像素不足 48px），手指就点不准——这时候宁可用媒体查询给最小尺寸兜底，也别强求“绝对等比”。
