calc() 是唯一真正可靠的单位自动换算方案，它通过显式运算逻辑实现浏览器实时计算，支持混合单位且需注意空格语法，而预处理器换算和 JS 运行时换算各有局限与性能陷阱。
calc() 是唯一真正可靠的单位自动换算方案
浏览器原生不支持 CSS 里“把 rem 自动转成 px”或“把 % 算成具体 vw 值”这类隐式换算。所有所谓“自动”，本质都是靠 calc() 显式写清楚运算逻辑，由浏览器实时计算结果。
常见错误是以为预处理器（如 Sass）的 px 到 rem 转换能进最终 CSS——其实编译后就固定成数字了，失去响应性；或者误用 em 嵌套导致级联放大，根本不是换算，是继承失控。
-
calc()支持混合单位：width: calc(100% - 2rem)、margin-left: calc(1vw + 8px) - 必须有空格：
calc(100%-2rem)会报错，calc(100% - 2rem)才合法 - 不能在
@media条件里直接写变量运算，比如min-width: calc(var(--breakpoint) * 1.2)不生效——CSS 变量值是字符串，乘法不被解析
Sass/Less 编译期换算只适合静态基准值
预处理器能做的只是“已知设计稿宽度 375px，把 16px 写成 16 / 375 * 100%”，本质是数学代入，不是运行时换算。
典型场景是适配 iPhone 尺寸：你设 $base-width: 375px，然后写 font-size: (14 / $base-width) * 100vw，编译后变成 font-size: 3.733vw。这看起来像“自动”，但一旦视口宽度变化超出预设范围，比例就失真。
立即学习“前端免费学习笔记（深入）”；
- 只适用于固定设计稿基准（如 UI Kit 统一按 375px 出图）
- 无法响应
font-size动态缩放（比如用户调大系统字号），rem才管这个 - Sass 的
unit()、unitless()函数只能校验单位类型，不能做跨单位转换
JavaScript 运行时换算要避开 layout thrashing
想让某个元素宽度始终等于另一个元素高度的 1.5 倍？纯 CSS 做不到，得用 JS 读取再写回 style。但直接在循环里反复读 offsetHeight 再设 style.width，会强制浏览器同步重排，卡顿明显。
- 用
getComputedStyle()替代offsetXXX属性（更稳定，但仍是同步读取） - 把读操作批量放在
requestAnimationFrame开头，写操作放结尾，合并重排 - 优先用
ResizeObserver监听尺寸变化，而不是window.resize——后者会漏掉 flex 容器内部伸缩 - 避免在
:hover或动画帧中高频触发换算，改用 CSS 自身的transform或scale()
viewport 单位和 rem 混用时的基准冲突
很多人同时用 vw 做大屏缩放、rem 做字体可访问性，结果发现按钮文字小了但图标没变小——因为 rem 依赖 html 的 font-size，而 vw 直接按视口算，两者基准不同源。
例如：设 html { font-size: 2.666vw; }（即 375px 下为 10px），看似把 rem 和 vw 绑定，但 iOS Safari 对 font-size 的最小限制（通常不小于 11px）会让这个公式在小屏上失效，rem 实际变大，整个比例崩了。
- 不要用
vw直接设html font-size，改用 JS 动态设置并加最小值保护 -
clamp()可缓解：font-size: clamp(14px, 4vw, 20px)，但注意 Safari 15.4+ 才完全支持 - 媒体查询里用
rem断点（如@media (min-width: 40rem)）比用px更一致，因它随根字体缩放
事情说清了就结束。单位换算没有银弹，关键看你要响应的是视口、字体设置，还是 DOM 尺寸——选错基准，后面全白搭。
