rem是响应式默认选择，因其缩放仅依赖html根字号，可控可预测；em仅适用于需跟随本元素字体比例的局部场景，如边框、行高、图标尺寸。
绝大多数响应式项目该用 rem，不是因为它“更高级”，而是它把缩放控制权收归 html 元素，避免嵌套计算失控；em 只在父字号强耦合的局部场景里才真正有用。
为什么 rem 是响应式布局的默认选择
真响应的关键不是“用了相对单位”，而是“缩放路径是否可控、可预测”。rem 的计算只依赖 html { font-size } 这一个源头，改一次，所有 1.5rem 的边距、0.75rem 的圆角、1.25rem 的字体大小全部等比变化。
- 调试成本低：开发者工具里直接看 computed 值，能快速反推根字号是否生效
- 媒体查询少写 80%：不用为每个断点重复定义
padding、margin的像素值 - 避免“横屏突变”：用
clamp(14px, 2.5vw, 18px)设置html字号，视口连续缩放时尺寸平滑过渡 - 注意兼容底线：Safari 13.1+ 和 Chrome 88+ 支持
clamp()；若必须支持 Safari 12 或更低，只能用 JS 动态设置document.documentElement.style.fontSize，且需防抖 + 首次渲染前执行
什么时候非用 em 不可
em 的价值不在全局缩放，而在“跟随当前文字节奏微调”。它适合那些**必须与本元素字体大小保持比例关系**的属性。
-
border-width: 0.0625em：当边框粗细需要随文字缩放（比如图标按钮） -
line-height: 1.5（无单位）比line-height: 1.5em更安全——后者会二次参照自身font-size，容易叠乘 -
icon-font图标尺寸设为1.2em，可自然对齐文本基线 - 危险信号：
padding: 1em用在卡片里，但卡片标题用1.5rem、正文用px——混用等于主动放弃间距逻辑一致性
em 容易翻车的三个具体现象
很多人不是不会写 em，而是没意识到它的参照规则在不同属性上不统一。
立即学习“前端免费学习笔记（深入）”；
-
font-size: 0.875em参照父元素；但padding: 1em参照的是**当前元素自身的font-size**，不是父级——改了父容器字号，子元素内边距却不跟着变 - 三层嵌套后，
font-size: 1.2em×1.2em×1.2em= 实际放大 1.728 倍，数值已脱离直觉 - 移动端弹窗中按钮文字突然变小？大概率是弹窗容器被 JS 修改了
font-size，导致所有后代em值被带偏
别让 rem “假装响应”：必须显式设置根字号
rem 不会自动响应，它只是个计算单位。浏览器默认 html 字号是 16px，但 iOS Safari 有时会重置，不能依赖。
- 必须写：
html { font-size: 16px; }—— 别留空、别靠继承 - 别用
font-size: 62.5%这类“方便心算”的技巧：它依赖用户系统默认字号，且和 macOS + Safari 的字体缩放功能冲突 - 设计稿宽 375px、希望 1rem = 10px？JS 计算逻辑应为：
document.documentElement.style.fontSize = 10 * (window.innerWidth / 375) + 'px';，但注意安卓 WebView 的screen.width不准，优先用window.innerWidth
最常被忽略的一点：rem 和 em 的混用往往不出现在代码里，而出现在设计系统变量命名中——比如 $space-md: 1.5rem 和 $icon-size: 1.2em 并存，后期换根字号时，图标尺寸不会变，但间距会变，视觉节奏就断了。
