为什么CSS rem单位在移动端浏览器中计算异常-css教程-PHP中文网

rem计算异常的根源是根字体大小没对齐，而非rem本身有问题；常见原因包括js动态设置时机太晚、多处覆盖、系统字号干预、viewport缩放干扰，导致媒体查询断点失效、布局错乱及亚像素渲染差异。

为什么css rem单位在移动端浏览器中计算异常

不是 rem 本身有问题，而是你设置的 html { font-size } 和浏览器实际渲染时用的值不一致。常见场景包括：JS 动态设置时机太晚、多处覆盖、系统字号干预、viewport 缩放干扰。一旦基准漂移，所有 1rem、2.5rem 都会按错误比例放大或缩小。

Chrome DevTools 显示 html 的 computed font-size 是 20px，但 JS 里 getComputedStyle(document.documentElement).fontSize 读出来却是 16px？大概率是样式表还没加载完，JS 就执行了
iOS 系统「更大字体」开关打开后，Safari 会强制放大整个页面的根字号（哪怕你 JS 算好了），导致 1rem 实际对应 24px 而非预期的 20px
微信内置浏览器在某些版本中会劫持 document.documentElement.style.fontSize，设了又悄悄改回默认值

因为 rem 在媒体查询中解析时，依赖的是 CSS 加载完成那一刻的 html 字号；而你的 JS 可能 DOMContentLoaded 后才去设置，此时 MQ 已经计算完毕，断点失效。

iPhone 12 上 @media (min-width: 75rem) 没反应，但换成 750px 立刻生效 → 根本原因是 MQ 解析时 html { font-size } 还是 16px，默认值，而非你 JS 后设的 20px
解决方案不是“等 JS 执行完再加 MQ”，而是把基准固化在 CSS 里：html { font-size: calc(100vw / 37.5); }（假设设计稿宽 375px），让 MQ 和元素渲染共用同一套计算逻辑
如果必须用 JS 控制，就把 MQ 断点全换成 em：@media (min-width: 46.875em)（46.875 × 16 = 750），因为 em 在 MQ 中始终相对于浏览器默认字号（16px），更稳定

插件在编译时就把 px 转成 rem，但它不知道你线上运行时 html 的真实 font-size 是多少——它只认配置里的 rootValue。

dmap-jsapi-skill

DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。

下载

配置写 rootValue: 16，但你项目里 JS 设置的是 document.documentElement.style.fontSize = clientWidth / 375 * 20 + 'px' → 所有转换结果系统性偏小 25%
检查 postcss.config.js 中的 rootValue，必须严格等于你最终上线时 html 元素上生效的像素值（单位是 px，不是 rem）
若基准由 JS 动态决定（比如根据 clientWidth 计算），就别用 postcss-pxtorem —— 改用 postcss-plugin-pxtorem 配合 unitToConvert + 自定义函数，或直接放弃编译时转换，用 JS runtime 注入

这不是 bug，是浏览器对亚像素渲染的策略差异：0.3rem × 20px = 6px 是整数，没问题；但 0.3rem × 12px = 3.6px 就要处理小数像素。

Chrome 倾向四舍五入为 4px，Safari 倾向保留 3.6px 并做抗锯齿 → 同一段 CSS，在两台设备上边框粗细/清晰度不同
多个 rem 值叠加（border: 0.1rem + padding: 0.2rem + margin: 0.3rem）会让误差累积，最终偏移 1–2px
避免把 border、outline 这类对精度敏感的属性转成 rem；propList: ['*'] 要禁用，尤其不能开 ['border']

真实项目里最常被忽略的一点：rem 基准不是“设一次就完事”，而是要贯穿 viewport、CSS 加载、JS 执行、用户缩放、系统设置五个环节全程对齐。少一个环节，视觉就偏一点。