PostCSS 本身不带语法检查，需依赖 stylelint 等插件实现；应优先采用独立 CLI 方式运行 stylelint，并正确配置 customSyntax、缓存及编辑器集成以提升效率与准确性。
PostCSS 本身不带语法检查，得靠插件
PostCSS 只是一个工具平台，它自己不会报错“color: #ff00000写错了”或者“display: flexx拼错了”。真正干活的是插件，比如stylelint——它才是负责语法、规则、可访问性、兼容性等检查的主力。
常见错误现象：npm run build成功但样式没生效，或 CI 里突然报出一堆Unexpected unknown property "disply"；其实问题早就存在，只是没被拦截。
- 必须显式安装并配置
stylelint及其 PostCSS 适配器stylelint-config-standard等 - 不能只装
postcss和autoprefixer就以为能做检查 - Stylelint 不是 PostCSS“内置功能”，它通过
postcss-reporter或直接调用 CLI 接入构建流程
如何让 Stylelint 在 PostCSS 流程中运行
有两种主流方式：一种是作为 PostCSS 插件链中的一环（适合 Webpack/Vite 等集成 PostCSS 的场景），另一种是独立 CLI 运行（更可控、推荐）。
使用场景：你用 Vite + PostCSS 处理 .css 或.pcss文件，想保存即校验；或者团队要求 PR 前必须通过样式 Lint。
立即学习 “ 前端免费学习笔记（深入）”；
- 若走 PostCSS 插件方式，需安装
postcss-reporter并把stylelint加进postcss.config.js的plugins数组——但注意：这仅在 PostCSS 解析阶段触发，不覆盖所有规则（比如文件命名、注释格式） - 更稳的做法是单独配
stylelintCLI，在package.json里加"lint:css": "stylelint "src/**/*.{css,pcss,scss}"" - 务必在
.stylelintrc.js里指定customSyntax: "postcss-scss"（如果用 SCSS 语法），否则会误报@mixin为非法
容易踩的坑：规则冲突、忽略文件、伪类误报
Stylelint 默认规则偏保守，和 PostCSS 实际能力不完全对齐，尤其遇到自定义语法、CSS-in-JS、CSS Modules 时容易误伤。
常见错误现象：Unknown word报在 :global(.btn) 上；no-unknown-animations把 CSS 变量当动画名报错；@layer被标为未知规则。
- 用
stylelint-config-standard时，要手动关掉at-rule-no-unknown，再启用at-rule-no-unknown的增强版stylelint-csstree-validator来支持@layer@container - 通过
ignoreFiles字段或/* stylelint-disable */注释跳过第三方 CSS（如node_modules），否则大量误报 - PostCSS 插件顺序很重要：如果
postcss-nested在stylelint之后，嵌套写法会被当成语法错误——必须保证stylelint在最前或单独跑
性能与编辑器集成的关键配置
本地开发时，没人愿意等 5 秒才看到一个拼写错误提示。Stylelint 默认全量扫描，不加限制会拖慢保存响应。
参数差异：--fix能自动修 color-function-notation 这类格式问题，但修不了逻辑错误（比如 z-index: 99999）；--max-warnings 控制 CI 失败阈值。
- VS Code 用户必须装
Stylelint扩展，并在设置里打开"stylelint.enable": true和"stylelint.autoFixOnSave": true - 在
.stylelintrc.js中加cache: true和cacheLocation: ".stylelintcache"，首次后提速明显 - 避免在
postcss.config.js里传stylelint({fix: true})——这会让构建过程修改源码，破坏 Git 追踪
事情说清了就结束。真正卡住人的，往往不是“能不能配”，而是 stylelint 和postcss谁先读文件、哪些语法它根本不认识、以及缓存没清导致旧错误反复出现。
