VS Code本身不提供Husky插件，Husky是独立CLI工具，依赖Git Hooks在shell中运行；其pre-commit是否生效取决于.husky/pre-commit文件存在性、可执行权限、Git初始化状态及lint-staged的glob匹配与自动add闭环。
VSCode 本身不提供 Husky 插件，也不需要“安装 Husky 插件”——Husky 是一个 CLI 工具，靠 Git Hooks 在 shell 中运行，和 VSCode 的插件系统完全无关。 你看到的所谓“Husky 插件”要么是误导性命名，要么是功能重叠的辅助工具（如 commitlint 提示），但真正起效的 pre-commit 检查，只取决于 .husky/pre-commit 脚本能否被 Git 正确调用、以及 lint-staged 是否能识别并处理暂存文件。
pre-commit 钩子没触发？先检查 .husky/pre-commit 文件权限和存在性
Git 只会执行 .git/hooks/pre-commit 或通过 Husky 设置的代理脚本，而不会读取 VSCode 里的任何设置。常见断点：
-
.husky/pre-commit文件必须存在，且在 macOS/Linux 下需有可执行权限：运行chmod +x .husky/pre-commit - 项目根目录下必须有
.git目录；若刚初始化，先git init再npx husky install - Windows 用户用 Git Bash 时，
.husky/pre-commit若含 CRLF 换行符，shell 可能解析失败 —— 用 VSCode 打开该文件，右下角切换为 LF，保存 - 如果用了
pnpm，npx lint-staged可能找不到本地二进制，需在.husky/pre-commit开头加：export PATH="./node_modules/.bin:$PATH"
lint-staged 匹配不到你的 .tsx 或 .vue 文件？glob 模式要显式声明
lint-staged 的 glob 是按 Git 暂存路径匹配的，不是当前工作目录，也不是 VSCode 当前打开的文件。常见失效原因：
用大白话操作当前项目的 Git/GitHub——配置 GitHub（装 gh CLI + 登录 + 建仓库）、备份、拉取下载、查询历史、回滚代码、管理分支。当用户用日常语言表达 git 意图时触发（例如"git备份一下""git下载项目""git拉下来""git看看我改了啥""git回退到上一个版本""git新建个分支搞新功能""git合并到主分支""git
-
"*.{js,ts}"不会匹配src/index.tsx—— 必须写成"*.{js,ts,tsx}" -
.vue文件默认不被 ESLint 处理，需单独配置："*.vue": ["eslint --fix", "prettier --write"] - 配置写在
package.json里时，字段名必须是"lint-staged"（全小写），拼成lintStaged或LintStaged会静默失效 - 若在子目录执行
git commit，lint-staged仍以项目根为基准读取配置，但 glob 匹配的是相对暂存路径（如src/App.tsx），不是绝对路径
格式化后文件没进提交？关键在 lint-staged 的自动 git add 行为
lint-staged 默认会在每个任务成功执行后自动 git add 修改的文件，但这个行为极易被破坏：
- 某个任务报错（比如
eslint --fix遇到语法错误退出码非 0），后续git add就不会触发 - 不要手动在配置里加
"git add"命令 —— 这会导致命令顺序混乱，甚至因路径问题失败 - 验证是否生效：改一个
.js文件 →git add→git commit→ 提交成功后立刻运行git status，看该文件是否仍在Changes to be committed区域 - 如果你用了自定义脚本（如
"*.js": ["npm run fix:js"]），确保该脚本内部不阻塞、不静默失败，且最终输出是可被lint-staged捕获的 exit code
真正卡住的地方，从来不是 VSCode 设置，而是 .husky/pre-commit 能否稳定调起 npx lint-staged，以及 lint-staged 是否能准确识别暂存文件、完成修复 → 写入 → git add 的闭环。每一步都得实打实验证，不能只看终端有没有输出。
