postcss-pxtorem 不适合新项目移动端适配，因其静态转换与真机运行时行为不一致：仅构建时转换、不响应横竖屏/缩放/viewport变化，且Android渲染精度差、配置易出错；必须用JS动态设置根字体大小并与构建配置严格对齐。
别用 postcss-pxtorem 做新项目移动端适配 —— 它的静态转换逻辑和真机运行时行为根本对不上，90% 的“变小”“错位”“横屏糊掉”都源于此。
为什么 postcss-pxtorem 在真机上经常失效
它只在构建时做一次转换，不感知运行时环境变化：
- iOS Safari 会在双击缩放、横竖屏切换后重置
document.documentElement.style.fontSize，而插件生成的 rem 值仍按原始rootValue计算 - Android WebView 对
rem的渲染精度不一致，尤其在devicePixelRatio=2.75或3.5的设备上，16px → 0.42667rem这类小数会被截断或四舍五入 - 它完全忽略
viewport的initial-scale变化，而很多安卓浏览器（尤其国产定制版）会强制覆盖该值，导致实际视口宽度 ≠window.screen.width - 控制台查不到报错，但
getComputedStyle(document.documentElement).fontSize返回16px—— 说明 JS 动态设置失败，而 CSS 里的 rem 已按错误基准换算完毕
postcss-pxtorem 的配置陷阱远比你想象的多
默认配置（如 rootValue: 16、propList: ['*']）是多数线上问题的源头：
-
rootValue必须和 JS 动态设置的基准严格一致：若 JS 设置的是html { font-size: 37.5px }，则配置必须为rootValue: 37.5；若设计稿是 750px，想让 1rem = 100px，则rootValue应为75（750 ÷ 10），不是750 / 100 = 7.5 -
replace: true是安全底线 —— 设为false会保留 px 并追加 rem，导致 CSS 权重混乱、调试困难 -
exclude必须排除 UI 库路径（如/node_modules\/vant/），否则 Vant 内部已适配的 px 会被二次转 rem，按钮直接缩成图标大小 -
mediaQuery: true极其危险：媒体查询中的 px 被转 rem 后，断点逻辑失效（比如@media (max-width: 768px)变成@media (max-width: 20.48rem)，而 20.48rem 在不同设备上物理宽度完全不同）
如果非要用，至少让 JS 和 CSS 基准对齐
不能只靠 PostCSS，必须用 JS 动态写入根字体大小，并与构建配置咬死：
立即学习“前端免费学习笔记（深入）”；
- JS 计算必须基于
window.screen.width * window.devicePixelRatio，不是document.documentElement.clientWidth—— 后者受 zoom、scrollbar、iframe 影响，不稳定 - 监听
resize和orientationchange时务必防抖，用setTimeout(fn, 100)，避免高频触发导致fontSize频繁重绘 - 在
<head>最顶部立即执行 JS，防止 FOUC（Flash of Unstyled Content）—— 尤其在慢网下，CSS 加载前 HTML 已按默认 16px 渲染，再改 fontSize 会闪动 - 示例代码（放在
<head>内）：!function(){ function refreshRem(){ const width = window.screen.width * window.devicePixelRatio; document.documentElement.style.fontSize = width / 750 * 100 + 'px'; } refreshRem(); window.addEventListener('resize', () => setTimeout(refreshRem, 100)); window.addEventListener('orientationchange', () => setTimeout(refreshRem, 100)); }();
真正难的不是写几行配置，而是理解：rem 适配的本质是「运行时动态基准」，而 postcss-pxtorem 是「构建时静态映射」。两者强行拼凑，等于让编译器替 runtime 做决策 —— 真机上出问题，从来不是配置没写对，而是这个前提本身就不成立。
