rem 的换算基准是 html 元素当前生效的 font-size，而非固定 16px；em 在 font-size 中参考父元素，在 padding/margin 中参考自身 font-size；px 适用于边框、阴影等需像素级精准的场景，rem 适用于文字、间距等需缩放的场景，em 仅限局部弹性需求。
rem 的换算基准不是 16px，而是 html 元素当前生效的 font-size
很多开发者直接用 px / 16 算 rem，上线后文字忽大忽小——因为实际页面里 html 的 font-size 很可能不是 16px。它可能是 html { font-size: 62.5%; }（≈10px），也可能是 html { font-size: clamp(14px, 1.5vw, 18px); } 这类响应式写法。
实操建议：
- 打开 DevTools → Elements → 选中
html标签 → 切到 Computed 面板，查font-size的实际计算值（如10px或15.2px） - 若项目用了
postcss-pxtorem，它的rootValue配置才是真实换算依据，不是浏览器默认值 - 手算公式始终是：
rem = px / rootValue；例如目标 14px，html实际为 10px →1.4rem
em 在 font-size 和 padding/margin 中参考对象不同
em 最容易踩坑的地方：它在不同 CSS 属性里“看谁”不一样。设 font-size: 1.2em 时，它看父元素字体大小；但设 padding: 1.2em 时，它看的是**当前元素自己的 font-size**（哪怕这个 font-size 是继承来的）。
常见错误现象：
- 同一 class 放在不同嵌套层级，
padding值完全不同 - 父元素
font-size: 0.8em，子元素再写font-size: 1.2em，结果变成 0.8 × 1.2 = 0.96 倍根字号，越嵌套越难预测 - 按钮内文字正常，放进卡片后突然变小，只因卡片设置了缩放的
font-size
建议：非必要不混用 em 控制字体和间距；组件内部统一用 rem 或 px，仅在需随文等比缩放的图标等场景谨慎用 em，且嵌套不超过两层。
px、em、rem 的适用边界很明确，别强行统一
不是所有地方都适合换 rem。比如边框 border: 1px solid #ccc，用 0.0625rem（按 16px 算）既难读又无意义；圆角 border-radius: 4px 写成 0.25rem 同样增加维护成本。
合理分工：
-
px：边框、阴影模糊值、小图标尺寸、需要像素级精准的细节 -
rem：标题、正文、行高、外边距、媒体查询断点（@media (min-width: 40rem)） -
em：仅限局部弹性场景，如按钮内图标随文字缩放、line-height（它本就是无单位倍数，用1.5比1.5em更安全）
特别注意：媒体查询里的 rem 单位，其基准仍是 html 的 font-size，不是视口宽度。想做 vw 响应式，请直接用 vmin 或 JS 动态改根字号。
动态设置 html font-size 时，rem 缩放是全局的，但副作用常被忽略
用 JS 或媒体查询改 html 的 font-size，确实能让所有 rem 值等比变化——但这包括 width、height、border-radius、甚至 background-size。如果某处用了 width: 20rem，而设计稿本意是“固定 320px 宽度”，那在大屏上它会撑满整个视口。
所以真正要问的不是“能不能用 rem”，而是：“这个值是否应该随用户系统字号或缩放比例一起变？”
无障碍适配时，用户把系统字体调大，rem 文字会变大，这是优点；但 rem 的容器宽高也会变，可能导致布局错位——这种耦合必须提前评估，不能默认“用了 rem 就一定更友好”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
