em 的伸缩性取决于父级 font-size，嵌套即失控；rem 的伸缩性来自根字号统一控制，但前提是根字号能随视口动态变化；混用单位会破坏参照系一致性，导致样式失控。
em 的伸缩性取决于父级 font-size，嵌套即失控
em 的伸缩不是“自动适配屏幕”，而是被动跟随最近一个显式设置了 font-size 的父元素。一旦父级用的是 rem 或百分比，子元素的 1em 就变成复合计算：比如父级 font-size: 0.875rem（=14px），子级再写 padding: 1em，实际就是 14px，而不是你预期的 16px。
常见错误现象：margin: 1em 在弹窗里突然变大，查半天发现是某层卡片组件悄悄写了 font-size: 1.2em，把整棵子树的 em 基准全带偏了。
- 用在
padding、margin上时，em 参照的是该元素自身的font-size，不是父级——很多人误以为是父级，结果改了父容器字号，子元素内边距却纹丝不动 - 嵌套三层以上时，
font-size: 0.875em的最终像素值必须逐层回溯计算，调试成本陡增 - 按钮组件内设
padding: 0.75em是合理的，因为它本就该随按钮文字大小同比例缩放；但若这个按钮被塞进一个用rem控制字号的卡片里，它的伸缩逻辑就和卡片脱钩了
rem 的伸缩性来自根字号统一控制，但前提是它真能动
rem 本身不响应屏幕——html { font-size: 16px } 是固定尺寸，不是响应式。它的伸缩性只在根字号随视口变化时才生效。一旦你用 clamp(14px, 2.5vw, 18px) 或 JS 动态设置 document.documentElement.style.fontSize，所有 rem 值立刻等比缩放。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
性能影响明显：用 vw 直接设 font-size: 2.666vw 最轻量，但 iOS Safari 12 及更早版本不支持；clamp() 在 Safari 13.1+ / Chrome 88+ 支持良好，是目前最推荐的方案。
- 别在 CSS 里写死
html { font-size: 16px }，否则 JS 设置会被覆盖，根字号根本动不了 - 避免用媒体查询硬切几档
font-size（如@media (max-width: 768px) { html { font-size: 14px } }），断点之间会突变，横屏切换时尺寸跳变 -
border-width: 0.125em这类写法看似灵活，实则危险——边框不该随根字号放大三倍，视觉精度直接崩坏
混用 rem 和 em 会让伸缩逻辑彻底断裂
单位混用不是语法错误，但会制造隐性耦合。比如卡片用 rem 写 font-size 和 padding，但图标用 em 写 font-size: 0.875em，一旦后期调整根字号，图标大小不会同比例变化，基线对不齐，间距错位。
更隐蔽的问题：同一套间距变量里同时出现 1.5rem 和 1.5em，等于主动放弃可维护性。后期换设计稿基准，em 部分会意外失效，还查不出原因。
- 安全边界：用
rem做全局尺度，就别让任何父容器偷偷改font-size；用em做局部缩放，就别指望它能响应屏幕宽度 - 行高慎用
line-height: 1.5em——推荐无单位line-height: 1.5，它基于当前元素自身字号，又不引入额外参照系 - 图标字体对齐文本基线时，
font-size: 0.875em合理；但若该图标放在用rem控制字号的标题里，它的伸缩就脱离了标题节奏
font-size；一旦用 em 做局部缩放，就别指望它能响应屏幕宽度。单位本身没对错，错的是参照逻辑被悄悄污染。
