必须同时配 amfe-flexible（运行时动态设根字号）和 postcss-pxtorem（构建时转换单位），缺一不可；前者在main.js顶部引入以确保首屏渲染前生效，后者rootValue需与设计稿基准及Vant适配对齐（推荐37.5），且仅转换构建时CSS源码，不处理行内样式和未过PostCSS的第三方样式。
直接结论：必须同时配 amfe-flexible（运行时动态设根字号）和 postcss-pxtorem（构建时转换单位），缺一不可。只装一个，页面要么不缩放，要么单位没变。
为什么 amfe-flexible 必须在 main.js 里引入？
它不是构建时工具，而是运行时脚本，负责监听设备宽度、DPR，并实时修改 document.documentElement.style.fontSize。不引入，html 的 font-size 就是浏览器默认的 16px，后续所有 rem 计算都失效。
- 必须放在
main.js最顶部（早于 Vue 实例创建），否则首屏渲染时根字号可能来不及生效 - 它内部已处理了
window.onresize和DOMContentLoaded，无需手动写监听逻辑 - 注意：Vant 官方明确要求使用
amfe-flexible或其 fork 版本（如flexible.js），不要用自己手写的rem.js，兼容性差且易漏掉 orientationchange 等事件
postcss-pxtorem 的 rootValue 怎么设才不翻车？
这个值不是随便填的数字，它必须和设计稿基准宽度、以及 amfe-flexible 实际设置的根字号对齐。常见错误是“设计稿 750，就填 75”，结果 Vant 组件被放大一倍——因为 Vant 源码样式基于 375 设计稿，它的 px 值是按 37.5 为基准写的。
vue-composition-api-best-practices
下载
Vue 3 组合式 API 与 最佳实践，涵盖代码组织、useXxx 模式、组合式函数设计、Store 集成、响应式优化及功能抽取。
- 若设计稿是 375px：填
37.5（最稳妥，Vant 默认适配） - 若设计稿是 750px：建议仍填
37.5，并在 Figma/Sketch 中把标注模式切为「375 宽度」，开发时直接照标数值写px；避免填75导致 Vant 组件错乱 - 进阶方案：用函数动态返回
rootValue，例如对vant相关文件返回37.5，其他业务文件返回75，但会增加维护成本，非必要不推荐
哪些地方的 px 不会被 postcss-pxtorem 转换？
它只处理构建阶段解析到的 CSS 源码，对运行时生成的内容完全无感。这意味着：
立即学习“前端免费学习笔记（深入）”；
-
<style>标签内、.css/.scss文件里的px会被转 -
<div :style="{ fontSize: '14px' }">这种绑定的行内样式，px不会被转——得手动写成rem或用calc(14 / 37.5) + 'rem' - 第三方 UI 库（如 Vant）如果用了
require('xxx.css')动态加载，且该 CSS 不经过 PostCSS 流程，则其中的px也不会被转——所以必须确保 Vant 的样式也走同一套构建链路 -
selectorBlackList: ['.ignore-', '.van-']这类配置能排除特定选择器下的属性，但别滥用，容易漏掉需要适配的边框、圆角等
真正难调的不是配置本身，而是当设计师给的是 750 稿、产品经理要求兼容老款 320px 屏、测试又反馈某安卓机 devicePixelRatio 返回 2.75 时，amfe-flexible 的缩放算法是否兜得住——这时候得看它源码里对 Math.min(scale, 2) 的硬限制有没有被绕过，而不是再改一遍 postcss.config.js。
