Git提交前自动触发ESLint修复的原理是通过Git的pre-commit钩子调用ESLint的--fix能力，而非VSCode直接干预；husky管理钩子生命周期，lint-staged仅处理暂存区文件并执行eslint --fix与git add，需关闭VSCode的eslint.autoFixOnSave以避免工作区与暂存区不一致。
Git提交前自动触发ESLint修复的原理是什么
VSCode本身不直接干预Git提交流程，真正起作用的是 Git 的 pre-commit 钩子 + ESLint 的 --fix 能力。VSCode 只负责把配置好的钩子脚本识别出来、并配合终端或插件调用它。关键点在于：不是 VSCode “做检查”，而是你本地 Git 在 git commit 执行瞬间，被钩子拦下来，先跑一遍 eslint --fix，再决定是否放行。
用 husky + lint-staged 实现可靠自动修复
直接写 .git/hooks/pre-commit 脚本容易被覆盖、难维护，推荐标准化方案。husky 管钩子生命周期，lint-staged 只处理暂存区文件（避免全量扫描拖慢提交），配合 ESLint 做精准修复。
按顺序执行以下操作：
- 安装依赖：
npm install --save-dev husky lint-staged eslint - 启用 husky：
npx husky install（会创建.husky/目录） - 添加 pre-commit 钩子：
npx husky add .husky/pre-commit "npx lint-staged" - 在
package.json中加入配置："lint-staged": { "*.{js,jsx,ts,tsx}": ["eslint --fix", "git add"] }
注意：git add 这一步不能省——ESLint --fix 修改的是工作区文件，必须重新暂存，否则修改不会进入本次提交。
Convert Github Repository
下载
适用于以下场景：（1）用户提供 GitHub 仓库 URL 或本地仓库路径，并请求将其转换为其他格式；（2）用户请求导出 GitHub 仓库……
VSCode里需要关掉哪些默认行为
很多人配完 husky 还没效果，是因为 VSCode 的 ESLint 插件在保存时已自动 fix，导致暂存区和工作区内容不一致，lint-staged 检查不到“待修复项”。这时候要明确分工：
- 关闭 ESLint 插件的自动修复：在 VSCode 设置中搜
eslint.autoFixOnSave，设为false - 确保
editor.codeActionsOnSave里没有source.fixAll.eslint - 保留 ESLint 插件的实时报错功能（即只提示、不自动改），让开发者肉眼确认逻辑是否真被修对了
否则会出现“明明看到红波浪线消失了，但提交时 still fails”的情况——因为保存时插件偷偷 fix 了，而 lint-staged 检查的是暂存区原始内容，发现没错误，就跳过修复，结果提交的仍是旧代码。
常见失败场景和对应解法
提交卡住、报错、或修复没生效，大概率是下面几个原因：
-
Cannot find module 'eslint'：husky 钩子运行在 Git 环境下，PATH 可能不包含 node_modules/.bin。解决方案：在.husky/pre-commit第一行加上#!/usr/bin/env sh，第二行加npm exec --no -- lint-staged（比直接npx更健壮） - TSX 文件没被 lint-staged 匹配到：检查
package.json里lint-staged的 glob 模式是否含tsx，且项目有@typescript-eslint/parser和对应配置 - 修复后仍有未暂存变更：说明
git add失败，常见于 Windows 权限问题或文件被其他进程占用；可临时改用git add -u或手动git add .后重试
最易忽略的一点：husky v8+ 默认要求 Git 版本 ≥ 2.37，老项目升级时若没更新 Git，钩子根本不会注册——别只盯着 Node 版本看。
