SCSS中rem()函数算不准，因Sass编译时无法感知运行时动态设置的html根字体大小，仅按预设基准（如16px）静态计算，导致JS修改fontSize后尺寸失真；且不支持@media内响应式重算、calc()中单位混用及行内/JS样式转换。
SCSS里写rem(16px)为什么算不准
因为Sass编译时根本不知道运行时html { font-size }是多少。你传rem(16px)，它按预设的$base-font-size: 16px算出1rem，输出1rem；但若项目用JS动态设了document.documentElement.style.fontSize = '10px'，那实际1rem就变成10px，而Sass生成的1rem仍按16px基准理解——结果所有尺寸都偏大60%。
常见错误现象：margin: rem(24px)在设计稿750px宽下看着正常，一到小屏手机上元素挤成一团；或者改了JS动态根字号后，整个布局比例崩坏，但控制台查不到CSS报错。
- 只在根字号**完全固定**（比如纯PC项目、无JS干预、无缩放）时才可信
- 函数内部必须显式校验单位：
unit($value) == 'px'，否则rem(24)或rem(24em)直接报Incompatible units - 别在
@media里调用rem()期望它“响应式重算”——Sass不执行运行时逻辑，媒体查询里的值全是编译时快照
calc(50% + rem(16px))拼接失败的真正原因
Sass无法把rem(16px)的返回值（比如1rem）安全塞进calc()表达式里。直接写calc(50% + rem(16px))，Sass会尝试数值相加，而%和rem单位不兼容，编译报错。
实操只能字符串拼接：#{'calc(50% + '}#{rem(16px)}#{')'}。但这只是语法逃逸，没解决根本问题：浏览器最终解析的是calc(50% + 1rem)，而IE9及部分安卓WebView根本不支持rem参与calc()运算。
立即学习“前端免费学习笔记（深入）”；
- IE9下
calc(100% - 1rem)会被整条忽略，降级为100% - 多层嵌套
calc(calc(100% - 1rem) / 2)在旧版UC、QQ内置WebView中易解析失败 - 现代方案应优先用
clamp(1rem, 2.5vw, 1.5rem)替代手动换算+媒体查询
行内样式和JS动态样式为什么永远转不了rem
postcss-pxtorem或px2rem这类工具只处理构建阶段的CSS文件内容。HTML里style="width: 100px"、JS里el.style.height = '50px'、甚至Vue模板中:style="{ width: '200px' }"，全在构建之后才存在，插件根本“看不见”。
常见错误现象：页面上某个按钮宽度始终是100px，调试发现它来自div[style]，但SCSS里明明写了rem(100px)——那是白写的。
- 规避方法：把大写
PX当“免转标记”，width: 100PX不会被转换，且浏览器识别正常 - JS动态样式需手动计算：
el.style.width = (100 / rootFontSize) + 'rem'，但得确保rootFontSize实时准确 - Vue中避免
:style写死px，改用计算属性返回rem字符串，或绑定class走CSS处理
为什么现在该少用Sass rem函数，多用原生CSS能力
不是函数不好，而是场景变了。2026年主流浏览器已全面支持clamp()、calc()（含rem）、vw/vh，且postcss-preset-env能自动补全旧浏览器需要的回退规则。继续用Sass函数做px→rem，等于在编译时硬编码一个可能随时被JS覆盖的基准。
最容易被忽略的一点：Sass函数无法感知font-size继承链变化。比如你在.modal里设了font-size: 0.875em，里面所有rem()还是按html根字号算——这和em的行为逻辑冲突，调试时极易误判。
- 根字号动态项目，直接用
font-size: clamp(1rem, 2.5vw, 1.5rem)，一行顶过去十行媒体查询 - 需要精确像素对齐（如雪碧图定位），老实用
px或background-position: 10px 20px，rem在这里是自找麻烦 - 真要封装函数，也该返回
calc()字符串而非数值，例如@function rem-calc($px) { @return calc(#{$px} / 16 * 1rem); }，让浏览器 runtime 计算
