Stylelint命令不识别主因是全局安装未配PATH或未加-g，推荐统一用npx stylelint执行；配置文件需正确设置extends和rules优先级，关闭规则用null而非false；自动修复仅限fixable规则；CI中glob路径需显式列出避免兼容问题。
Stylelint装完为什么stylelint命令不识别
常见错误是全局安装但没配PATH，或用npm install没加-g。Node.js的npx能绕过路径问题，推荐统一用npx stylelint执行，避免环境差异。
使用场景：CI/CD里跑检查、本地pre-commit钩子、编辑器保存时触发——这些都依赖命令可被直接调用。
- Linux/macOS下确认
which stylelint有输出；没有就重装：npm install -g stylelint - Windows用户更建议始终用
npx stylelint，避免PowerShell和CMD对全局bin路径处理不一致 - 如果项目里用了pnpm，别用
pnpm add -g，它不支持全局安装，必须用npm install -g
配置文件.stylelintrc.js怎么写才不踩坑
Stylelint默认不带任何规则，全靠配置驱动。空配置=没效果，但照搬社区preset（比如stylelint-config-standard）又容易和项目实际脱节。
参数差异关键在extends和rules的优先级：后者会覆盖前者，但只覆盖同名规则，不会继承未声明的规则。
立即学习“前端免费学习笔记（深入）”；
- 起步推荐从
stylelint-config-standard开始，再按需关掉几条（比如declaration-block-trailing-semicolon设为null） - CSS-in-JS项目（如Emotion、Styled Components）必须加
stylelint-config-standard-scss或对应插件，否则color等属性报错 - 配置里写
"rules": { "no-empty-source": null }是关闭规则，不是false或0，错写成布尔值会导致整个配置加载失败
VS Code里保存自动修复stylelint --fix为什么只修一半
自动修复能力受限于规则本身是否支持修复（fixable）。Stylelint官网每条规则文档末尾都标了✅或❌，比如color-hex-case可修，selector-max-id不可修。
性能影响明显：开启太多非fixable规则会让保存变卡，尤其大文件；而过度依赖--fix可能掩盖语义问题（比如把margin: 10px 0强行转成margin: 10px 0 10px 0并不合理）。
- 编辑器插件要选
Stylelint（作者stylelint.vscode-stylelint），别装错成老版本stylelint-plus - 在
settings.json里确保"stylelint.enable": true且"editor.codeActionsOnSave": { "source.fixAll.stylelint": true } - 如果某条规则总报错但不修复，先查文档确认是否标记为
fixable: false，别硬调参数
CI里跑npx stylelint "**/*.css"报错路径不匹配
错误现象通常是No files matching the pattern were found.，本质是glob路径在不同shell下解析行为不同：zsh默认不展开**，bash需要shopt -s globstar，而CI环境（如GitHub Actions）多数用busybox shell，压根不支持**。
兼容性影响比想象中大：本地OK的命令，在GitLab CI或自建Jenkins上大概率失败。
- 最稳写法是用
npx stylelint "src/**/*.css" "src/**/*.scss" "src/**/*.less"，显式列出目录，避开glob - 或者换工具：
npx stylelint --config .stylelintrc.js $(find src -name "*.css" -o -name "*.scss") - GitHub Actions里可加
shell: bash指定解释器，但不如直接规避**可靠
Stylelint本身不处理CSS语法错误（比如漏括号、非法值），那是PostCSS解析层的事；一旦解析失败，规则根本不会运行。所以看到大片报错，先检查是不是/*注释没闭合，或用了浏览器还没实现的新函数（如color-mix()）导致PostCSS卡住。
