rem 在 sass 中不能用 calc() 动态计算，因 calc() 是运行时 css 函数，而 sass @function 在编译期执行，二者阶段不同；px2rem 应避免递归、统一基准 16px、保留一位小数；多端适配靠 js 或媒体查询控制根字号，sass 仅静态换算；postcss-pxtorem 更可靠，需确保 rootvalue 与 js 设置一致。
为什么 rem 在 Sass 里不能直接用 calc() 动态算？
因为 calc() 是运行时 CSS 函数，而 Sass 的 @function 在编译期就执行完毕，两者不在同一阶段。你写 calc(100vw / 375 * 16) 看似灵活，但 Sass 根本不会等浏览器去算——它要么报错（语法不识别），要么原样输出，失去预处理意义。
- 真正能用的只有编译期可确定的数值：设备宽度、基准像素、设计稿尺寸这些必须写死或通过变量传入
- 如果想“动态”，得靠 JS 注入根字体大小，Sass 只负责把
px换成对应比例的rem，别越界 - 常见错误是把
100vw当作 Sass 变量参与运算，结果编译失败或输出无效 CSS
px2rem() 函数怎么写才不掉精度、不爆栈？
Sass 递归函数容易在大数值或小数位多时触发编译器栈溢出（Stack level too deep），尤其当设计稿用 375px 宽、字号又常带小数（如 13.5px）时。
- 避免递归：用
@return $px / $base-font-size + rem直接除，别写循环或条件嵌套计算单位 - 统一基准：约定
$base-font-size: 16px（对应 1rem），所有转换基于此，不随 media query 变动 - 保留一位小数：用
round($val * 10) / 10控制输出精度，防止生成1.234567rem这类无意义长数 - 示例：
@function px2rem($px) { @return round($px / 16 * 10) / 10 + rem; }
多端适配不是靠 Sass 算出来的，而是靠根元素控制的
Sass 本身没有“检测 iPhone”或“判断是 PC”的能力，所谓“多端”，实际是靠 JS 或媒体查询设置 html 的 font-size，Sass 只做静态换算。
- 移动端常用 JS 方案：
document.documentElement.style.fontSize = window.innerWidth / 375 * 16 + 'px'; - PC 端可加媒体查询兜底：
@media (min-width: 768px) { html { font-size: 16px; } } - 别在 Sass 里写
@if $device == 'mobile'这种伪逻辑——它编译出来就是固定值，起不到响应作用 - 验证是否生效：打开 DevTools，看
html元素 computed 的font-size是否随窗口缩放变化
PostCSS 插件比手写 Sass 函数更靠谱？
如果你项目已用 Webpack/Vite，且需要兼容旧版 iOS Safari（对 rem 计算有 bug），硬靠 Sass 函数反而增加维护成本。
立即学习“前端免费学习笔记（深入）”；
-
postcss-pxtorem能自动把所有px转rem，支持 exclude 规则（比如跳过第三方 UI 库） - 它运行在 CSS 字符串层面，不依赖 Sass 变量结构，也不怕嵌套深度
- 注意配置项：
rootValue必须和 JS 设置的基准一致（比如 16），否则换算错位 - 错误现象：按钮文字忽大忽小、间距错乱——大概率是
rootValue和 JS 设置的font-size不匹配
实际最难的从来不是写一个 px2rem()，而是让 JS 设置的根字号、设计稿标注的像素值、以及你写的 Sass 函数三者始终对齐。漏掉任意一环，rem 就会变成“看起来适配，实则错位”。
