SCSS中px转rem函数报错“Operation on an invalid type”的根本原因是单位不匹配（如32px / 16），正确做法是先用unitless()判断并用$px / 1px剥离单位；且SCSS换算必须与JS运行时设置的根字号严格对齐，推荐用mixin替代函数以支持条件输出和多属性批量处理。
SCSS里px转rem函数为什么总报错Operation on an invalid type
根本原因是直接拿带单位的$px参与除法运算，比如$px / 16px看似合理，但SCSS要求参与算术的两个操作数单位必须兼容——而px和px相除得的是无量纲数字，不是它拒绝的原因；真正触发错误的是像32px / 16（右边无单位）或32 / 16px（左边无单位）这种“单位不匹配”的写法。
正确做法是先用unitless()确认是否有单位，再用$px / 1px安全剥离单位：
-
@if not unitless($px) { $px: $px / 1px; }—— 这比strip-unit()更直白可靠 - 别依赖
unit($px, '')，SCSS 3.5+已弃用该用法，unit()只读不改值 - 如果传入
14（纯数字），函数应自动补px，否则下游计算会因类型不一致中断
px转rem函数必须和JS设置的根字号严格对齐
SCSS里的rem只是个静态换算，它不会感知屏幕宽度变化。所谓“自适应”，全靠JS在运行时动态改document.documentElement.style.fontSize。两者若不一致，尺寸就全乱了。
常见错配场景：
立即学习“前端免费学习笔记（深入）”；
- JS里写
fontSize = clientWidth / 7.5 + 'px'→ 实际1rem = 100px，但SCSS函数却用$px / 37.5 * 1rem（隐含1rem = 37.5px） - 设计稿是640px，JS按
clientWidth / 6.4设根字号，SCSS却仍用750系分母 - 没处理DPR：高倍屏下
clientWidth是逻辑像素，但JS若未乘window.devicePixelRatio，实际渲染会偏小
对策：把基准值抽成变量，JS和SCSS共用同一份配置，例如定义$rem-base: 100px，JS里也按/ 100算缩放比。
为什么推荐用mixin而不是@function做单位转换
函数返回值只能塞进属性值位置，比如font-size: rem(14px)，但无法展开成多条声明；而mixin能直接注入完整CSS块，更贴近真实开发流。
典型痛点：
- 写按钮样式要同时转
font-size、padding、border-radius，用函数就得重复写三遍rem() - 伪元素
::before的content里不能调函数（Sass不支持在content中执行函数） - 需要条件判断时（如
@if $border），函数无法控制是否输出某条声明，mixin可以
一个实用写法：
.px-rem($fs: false, $pd: false) {
@if $fs { font-size: $fs / $rem-base * 1rem; }
@if $pd { padding: $pd / $rem-base * 1rem; }
}
.btn { @include px-rem($fs: 14px, $pd: 8px); }border-width、line-height这些易漏属性怎么安全转rem
它们看着像长度，但语义不同：border-width允许thin/medium等关键字，line-height无单位时是相对于font-size的倍数——直接套rem函数会破坏原意。
处理原则：
-
border-width：只对明确写了px的值转换，1px→0.01rem，但medium保留原样，别强行转 -
line-height：若为纯数字（如1.5），不加单位，也不转rem；若写了24px，才按基准换算 -
transform: scale()这类函数参数，单位无关，禁止传入rem——它要的是比例因子，不是长度
最稳妥的方式：不在全局函数里硬编码适配所有属性，而是按需封装专用mixin，比如.border-rem($width)只处理有明确px输入的边框。
