Stylelint本身不监听Git hooks，提交前自动修复需依赖Husky+lint-staged+Stylelint组合：Husky注册pre-commit钩子，lint-staged筛选暂存文件并执行stylelint --fix，再通过git add暂存修复结果，仅官方标记✅的格式规则（如indentation、string-quotes）可生效。
Stylelint 无法在 Git 提交时自动修复 CSS 格式错误 —— 它不监听 git hooks，也不内置 pre-commit 集成能力；你看到的“提交前修复”，本质是手动或借助工具（如 Husky + lint-staged）触发 stylelint --fix 命令。
为什么直接配 stylelint --fix 到 commit 不生效
Git 本身不会调用 Stylelint，也不会识别你的配置文件或规则。所谓“提交时修复”，必须靠外部流程介入：
- Stylelint CLI 是纯校验/修复工具，
--fix只改文件内容，不挂钩子、不拦截 commit - 若没配任何脚本，
git commit过程中 Stylelint 完全不运行，更别说修复 - 即使项目有
.stylelintrc.js和可修复规则，没命令触发 = 零效果
真正可行的 pre-commit 自动修复链路
必须组合三方工具：Husky（注册 hook）+ lint-staged（只处理暂存区文件）+ Stylelint（执行修复）。缺一不可：
- 安装依赖：
npm install --save-dev husky lint-staged stylelint - 初始化 Husky：
npx husky install，并确保package.json中有"prepare": "husky install" - 添加 hook：
npx husky add .husky/pre-commit "npx lint-staged" - 配置
lint-staged（package.json内）："lint-staged": { "*.{css,scss,less,vue}": ["stylelint --fix", "git add"] } - 关键点：
git add必须跟在stylelint --fix后——否则修复后的变更不会进入暂存区，commit 仍会包含原始错误
哪些规则会在提交时被真正修复
仅限 Stylelint 官方标记为 ✅ 的格式类规则，且需在配置中显式启用（值不能为 null 或 false）：
-
color-hex-case（如#ff0000→#FF0000） -
declaration-block-trailing-semicolon（补/删末尾分号） -
indentation（空格缩进，但嵌套块内可能错位） -
string-quotes（统一单/双引号） -
declaration-colon-space-after（冒号后加空格） - 注意：
order/properties-order需额外装stylelint-order插件才生效，且仅当规则值为数组形式（非true）时参与--fix
容易被忽略的破坏性风险
自动修复不是无害操作，尤其在提交环节：
-
--fix会直接写入文件，如果团队成员本地没跑过stylelint --fix，可能造成 diff 爆炸（比如全文件缩进重排） - 嵌套语法（SCSS/LESS）必须配
customSyntax: "postcss-scss"，否则lint-staged传入的 .scss 文件会被当普通 CSS 解析，修复失效甚至误改 - Vue SFC 中的
需在lint-staged匹配项里明确写*.vue，且配置中stylelint-config-recommended-vue和customSyntax缺一不可 - 修复后未
git add就 commit，会导致修复白做——这是最常被跳过的一步
真正要让提交时修复可靠，核心不在 Stylelint 本身，而在 lint-staged 的文件匹配精度、customSyntax 的语法覆盖完整性，以及 git add 是否紧随其后。漏掉任一环，都只会看到“好像没反应”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
