rem错位源于系统字体缩放改写根字号计算值，导致媒体查询失效、亚像素渲染不一致及clamp()循环依赖；需用px设clamp下限、反推vw系数，并以computed font-size为准校验。
rem 错位不是单位本身的问题，而是你设的根字号没扛住缩放——浏览器尊重系统字体设置，html { font-size: 62.5% } 这类声明只是“建议”，不是锁定。
系统字体缩放直接改写根字号计算值
你在 CSS 里写 html { font-size: 100px }，但 iOS「最大动态类型」开启后，实测 getComputedStyle(document.documentElement).fontSize 可能是 142px。这不是 bug，是浏览器在按系统策略重算。62.5% 同理：它基于默认 16px，系统改成 28px，62.5% 就变成 17.5px，不是你预期的 10px。
- 所有依赖
rem的尺寸（padding、margin、top）都按这个被改写的值重新计算 - 媒体查询里的
@media (min-width: 40rem)会失效——断点计算发生在根字号最终确定前，基准已漂移 - 第三方 UI 库可能悄悄重设
html字号，DevTools 的 Computed 面板里看font-size才是真实值
小数 rem 渲染时亚像素插值不一致
0.3rem × 12px = 3.6px 这种计算结果，Chrome 可能四舍五入为 4px，Safari 保留 3.6px 做抗锯齿，同一段 CSS 在不同设备上边框粗细、间距松紧就对不上。
- 误差在多层叠加时放大：比如
padding: 0.5rem+border: 0.1rem+margin: 0.3rem，总偏差可达 1–2px -
postcss-pxtorem若rootValue设为16，但线上html实际是20px，所有转换结果系统性偏大 25% - 伪元素边框、卡片列表底部缝隙，往往就是这种亚像素对不齐漏出的背景
clamp() 下限必须用 px，不能用 rem
写成 font-size: clamp(1.2rem, 2.666vw, 16px) 是错的——第一个参数 1.2rem 会回溯当前未稳的根字号，形成循环依赖。它兜不住底。
- 正确写法是
font-size: clamp(12px, 2.666vw, 16px)，下限铁板钉钉为 12px，确保1rem ≥ 12px - 系数要反推：若设计稿 750px 对应 100px，希望最小视口 240px 下仍保 12px，则
vw系数 =12 / 240 × 100 = 5，即clamp(12px, 5vw, 16px) - 别在
@media里再套clamp()，冗余且旧版 Safari 可能直接忽略整个声明
真正难处理的不是单个 rem 值，而是它和 position: absolute、transform、第三方库的 px 样式混用——缩放时各算各的基准，错位是必然的。校验点不在代码写得有多漂亮，而在 DevTools 里盯着 html 的 computed font-size 和 offsetTop 看它到底有没有变。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
