直接用 px 转 rem 容易出错，因为 rem 依赖动态的根元素 font-size，硬编码换算（如除以 16）仅在特定基准下成立；可靠方式需传入设计稿宽度和目标根字号参与比例计算。
为什么直接用 px 转 rem 容易出错
因为 rem 依赖根元素（html）的 font-size，而这个值在不同设备、不同适配方案下是动态的。硬编码换算（比如除以 16 或 100）只在特定基准下成立，一旦设计稿基准变了、或用了 flexible 方案，所有 rem 值就全偏了。
真正可靠的换算必须把「设计稿宽度」和「目标根字号」作为参数参与计算，否则函数只是个假自动化。
- 常见错误：写
rem(32px)→ 内部固定除以 16，结果在 750px 设计稿 +html{font-size:37.5px}下，32px 实际变成0.853rem，但设计师要的是32 / 750 * 100 = 4.266vw或对应rem值 - 正确思路：函数得接收设计稿宽度（如
$design-width: 750）、目标根字号（如$root-font-size: 37.5），再做比例缩放 - SCSS 不支持运行时读取 DOM 的
font-size，所以「自动」仅指编译期按约定规则生成，不是真动态
px-to-rem() 函数怎么写才不踩坑
核心是把换算逻辑和项目适配策略绑定，而不是封装一个“万能转换器”。例如 flexible 方案中，html 的 font-size 是 JS 动态设置的（如 document.documentElement.style.fontSize = clientWidth / 750 * 100 + 'px'），那 SCSS 里就得用同样的 750 和 100 做基准。
推荐定义：
立即学习“前端免费学习笔记（深入）”；
@function px-to-rem($px, $design-width: 750, $root-font-size: 100) {
@return ($px / $design-width * $root-font-size) * 1rem;
}-
$design-width是设计稿宽度（单位 px），必须和前端 JS 适配逻辑一致 -
$root-font-size是你期望在$design-width屏宽下，html的font-size值（单位 px）；例如 flexible 常设为 100，表示 750px 屏宽时根字号 = 100px - 调用示例：
font-size: px-to-rem(32);→ 输出4.26667rem（32/750×100） - 别写成
@function px-to-rem($px) { @return $px / 16 * 1rem; }—— 这等于放弃适配控制权
px-to-vw() 更适合现代响应式布局
vw 单位天然基于视口宽度，不需要 JS 控制根字号，也不受嵌套影响，对字体、间距等多数场景更稳定。只要设计稿是标准宽度（如 750px 或 375px），换算就是纯数学关系。
函数实现更简单，且不易误用：
@function px-to-vw($px, $design-width: 750) {
@return ($px / $design-width) * 100vw;
}- 调用
width: px-to-vw(150);→ 输出20vw（150/750×100） - 如果团队统一用 375px 设计稿，直接设
$design-width: 375，避免每次传参 - 注意：iOS Safari 对小数
vw渲染有精度问题（如0.01666vw），建议配合clamp()或最小阈值处理，但 SCSS 层无法 runtime 判断，需靠设计规范约束输入值 -
vw不适合用于需要绝对尺寸的场景（如 border、阴影模糊值），这时仍得回退到px或rem
混合使用 rem 和 vw 时的关键约束
同一个项目里混用两种单位，最容易在组件复用时出问题——比如一个按钮在 A 页面用 rem 写内边距，在 B 页面被 vw 布局容器包裹，视觉比例就崩了。
- 必须明确分层：字体大小、行高、垂直间距优先用
rem（保持可读性），容器宽高、横向间距优先用vw（保持比例） - 禁止在同一个 CSS 属性里混用单位做计算（如
padding: px-to-rem(20) px-to-vw(30)），SCSS 不报错但语义混乱 - 所有函数统一放在
_units.scss中，并用注释标明适用场景，例如：// 仅用于 font-size，配合 flexible 方案 - 最常被忽略的一点：媒体查询里的
min-width不能用rem或vw做断点，必须用px（浏览器解析媒体查询时单位尚未生效）
