rem媒体查询失效的根本原因是html根元素font-size被多处覆盖或动态修改，导致计算基准不一致；应统一且仅在html上设置固定基准，媒体查询断点需严格匹配该基准，避免JS动态改、缩放干扰及插件配置错误。
rem 基准值被多处覆盖，导致媒体查询失效
浏览器计算 rem 时，只认根元素（html）的 font-size。但很多人在 CSS 里用 JS 动态改、用媒体查询嵌套改、甚至在不同文件里重复设，结果后写的覆盖前写的，媒体查询里用的 rem 值和实际渲染时不一致。
常见错误现象：@media (max-width: 750px) 没触发，但把单位换成 px 就立刻生效；或者页面缩放后布局突然错乱。
- 统一在
html标签上设置基准，且只设一次——推荐用纯 CSS 方案，避免 JS 注入时机问题 - 媒体查询中的断点值必须和基准换算逻辑严格对应：比如你设
html { font-size: 10px; }，那750px就该写成75rem - 别在媒体查询内部再改
html的font-size，否则后续所有rem计算都会漂移
viewport 缩放干扰 rem 像素精度
移动端 Safari 和部分安卓 WebView 在双指缩放后，会临时改变设备像素比（window.devicePixelRatio），但不重排 html 的 font-size，导致 1rem 对应的实际物理像素变模糊，媒体查询边界出现“半像素卡顿”。
使用场景：用户缩放网页后，原本在 750px 切换的响应式布局，可能要拖到 752px 才触发。
立即学习“前端免费学习笔记（深入）”；
- 强制禁止用户缩放：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">（仅限非可访问性敏感场景） - 若需支持缩放，改用
em或px写媒体查询断点，rem仅用于组件内尺寸 - 避免用
calc(100vw / 37.5)这类视口除法动态算基准——它在缩放时会产生浮点误差累积
postcss-pxtorem 插件输出的 rem 值不准
这个插件默认把 16px 当作 1rem，但如果你项目里 html 的基准是 10px，它就会把 16px 转成 1.6rem，而实际需要的是 1.6rem × (16/10) = 2.56rem，直接导致所有转换结果偏小。
参数差异：关键看 rootValue 配置是否和运行时 html 的 font-size 完全一致。
- 检查插件配置里的
rootValue，必须等于你最终上线时html标签上生效的font-size值（单位是 px） - 如果基准是 JS 动态设置的（如根据屏幕宽度算），就别用这类编译时转换插件，改用
postcss-plugin-pxtorem的unitToConvert+ 自定义函数 - 开启插件的
propList选项时小心：把border也转成 rem 后，1px 边框在高清屏上可能变成 0.1rem，直接不可见
字体抗锯齿让 rem 实际占位偏离预期
CSS 中 font-size: 1.4rem 看似精确，但字体渲染引擎会根据当前 devicePixelRatio 和子像素对齐策略微调真实高度，尤其在 macOS 上启用抗锯齿后，1rem = 10px 可能实际占 10.2px，连续叠加多个 rem 元素后，容器总高偏差可达 2–3px，刚好卡在媒体查询临界点附近。
性能影响：这种偏差无法通过 JS 获取，也无法用 getBoundingClientRect() 精确预测，只能规避。
- 媒体查询断点尽量避开「易卡住」的值，比如不用
750px，改用748px或752px（对应74.8rem/75.2rem） - 对齐关键容器（如页头、导航栏）优先用
flex或grid的内在对齐能力，少依赖 rem 累加高度 - 测试时务必在真机上验证，模拟器和桌面 Chrome DevTools 的像素对齐行为和真实设备不一致
rem 的精度问题从来不在单位本身，而在「谁控制了 html 的 font-size」和「谁在读取这个值」——这两者之间只要存在任意一个异步、覆盖或渲染时机差，像素就一定会漂。盯着那个 html 标签，把它当成唯一信源，其他地方全是副本。
