px在需响应式缩放或适配多设备时不可用，因其无法随根元素或视口变化；适合固定精度场景如图标文字，但正文标题等弹性排版应避免。
px 在 CSS 中什么时候不能用
当设计需要响应式缩放或适配不同设备时，px 会卡死字号，无法随根元素或视口变化。它适合固定像素精度的场景（比如图标内文字、UI 控件微调），但不适合正文、标题等需弹性排版的内容。
常见错误现象：font-size: 16px 在小屏手机上挤成一团，用户双指放大后文字和布局错位；或者在系统强制放大字体（如 Windows 高对比度模式、iOS「更大字体」设置）下完全不响应。
- 移动端 H5 页面里全用
px写正文 → 用户缩放失效，可访问性直接掉线 - CSS 自定义属性（
--base-font-size）配合px赋值 → 后续无法用em/rem做相对计算 - 用
px设置html的font-size再配rem→ 失去动态调整意义，白搭
em 和 rem 的核心区别在哪
em 是相对于父元素 font-size 计算，嵌套越深越容易失控；rem 只认 html 元素的 font-size，是真正意义上的“根相对”。别被“em 更灵活”误导——它灵活得让人头疼。
使用场景：rem 是响应式字号的事实标准；em 仅建议用于局部缩放，比如按钮内图标和文字的等比缩放（icon { font-size: 0.8em; }）。
立即学习“前端免费学习笔记（深入）”；
- 写
.card { font-size: 1.2em; }，而它的父级是1.5rem→ 实际计算是1.5rem × 1.2，再向上找父级的font-size，链式依赖极难追踪 - 用
rem但忘了重置html的默认字号（Chrome 是16px）→ 所有1rem默认等于16px，改了设计稿基准（比如按10px = 1rem）却不改html→ 全站字号错乱 - 媒体查询中用
em做断点（@media (min-width: 30em)）→ 这里的em是基于浏览器默认字号（16px），不是当前上下文，所以是安全的，但容易误解
怎么让 rem 真正适配不同屏幕
靠 JS 动态设 html 的 font-size 是最稳的路，CSS 的 clamp() 或媒体查询只能覆盖有限区间，且无法响应系统字体设置。
关键不是“怎么算”，而是“以谁为基准”。推荐以设计稿宽度（如 375px）对应一个基准 rem 值（如 1rem = 10px），然后按比例缩放：
document.documentElement.style.fontSize = document.documentElement.clientWidth / 375 * 10 + 'px';
- 别在
DOMContentLoaded里只执行一次 → 屏幕旋转、分屏、缩放时要重新计算，加resize监听，但记得防抖 - 用
clientWidth不用innerWidth→ 排除滚动条宽度干扰，更准 - 如果项目已用
postcss-pxtorem，确保插件的rootValue和 JS 里设的基准一致，否则编译后和运行时不匹配
字体单位混用时最容易翻车的点
混用本身没问题，但边界必须清晰。最常崩的是把 em 当 rem 用，或在 transform: scale() 容器里还用 em 控制字号 —— 此时 em 会叠加缩放，结果不可控。
-
body { font-size: 1.125em; }放在未重置html的页面里 → 基于浏览器默认16px，变成18px，后续所有rem都偏大 - 用
vw写标题字号（font-size: 4.5vw）+rem写正文 → 行高、间距若仍用rem，视觉节奏会断裂 - Flex 容器设了
font-size: 0.875em，子元素又用1.5em→ 实际是父级字号的1.5倍，不是设计稿的1.5倍，还原失真
复杂点不在换算公式，而在谁控制谁、何时继承、是否被 transform 干扰 —— 看渲染前的 computed style，比背规则管用。
