em在多级嵌套中出错的根本原因是其依赖当前元素font-size，而该值又可能由em定义，形成递归计算链；浏览器逐级向上查找直至遇到绝对值（如16px）才停止，中间任一层用em或%都会转嫁计算，导致结果不可预测。
em单位在多级嵌套中出错，根本原因是它依赖“当前元素的font-size”，而这个值本身又可能由em定义——形成递归计算链，最终结果难以预测。
em怎么一层层算错的
浏览器不会直接给你一个数字，而是从当前元素出发，逐级向上找父级的font-size，直到遇到绝对值（比如16px或1rem）才停下。中间任何一层用em或%设字号，都会把计算“转嫁”给上一级。
- 父容器
font-size: 0.8em→ 它的font-size取决于爷爷辈；爷爷若也是0.9em，就得再往上翻 - 某层写了
font-size: 0或font-size: 0.625em（即10px），会直接截断计算链，但子元素1.2em就变成12px，而非你预期的19.2px - JS动态修改了某层
font-size（比如弹窗缩放时设font-size: 0.9em），所有后代em值都会被悄悄拉低
调试时怎么看实际字号
开发者工具里看到的Computed面板中的font-size值（比如14.4px）是最终结果，但无法反推哪一层出了偏差。靠猜不如实测：
- 加一行
console.log(parseFloat(getComputedStyle(document.documentElement).fontSize))确认根字号是否如预期 - 对可疑元素执行
getComputedStyle(el).fontSize，看它到底是多少px，再手动倒推父级 - 禁用父级样式，逐个启用，观察
font-size何时跳变
什么时候非得用em，而不是rem
em不是bug，是工具——只在需要“跟随文字等比缩放”的局部场景才不可替代：
- 图标字体：
.icon { font-size: 0.8em; vertical-align: middle; }，换正文字号时图标自动缩放，保持基线对齐 - 边框粗细：
border-width: 0.1em，文字变大时边框也变粗，视觉权重一致 -
line-height: 1.5em要小心：它继承的是父级font-size，不是自身，容易导致行高“悬空”
别让em和rem混在同一个组件里
一个按钮内部同时用font-size: 0.875em和padding: 0.5rem，等于把两套计算逻辑硬塞进同一块样式里。一旦根字号或某层父字号变动，padding不变而文字缩放，间距比例立刻崩坏。
最容易被忽略的是：BEM类名如button__label如果用em设字号，而button本身又被其他模块用rem控制大小，那这个label的实际尺寸就彻底脱离设计系统约束了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
