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谁先读文件、哪些语法它根本不认识、以及缓存没清导致旧错误反复出现。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
