vw/vh 可完全取代 rem，但必须配合 postcss-px-to-viewport 在构建时转换；它将 px→vw 计算提前至打包阶段，消除运行时 js 依赖，仅作用于 css 文件，静态转换、零开销，viewportwidth 必须与设计稿宽度严格一致。
vw/vh 能完全取代 rem，但必须配合 postcss-px-to-viewport 在构建时转换，不能靠运行时 JS 计算。 它不是“换种写法”，而是把 px 到视口单位的计算提前到打包阶段，彻底去掉对 flexible.js 或动态 document.documentElement.style.fontSize 的依赖。
为什么 postcss-px-to-viewport 是 vw 方案的核心？
浏览器原生支持 vw，但没人会手动写 width: 5.333vw——太反人类。插件的作用就是：你照常写 width: 20px，它在构建时按设计稿宽度（比如 viewportWidth: 375）自动算出等效的 vw 值并替换。
- 转换公式固定：
1px → (100 / viewportWidth) vw，例如 375 设计稿下，1px = 0.26667vw - 只作用于 CSS 文件，不侵入 JS 逻辑，也不触发重排重绘
- 所有转换结果都是静态值，无运行时开销，比 rem 的 JS 动态设置更轻量
- 不处理 HTML 或 JS 中的 px 字符串（如内联 style、JS 拼接样式），仅限 CSS AST 层面
viewportWidth 必须和设计稿宽度严格一致
这个值不是屏幕物理宽度，也不是设备像素，而是设计师给你的 PSD/Figma 文件的画布宽度。设错会导致整体缩放失真。
- 常见取值：
375（iPhone SE/8）、750（@2x 设计稿）、1920（桌面端大屏设计稿） - 如果设计稿是 750px，但你配成
viewportWidth: 375，所有尺寸会放大 2 倍 - 同一项目不能混用多个
viewportWidth，否则不同组件间比例不一致 - 不要试图用 JS 读取
window.screen.width来动态配这个值——它在构建时就固化了
哪些地方容易被误转？用 selectorBlackList 和 propList 精控
不是所有 px 都该转成 vw。边框、阴影、字体粗细、某些固定像素图标，转了反而失真。
-
selectorBlackList: ['.ignore', '.no-viewport']：匹配到的类名下所有声明都不转，适合包裹全局禁用区域 -
propList: ['font-size', 'width', 'height', 'padding', 'margin']：只对列表里的属性生效；设为['*']表示全开，但慎用 -
minPixelValue: 1：小于等于 1px 的值（如border: 0.5px solid #ccc）默认不转，避免出现0.00133vw这种无效值 -
mediaQuery: false：默认不转换媒体查询里的 px（如@media (max-width: 768px)），因为媒体查询条件本身是设备特性，不该随视口缩放
unitPrecision 和小数点误差的实际影响
转换后保留几位小数，直接影响最终 CSS 体积和渲染精度。它不是“越精确越好”。
- 设为
5（默认）：1px → 0.26667vw，精度高，但可能生成大量重复小数，CSS 文件略大 - 设为
3：1px → 0.267vw，人眼几乎不可辨，文件体积下降约 8%～12% - 设为
0：全部四舍五入到整数 vw，1px → 0vw，直接失效，绝对不要这么干 - 真正影响布局的是连续多个小数误差的累积，比如 20 个元素各差 0.001vw，在 4K 屏上可能偏移 1px+
实际项目中，unitPrecision: 4 是平衡点：足够准，又不至于让 CSS 膨胀。别迷信“保留 6 位”，构建工具不会帮你做额外优化。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
