rem 和 em 不改变盒模型结构但影响各部分尺寸计算：em 相对父元素 font-size，易引发嵌套放大；rem 始终相对根元素 font-size，更可控；混用单位易导致布局失配。
rem 和 em 本身不改变盒模型结构，但会直接影响盒模型各部分的尺寸计算结果
盒模型（content + padding + border + margin）的结构逻辑是固定的，rem 和 em 不会“开关”或“替换”这个模型，但它们作为长度单位，会把每个可设尺寸的属性（width、padding、margin、border-width 等）的实际像素值变成动态计算值——而这个计算过程，恰恰决定了盒子最终在页面中占多大空间。
em 的尺寸计算依赖父级 font-size，容易引发嵌套放大效应
em 是相对于**当前元素的父元素 font-size** 计算的。这意味着：padding: 1em 在不同嵌套层级下可能对应完全不同的像素值。
- 如果
的font-size是默认16px，且父元素没改过字体大小，则1em = 16px - 但若父元素设置了
font-size: 1.2em（即19.2px），子元素写margin: 1em就会变成19.2px，而不是16px - 再往下一层，如果子子元素又继承了这个
19.2px并再乘一次1.2em，就会变成23.04px—— 这就是常说的“em 嵌套放大”问题
这种不可预测的级联会让盒模型的 padding 和 margin 实际值越来越难推算，尤其在复杂组件嵌套中，极易导致布局错位或响应异常。
rem 绕过父级干扰，让盒模型尺寸更可控
rem 始终只看 根元素的 font-size，不管你在第几层嵌套，1rem 永远等于 html { font-size: 16px } 时的 16px（除非你主动改根字号）。
立即学习“前端免费学习笔记（深入）”；
典型做法是重设根字号以简化换算：
html { font-size: 62.5%; /* 16px × 62.5% = 10px，此时 1rem = 10px */ } .box { width: 20rem; /* → 200px */ padding: 1.6rem; /* → 16px */ margin: 0.8rem; /* → 8px */ }- 所有盒模型尺寸都基于同一个基准，不会因组件嵌套而漂移
- 配合媒体查询动态改
html font-size，就能实现整站等比缩放（比如移动端设为font-size: 50%，则1rem = 8px，所有 rem 值自动缩小） - 注意：
border-width虽然支持rem/em，但浏览器对小数值渲染有精度限制（如0.1rem在10px根字号下是1px，但0.05rem可能被截断为0）
px、em、rem 混用时盒模型容易“失配”
一个常见坑是：用 rem 控制 width 和 padding，却用 px 写 border 或 font-size。当根字号变化时，内容区和内边距跟着缩放，但边框粗细不变，视觉比例就崩了。
- 推荐统一使用
rem（或em）管理所有盒模型相关尺寸：包括width、height、padding、margin、border-width、font-size - 如果必须用
px（比如需要绝对精准的 1px 分割线），请确保它不参与响应式缩放逻辑，且单独测试高 DPR 屏幕下的渲染效果 - 不要在同一个组件里混用
em（用于局部缩放）和rem（用于全局缩放），除非你明确知道每处计算的基准和叠加关系
真正影响盒模型表现的，从来不是单位本身，而是你是否清楚每一行 css 尺寸背后的计算源头——em 看父，rem 看根，px 看屏幕。漏掉这个前提，再规范的盒模型也会在实际渲染中“跑偏”。