pre-commit 钩子在 vscode 中“没反应”是因 git 层面未正确安装或执行环境缺失；真正起作用的是 .git/hooks/pre-commit 脚本，vscode 仅调用系统 git，不负责运行钩子或保证环境变量、node/python 路径可用。

pre-commit 钩子在 VSCode 里“没反应”，不是 VSCode 的问题，而是 Git 层面的钩子没被正确安装或执行环境缺失。真正起作用的是 .git/hooks/pre-commit 脚本，VSCode 只是调用系统 Git —— 它不负责运行钩子，也不保证环境变量、Node 路径或 Python 解释器可用。

为什么 VSCode 点提交按钮时 pre-commit 不触发

常见现象：终端里 git commit 能跑 lint，VSCode 点 ✔️ 却直接提交成功，连 ESLint 错误都没打印。

• .git/hooks/pre-commit 文件存在但没可执行权限（chmod +x 缺失）
• VSCode 内置终端默认不加载 ~/.zshrc 或 ~/.bash_profile，导致 pre-commit 命令找不到（尤其用了 pyenv 或 node 版本管理）
• 手动写的 shell 脚本开头没写 #!/usr/bin/env bash，在 macOS/Linux 上可能静默失败
• VSCode 启用了 git.enableSmartCommit（默认 true），它会把未暂存文件直接塞进 commit，绕过 pre-commit 对 staged 文件的检查逻辑

用 husky + lint-staged 配置可靠 pre-commit

别手写 .git/hooks/pre-commit —— 它易被覆盖、难维护、跨平台兼容差。husky 是当前最稳定的方案，它自动注入 PATH、解析 package.json scripts，并兼容 Windows 换行符和 Node 环境。

GitLab MR Code Review

通过轮询对 GitLab 合并请求进行自动化 AI 代码审查。定期检查开放的合并请求，审查代码差异中的安全漏洞、错误等。

下载

• 安装并启用：npx husky install（会创建 .husky/ 目录）
• 添加钩子：npx husky add .husky/pre-commit "npx lint-staged"
• 在 package.json 中配置 lint-staged，只处理暂存区文件：

  "lint-staged": {
    "*.{js,ts,jsx,tsx}": ["eslint --fix", "prettier --write", "git add"],
    "*.{css,scss,md}": ["prettier --write", "git add"]
  }

• 必须加 git add：ESLint --fix 改的是工作区，不重新暂存，修复不会进本次提交

VSCode 设置里必须关掉的两个选项

很多人配完 husky 还没效果，是因为 VSCode 插件和 Git 钩子在抢着改代码，造成暂存区与工作区内容不一致。

• 关闭 eslint.autoFixOnSave（设为 false）：否则保存时插件已偷偷 fix，lint-staged 检查暂存区发现“没错误”，跳过修复，结果提交的是旧代码
• 禁用 editor.codeActionsOnSave 中的 source.fixAll.eslint：同理，避免保存时自动介入
• 保留 ESLint 插件的实时报错功能（即只高亮、不改），让开发者肉眼确认逻辑是否真被修对了
• 把 git.enableSmartCommit 设为 false：强制自己先 git add，确保 pre-commit 有东西可检查

pre-commit 失败但提交仍成功？查这三点

钩子脚本退出码没被 Git 正确识别为失败，是“拦截失效”的最隐蔽原因。

• 检查 husky 生成的 .husky/pre-commit 脚本末尾有没有 || true、set +e 这类忽略错误的语句
• 运行 git status --porcelain：如果输出为空，lint-staged 默认不执行任何命令（不会报错，但也不检查）
• 确认 lint-staged 没启用 --allow-empty 或 --no-stash 参数——它们会让校验逻辑跳过

真正关键的不是“怎么配”，而是让 Git 在 commit 那一刻确实拿到一个非零退出码。所有配置最终都服务于这个信号：只要 pre-commit 脚本返回 1，Git 就会中止提交。其他环节，比如 VSCode 是否弹窗、是否高亮错误，都是次要的。