scss中px2rem函数除以100而非16，是因为该函数专为750px设计稿+1rem=100px的适配方案服务，需与js运行时设置的document.documentelement.style.fontsize = (window.innerwidth / 750) * 100 + "px"严格对齐，否则编译结果与实际渲染失配导致缩放错误。
SCSS里写px2rem函数，为什么除以100而不是16？
因为100是为750px设计稿+1rem = 100px方案服务的，不是浏览器默认值。你写font-size: px2rem(32)，期望输出0.32rem，那就得让JS运行时把html的font-size设成(window.innerWidth / 750) * 100 + "px"——两边必须对齐，否则算出来是0.32rem，但1rem实际只有16px，缩放就全乱了。
常见错误现象：px2rem(32)编译出0.32rem，但元素在手机上小得看不见，大概率是JS没执行、执行晚了、或被html { font-size: 16px }硬编码覆盖了。
- 别用
16当基准，除非你真按浏览器默认16px做适配（基本没人这么干） - 把基准提成变量：
$rem-base: 100;，函数里用$px / $rem-base * 1rem - 如果设计稿是375px宽，基准可设为
37.5，但函数签名要体现意图：px2rem(32, $base: 37.5)
传入无单位数字（比如14）时，函数会直接报错
SCSS不允许14 / 100 * 1rem这种运算——左边是纯数字，右边是带单位值，类型不匹配。必须先补单位，再约分。
正确做法是用$px / 1px去单位，这是最稳的写法，比unitless()或旧版strip-unit()更可靠。
- 函数开头加判断：
@if unitless($px) { $px: $px * 1px; } - 然后统一走
($px / 1px) / $rem-base * 1rem - 别写
$px / $rem-base——万一$px是14px，结果就是14px / 100，单位还在，后续乘1rem会崩
为什么不能在函数里加@media或JS逻辑？
SCSS是编译期工具，它只管把px2rem(750)变成7.5rem这行静态CSS。屏幕宽度、DPR、用户缩放这些运行时信息，它根本看不到。
有人试图在函数里写@if $dpr > 2 { ... }，这不可能生效——$dpr不是SCSS变量，是JS从window.devicePixelRatio读出来的。
- 媒体查询断点别用
px：@media (max-width: 750px)→ 改成@media (max-width: 7.5rem)（前提是根字号已按比例设好） - border、line-height、伪元素尺寸这些容易漏的地方，必须手动过一遍，函数不会自动帮你扫
- 第三方UI库（如Vant、NutUI）内部用px写的样式，和你的
$rem-base不一致，得单独覆盖
PostCSS插件能替代SCSS函数吗？
可以，但替换的是不同环节：SCSS函数是你主动调用、显式控制；postcss-pxtorem是构建时全局扫描替换，省事但失控。
典型问题：width: calc(100px - 20px)这种表达式，插件只会把两个px分别转，结果变成calc(1rem - 0.2rem)，而SCSS里你可以写calc(px2rem(100) - px2rem(20))，语义清晰。
- 团队若统一用插件，就别混用SCSS函数，否则维护混乱
- 插件配置里的
rootValue必须和SCSS函数的$rem-base严格一致，否则开发环境和构建产物不一致 - 插件对
background: url(xxx.png) 0 0 / 20px 20px这类复合值支持不稳定，SCSS函数反而更可控
真正卡住人的从来不是怎么写函数，而是SCSS编译出的rem值和JS运行时设置的根字号之间那毫厘之差——它不报错，只默默让页面在某些机型上错位一像素，查三天才发现是html样式被重置了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
