rem更适合全局适配，因其基准锁定html根元素font-size，不随dom嵌套变化；em则依赖父级字体大小，深层嵌套时计算失真，易导致布局错乱。
rem 更适合做适配，根本原因就一条：它不依赖嵌套路径，只认 html 元素的 font-size；而 em 的计算链会随 DOM 深度指数级发散，一改全乱。
em 在深层嵌套中会“失真”
em 的值始终相对于**当前元素的父元素字体大小**。如果父元素本身用了 em 设置字体，那子元素的计算就是“父的父 × 父的倍数 × 自己的倍数”。三层嵌套后，1.2em 可能实际放大到 1.728 倍（1.2³），完全脱离设计预期。
常见错误现象：margin 或 padding 在嵌套组件里越缩越小、文字忽大忽小、按钮尺寸在不同上下文中不一致。
- em 适合局部微调（比如让
small标签固定是父文字的 0.8 倍） - em 不适合全局布局单位（如容器宽、行高、间距系统）
- 调试时必须逐层检查父级
font-size计算链，耗时且易漏
rem 的基准永远锁定在 html 元素
无论你在 div > section > article > p 的第几层，1rem 始终等于 html 元素当前的 font-size 像素值。改一次 html 的 font-size，所有 rem 单位等比缩放。
使用场景明确：rem 是为「整页缩放」而生的——移动端视口适配、主题字号切换、无障碍大字模式。
- 媒体查询中只需写几组
html { font-size: ... }，就能覆盖主流断点 - JS 动态设置也极简：
document.documentElement.style.fontSize = window.innerWidth / 10 + 'px'; - 和 CSS 自定义属性结合时更可控，例如：
html { font-size: var(--root-font, 16px); }
rem 的换算成本其实更低
很多人觉得 “rem 要手动把 px 除以基准值”，但实际开发中，这个过程早已被工具收编：
- PostCSS 插件（如
postcss-pxtorem）可全自动转换px→rem - VS Code 插件（如 CSS Rem Unit Converter）光标一按就换
- 设计稿标注工具（如 Zeplin、Figma 插件）直接导出 rem 值
而 em 的换算无法自动化——你永远得先知道“当前父级是多少 px”，这个信息在 CSS 中不显式存在，只能靠 DevTools 人肉查。
rem 在高 DPI 和缩放场景下更稳定
浏览器缩放（Ctrl + / Cmd +）、系统级字体缩放、Windows 高 DPI 缩放设置，都会影响 em 的实际渲染结果，因为它们会改变中间某一层的 font-size 计算起点。而 rem 只响应根元素，只要你不主动用 JS 干预 html 的 font-size，它的缩放行为就是确定的、可预测的。
容易踩的坑：rem 不是万能的——它对非根元素的 font-size 无感，所以如果你在某个组件里写了 html { font-size: 20px; } .modal { font-size: 14px; }，再给 .modal p { line-height: 1.5em; }，这个 1.5em 就又回到 em 的嵌套逻辑里了。所以原则是：**所有尺寸单位，统一用 rem；所有字体继承控制，靠 font-size: inherit 或重置，别混用 em。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
