VSCode本身不执行提交检查，真正起作用的是husky + lint-staged + eslint/prettier组合；需确保husky初始化、lint-staged规则匹配暂存文件、所有工具本地安装且配置文件置于项目根目录，否则提交将静默跳过检查。
直接上结论：VSCode 本身不执行提交检查，真正起作用的是 husky + lint-staged + eslint/prettier 这套组合。配置错一个环节，比如 husky 没初始化、lint-staged 规则没匹配到文件、或 ESLint 本地没装，提交就会静默跳过检查。
pre-commit hook 怎么触发 lint-staged
关键不是 VSCode 点“提交”按钮那一刻才运行，而是 Git 执行 git commit 命令时，由 Husky 拦截并调用 lint-staged。VSCode 的提交界面只是封装了这个命令。
-
npx husky install必须在项目根目录运行，它会在.husky/下生成钩子脚本 -
npx husky add .husky/pre-commit "npx lint-staged"是把 lint-staged 命令写进 pre-commit 钩子——注意路径是.husky/pre-commit，不是.husky/pre-commit.sh或其他变体 - 如果项目用 pnpm，得确认
npx能正确解析本地 bin；pnpm 用户建议改用pnpx lint-staged - 验证是否生效：终端里手动跑
git commit --no-verify -m "test"（绕过 hook），再跑git commit -m "test"，对比输出是否有 lint-staged 日志
lint-staged 配置为什么总不生效
常见现象是 commit 成功但完全没报错、没格式化——大概率是 glob 模式没匹配到暂存文件，或者规则命令根本没执行。
- 确保
lint-staged配置在package.json顶层，不是嵌套在scripts或其他字段里；若用独立配置文件，必须叫.lintstagedrc.json或.lintstagedrc.js，不能是lint-staged.config.js - glob 模式要覆盖实际暂存的文件后缀：
"*.{js,ts,jsx,tsx}"不会匹配.vue或.svelte，得单独加 - 命令数组里每个字符串都得是可执行命令：
"eslint --fix"要求项目本地装了eslint，全局安装无效；同理"prettier --write"依赖本地prettier - 如果用了 TypeScript，
eslint --fix可能报 parser 错误，得确认@typescript-eslint/parser已安装且.eslintrc.cjs中parser字段指向正确
ESLint 和 Prettier 冲突导致保存和提交行为不一致
保存时自动修复、提交时又报错，八成是两套规则打架。VSCode 的保存修复走的是编辑器层，而提交检查走的是 CLI 层，路径不同，配置加载可能不一致。
- 必须在
.eslintrc.cjs的extends数组末尾加上"prettier"，且eslint-config-prettier要本地安装，否则 ESLint 仍会启用自带的格式规则（如indent、quotes） -
.prettierrc文件必须存在且位于项目根目录，内容不能有注释（JSON 不支持），也不能是.prettierrc.js里用module.exports—— lint-staged 默认只读 JSON/YAML/JS 导出，但某些版本对 JS 格式支持不稳定 - VSCode 设置里禁用
"editor.codeActionsOnSave": { "source.fixAll.prettier": true }，只留"source.fixAll.eslint": true；否则保存时 Prettier 和 ESLint 可能反复覆盖同一行 - 验证方法：改一行缩进，保存后看是否只修正一次、无红色波浪线提示 “conflicting rule”，再 git add + commit 看是否通过
最容易被忽略的点：所有工具（husky、lint-staged、eslint、prettier）都必须本地安装，且配置文件严格放在项目根目录。VSCode 打开的文件夹如果不是根目录，插件和钩子都会失效——这不是 bug，是设计使然。
