绝大多数响应式排版场景该用rem，因其以html根字号为唯一基准，实现整站文字、间距、圆角等按相同比例一致缩放；em仅适用于图标对齐、内边距随本元素字号微调等局部强耦合场景；vw适合流体字体和全屏容器，但无法支撑精细排版体系。
绝大多数响应式排版场景该用 rem，不是因为它“高级”，而是它把缩放控制权收归 html 元素，避免嵌套失控；em 只适合父字号强耦合的局部微调；vw 适合流体字体或全屏容器，但不能单独撑起整套排版体系。
什么时候必须用 rem？
当你需要整站文字、间距、圆角等按相同比例缩放，且不希望改一处、查三层时，rem 是唯一靠谱选择。它的计算链路干净：所有值都只依赖 html { font-size }，改一个地方，全站响应。
- 典型场景：按钮
padding: 0.75rem、标题font-size: 1.5rem、卡片border-radius: 0.375rem - 错误做法：
font-size: 62.5%写死在html上——它依赖用户浏览器默认字号，且和系统字体缩放冲突，在 macOS + Safari 下实测失准 - 兼容底线：若必须支持 Safari 12 或更低版本，JS 动态设
document.documentElement.style.fontSize仍是唯一路径，但得加防抖，并确保首次渲染前执行
em 真正该用在哪？
em 不是错，只是适用面极窄。它只在“当前文字节奏就是设计节奏”的局部场景里自然——比如图标字体的 font-size 和 line-height 必须对齐文本基线，或按钮内边距想随文字同比例增减。
- 安全用法：
line-height: 1.5（无单位）代替line-height: 1.5em；border-width: 0.0625em仅当明确需要边框粗细随文字缩放时才用 - 危险信号：在卡片组件里用
em设padding，但标题用rem、正文用px——这类混用会让间距逻辑彻底断裂 - 特别注意：
margin和padding用em时，参照的是该元素自身的font-size，不是父级；很多人误以为是父级，结果改了父容器字号，子元素内边距却没变
vw 能不能替代 rem 做排版？
可以，但要分层用：vw 适合做流体字体（如 font-size: clamp(14px, 4vw, 24px)）或全屏容器（width: 100vw），但它不适合控制组件内边距、行高、圆角等需保持视觉比例一致的细节。
立即学习“前端免费学习笔记（深入）”；
- 常见翻车：
font-size: 8vw在小屏下可能缩到 10px 以下，可读性崩坏；100vw在 PC 端因滚动条存在导致横向溢出 - 推荐组合：
vw控制大块区域宽度（.banner、.card）、全屏高度（min-height: 100vh）；rem控制文字大小（font-size: 1.125rem）、行高（line-height: 1.5rem）、内边距（padding: 0.5rem） - 别用
rem控制border或阴影——缩放后边框变粗、模糊；也别用vw控制border，它会随视口疯狂变化
真正容易被忽略的点是：单位混用本身不致命，致命的是“同一类样式在不同组件里随意切换参照系”。比如一个项目里，按钮用 rem、弹窗用 em、轮播图用 vw，调试时根本没法建立统一预期——这不是技术选型问题，是样式契约的失效。
