postcss-mobile-forever 仅在统一按指定设计稿宽度（如375px）写px、构建时静态转vw的场景下有效，不解决缩放本质问题，无运行时JS，不支持DPR适配与系统字体缩放，配置错误易致白屏或错位。
postcss-mobile-forever 不是“推荐使用”，而是只在特定场景下真正有效：你写 px，它在构建时转成 vw（或配合媒体查询），浏览器运行时零成本。但它不解决“缩放问题”本身，只解决“单位映射失准”——这点必须先厘清。
为什么它看起来像解决了缩放问题？
因为你在设计稿上量出 150px，在 375px 宽的手机上显示刚好；但换到 414px 屏，150px 就变小了。而 postcss-mobile-forever 把它算成 40vw（即 414 × 0.4 = 165.6px），视觉尺寸就接近一致了。
关键点在于：它依赖你统一按一个设计稿宽度（如 viewportWidth: 375）来写样式，所有换算都基于这个基准。不是动态感知设备宽，而是静态映射。
- 如果你的设计稿是 750px，但配置里写了
viewportWidth: 375，所有转换结果都会放大 2 倍，页面直接撑爆 - 它不处理 DPR（设备像素比），高 DPR 屏幕下文字/边框可能发虚，得靠
image-set()或@supports (-webkit-appearance: none)单独补 -
mediaQuery: true开启后会生成多组断点规则，但只覆盖常见宽度（如 320/375/414/768），非标准屏（比如折叠屏半开态）不会额外适配
和 postcss-pxtorem + lib-flexible 的核心区别在哪？
postcss-pxtorem 是“构建期转 rem + 运行时 JS 动态设 html.font-size”，有两段逻辑；而 postcss-mobile-forever 是“纯构建期转 vw”，没 JS、没运行时干预。
立即学习“前端免费学习笔记（深入）”；
这意味着：
- 你删掉所有 JS 适配代码（比如
flexible.js或手动计算font-size的脚本），它照样生效 - 不兼容需要
rem做精确控制的场景（例如动画中用rem控制 easing 曲线节奏） - 如果项目里已用
rem做了字体分级体系（如h1: 2rem,p: 1rem），混用postcss-mobile-forever会导致单位混乱
哪些地方容易配错导致白屏或错位？
最常见的三个配置坑：
-
viewportWidth必须和设计稿原始宽度完全一致，不能四舍五入（比如设计稿导出是 375.2px，你就得写375.2，写375会导致整体偏差 0.05%） -
unitPrecision默认是6，但某些 CSS 压缩工具（如cssnano）会把4.266667vw截成4.26667vw，再压缩成4.26667vw→4.26667vw，小数位丢失引发累计误差 -
selectorBlackList如果漏加第三方 UI 库的选择器（如van-button、uni-button），它们的内建px值也会被转，按钮尺寸可能异常
它真能“永久适配”吗？
不能。“forever”只是营销词，实际只保证：只要屏幕宽度落在插件预设的媒体查询区间内，且你没手动写死 px 覆盖，就能维持比例一致。
真正不可控的点藏在底层：
- iOS Safari 对
vw的解析在横屏切换瞬间有延迟，可能出现闪动 - 部分安卓 WebView（尤其旧版 UC）对
min(vw, px)函数支持不全，需降级为媒体查询分支 - 当用户强制放大系统字体（设置 > 显示与亮度 > 字体大小），
vw布局不会响应，而rem方案可通过html的font-size继承系统缩放
这些细节不报错、不警告，只在真机上偶然出现——最容易被忽略。
