应优先选用stylelint搭配postcss-reporter，因其规则细致、支持自定义性能规则（如禁用触发布局的hover、限制!important频次），并可导出JSON/HTML供CI阈值拦截；需手动启用stylelint-performance插件及对应规则，且须将其集成进PostCSS配置链路而非单独运行。
PostCSS插件怎么选：先盯住postcss-reporter和postcss-lint类工具
PostCSS本身不带审查能力，得靠插件补上。真正能跑起来做样式性能扫描的，目前稳定可用的就两类：postcss-reporter（配合其他插件输出结果）和更具体的postcss-lint、stylelint（后者虽非PostCSS原生，但通过postcss-stylelint可接入）。别被名字带偏——postcss-cssnext或postcss-preset-env这类编译型插件完全不参与审查。
实操建议：
- 用
stylelint为主力，它规则细、社区更新勤，且支持自定义性能规则（比如禁止* + *选择器、限制!important频次） - 搭配
postcss-reporter把结果导出为JSON或HTML，方便CI里做阈值拦截 - 避免直接用已归档的
postcss-bem-linter——它只管命名，不查重绘、不看层叠深度
哪些CSS问题真会影响性能：聚焦重排重绘和层叠开销
审查不是挑语法毛病。真正拖慢渲染的，是那些浏览器在布局/绘制阶段反复计算的东西。PostCSS插件能抓到的典型隐患包括：
-
:hover里改width/height/top等触发重排的属性（应改transform或opacity） - 选择器层级超过4级（如
.layout .header .nav .item a），导致匹配变慢 - 大量使用
@import嵌套引入CSS文件（会阻塞并串行加载，应改用postcss-import预处理） -
background: url(...)路径失效或404（插件可配合postcss-url校验，但需手动开启url: { failOnWarning: true }）
配置容易漏掉的关键开关：stylelint的performance规则集要手动启用
stylelint默认规则不包含性能检查，必须显式加载插件包并启用对应规则。常见疏忽是只装了stylelint主包，没装stylelint-performance或没在.stylelintrc里配plugins: ["stylelint-performance"]。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 安装：
npm install stylelint stylelint-performance --save-dev - 配置中加规则：
"performance/no-activating-hover"（禁用触发布局的hover）、"performance/no-unnecessary-initial"（避免冗余initial值） - 注意
stylelint-performance不支持PostCSS 8.4+的某些新AST结构，若报Cannot read property 'raws' of undefined，退回stylelint@15.10.0更稳
CI里跑审查：别让postcss流程绕过stylelint
很多人把PostCSS配置写在postcss.config.js里，却把stylelint单独当脚本跑，结果构建时样式照常编译，隐患照旧上线。审查必须和编译链路对齐，否则等于没审。
实操建议：
- 用
postcss-stylelint插件，把它塞进postcss.config.js的plugins数组最前面，确保所有CSS源文件过一遍规则 - CI脚本里别只跑
postcss src/*.css -o dist/，加一句npx stylelint "src/**/*.css" --fix并设--max-warnings 0来卡住高危项 - 如果项目用Webpack，
css-loader前加stylelint-webpack-plugin，比单独跑脚本更能捕获import './xxx.css'里的问题
样式审查真正的复杂点不在插件怎么装，而在判断“这个警告值不值得阻断构建”。比如selector-max-specificity设成0,2,0很安全，但可能逼你把所有BEM修饰符改成data-属性——这时候得权衡是改规则，还是改组件封装方式。
