根本原因是sass 1.65+内置rem()函数强制双参数（如rem(300, 16px)），旧单参数写法报错；且scss编译时的基准值必须与js运行时设置的html font-size完全一致，否则换算结果偏差可达20%。
根本原因不是函数写错了，而是 rem 值在编译时算出来的数字，和运行时浏览器实际渲染的根字号对不上——两者差 1px，最终可能偏 20%。
rem() 函数在 Sass 1.65+ 必须传两个参数
Sass 自 1.65.0 起把内置 rem() 改成双参数：必须显式写 rem(300, 16px)，旧写法 rem(300) 直接报错 “2 arguments required”。它不再默认按 16px 换算，就是为了防止你误以为“写了 rem 就一定准”。
- 如果你项目里 html 的
font-size是 JS 动态设的20px，但函数里还用rem(300, 16px)，那编译出的18.75rem实际对应的是18.75 × 20 = 375px，而不是你想要的 300px - 更隐蔽的问题是：你在 SCSS 里用变量存基准，比如
$root-font-size: clamp(14px, 1rem, 18px)，但rem()不接受这种带函数的值，只能传静态单位值（如16px） - 别试图覆盖内置
rem()—— 官方明确不推荐，容易和未来版本冲突
SCSS 编译期换算 vs JS 运行时设置的根字号
SCSS 所有 rem 计算都在构建时完成，生成的是固定字符串，比如 font-size: 1.875rem。它完全不知道你上线后 JS 会把 html 的 font-size 设成 12px 还是 24px。
- 检查线上
html元素的 computed style，确认font-size真实值（右键审查元素 → Computed → font-size） - 这个真实值必须和你在 SCSS 中用于换算的基准完全一致；若 JS 设的是
document.documentElement.style.fontSize = clientWidth / 375 * 20 + 'px'，那所有 SCSS rem 计算就得按20px基准来 - 用
postcss-pxtorem的话，rootValue配置项也得等于这个真实值（单位是px），否则所有转换系统性偏大或偏小
小数 rem 渲染时被浏览器四舍五入或亚像素插值
哪怕换算完全正确，0.3rem 在 12px 基准下就是 3.6px。浏览器无法画出 0.6 像素，只能插值或舍入——Chrome 可能当 4px，Safari 当 3.6px 抗锯齿，结果就是边框粗细不一、卡片底部漏白。
- 高频出问题的场景：伪元素边框拼接、tab 下划线、轮播指示器对齐、多层
padding + margin + border叠加 - 解决方向不是“让 rem 更准”，而是“不让它落到 subpixel”：用
clamp(12px, 13.333vw, 16px)锁住最小根字号，确保0.1rem ≥ 1.2px - 已出现缝隙时，优先用
transform: translateY(-0.3px)微调，别用margin-top: -0.3px—— 后者仍参与 layout，照样被舍入
最常被忽略的一点：媒体查询里写 @media (min-width: 40rem)，其实非常危险。因为此时 html 的 font-size 可能还没被 JS 设置，或者被其他 CSS 覆盖，导致断点计算失准。直接改用 em 或 px 断点更稳。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
