Chrome强制最小字体12px导致rem基准跳变：html设62.5%（预期10px）时，实际取12px，使1rem从10px变为12px，所有rem值系统性偏大20%。
Chrome强制12px最小字号导致rem计算跳变
Chrome对font-size有硬性下限：根元素计算出的font-size若低于12px，浏览器会向上取整到12px，但这个修正只作用于font-size属性本身，不影响其他rem换算——结果就是1rem突然从10px变成12px，所有基于10px基准的rem值集体偏大20%。
常见现象：1.4rem在PC Chrome里渲染为16.8px（预期14px），但实际显示17px；而同一样式在Firefox中仍是14px。这不是四舍五入问题，是基准被篡改后的系统性偏移。
- 检查方式：打开开发者工具，选中
html元素，在Styles面板看Computed里的font-size是否等于你JS动态设置的值（比如10px），还是被悄悄改成12px - 验证方法：临时加一条
body { font-size: 1.2rem; }，如果它最终显示为14.4px而非14px，说明根字号已被拉高 - 规避方案：把JS中设置的
html字号起点定为12px或更高（如12.5px），避免触碰下限；不要用62.5%这种依赖默认16px的写法
IE8及以下完全忽略rem声明，不是“不准”而是“失效”
IE8遇到0.875rem这类值，不是计算错，而是整条CSS规则被丢弃——连带前面的padding、后面的color一并失效。你看到的“偏差”，其实是样式坍塌后的默认渲染。
关键陷阱在于fallback顺序和根字号定义：
立即学习“前端免费学习笔记（深入）”；
-
px值必须严格写在rem值之前，例如font-size: 14px; font-size: 0.875rem;，调换顺序IE8就全盘忽略 -
html { font-size: 62.5%; }在IE6–IE8中行为不可控，部分引擎回退为100%（即16px），导致所有rem换算错乱；必须显式写死html { font-size: 10px; } - 所有用到rem的地方都要配px fallback：
margin、padding、width、height、border都不能漏
Safari与Chrome亚像素渲染策略不一致引发视觉错位
同一段0.3rem代码，在Safari里可能渲染为3.6px（抗锯齿模糊边框），在Chrome里却四舍五入成4px（清晰但偏粗）。这不是bug，是浏览器在“实际值”阶段对小数像素的不同处理路径。
误差会在多层叠加时放大：
- 一个卡片含
padding: 0.5rem+border: 0.05rem+margin-bottom: 0.3rem，三者小数累加后可能偏移1–2px - 设计稿按750px宽、基准设为75px时，1px =
0.0133rem，这种极小单位在缩放中极易失真 - 用
transform: translateY(-0.3px)微调位置比改margin-top更可靠——前者走合成层，精度到0.1px；后者参与layout，照样被舍入
postcss-pxtorem的rootValue配置错位引发全量偏差
插件默认以rootValue: 16为基准，但如果你项目里html实际生效的是20px，那它就会把1px错误转成0.0625rem（应为0.05rem），所有尺寸系统性偏大25%。
更隐蔽的问题是JS动态设置根字号时，编译时转换根本无法匹配运行时真实值：
- 检查
postcss.config.js中的rootValue，必须等于线上html标签最终生效的font-size值（单位是px） - 若用JS根据
clientWidth动态算font-size，就别用postcss-pxtorem——改用postcss-plugin-pxtorem配合unitToConvert和自定义函数，在构建时注入运行时基准 - 禁用
propList: ['*']，尤其不要把border转成rem：1px边框转成0.05rem后，在2x屏上可能渲染为0.1px，直接不可见
