优先选vw+postcss-px-to-viewport，次选rem+postcss-pxtorem；纯px仅适用于局部微调或第三方组件兜底。vw天然与视口对齐、无js依赖、避免闪烁抖动，构建时静态转换更可控；rem依赖font-size时机易导致首屏闪动和兼容问题。
直接说结论：优先选 vw + postcss-px-to-viewport，次选 rem + postcss-pxtorem；纯 px 只适合局部微调或第三方组件兜底。
为什么 vw 比 rem 更适合现代 H5 项目
vw 是视口宽度的 1%，天然与屏幕物理尺寸对齐，不需要 JS 动态计算根字体、不依赖 document.documentElement.style.fontSize 的时机，避免首屏闪烁和 resize 重绘抖动。尤其在 Vite/Webpack 构建中，postcss-px-to-viewport 能把设计稿（如 375px 或 750px）的 px 值自动转成 vw，转换逻辑清晰可控。
而 rem 方案依赖 JS 注入时机 —— 如果 rem.js 加载晚于 CSS 渲染，就会出现「先按默认 16px 渲染，再缩放」的闪动；Android WebView 中还可能出现 font-size 设置被忽略的问题。
- vw 单位天生支持 flex 容器内子元素等比缩放，比如
width: 50vw在任何设备上都占一半视口宽 - rem 在嵌套组件中容易因父级
font-size变化导致意外缩放（除非严格限定propList） - vw 不受 root font-size 影响，第三方 UI 库（如 Vant、NutUI）样式更稳定
postcss-px-to-viewport 和 postcss-pxtorem 的关键配置差异
两者都是 PostCSS 插件，但行为逻辑完全不同：
-
postcss-px-to-viewport：以视口宽度为基准换算，核心参数是viewportWidth（如375），输出vw；unitPrecision控制小数位数，selectorBlackList可排除第三方类名（如van-） -
postcss-pxtorem：以根元素font-size为基准换算，核心参数是rootValue（如37.5对应 375 设计稿），输出rem；mediaQuery默认 false，意味着媒体查询里的 px 不会转换 —— 这常被忽略，导致断点失效
注意：postcss-pxtorem 的 rootValue 必须和 JS 动态设置的值一致，否则单位错乱；而 postcss-px-to-viewport 完全脱离 JS，只靠构建时静态分析。
px 并非完全弃用，而是有明确使用边界
纯 px 在以下场景仍不可替代：
- 细线（
border: 1px solid #eee）—— vw/rem 在小屏下会缩得太细甚至消失，需配合transform: scaleY(0.5)或hairline类名 hack - 图标字体（
font-size: 16px）—— 字体大小低于 12px 时 Android 会强制放大，此时 px 更可控 - 第三方组件库的覆盖样式（如
.van-button）—— 避免 rem/vw 改动其内部比例关系 - CSS 动画关键帧中的绝对偏移（
translateX(2px)）—— vw/rem 在动画中可能因视口变化产生跳变
容易被忽略的兼容性细节
vw 在 iOS 8+、Android 4.4+ 全面支持，但旧版 UC 浏览器（UC 11.5 及更早）对 vh 支持异常，vw 相对稳定；而 rem 方案在所有浏览器都可用，但 flexible.js 等老方案已废弃，postcss-pxtorem 生成的 rem 值若小于 0.01rem（即约 0.16px），部分 Android 机型会四舍五入为 0。
真正麻烦的是混合场景：比如用 vw 布局主体，但某处必须用 px 画 1px 边框 —— 这时不能简单写 border: 1px，得结合 devicePixelRatio 动态计算缩放系数，或者用伪元素 + transform 替代。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
