1. 这不是 Git 报错是 VS Code 被“劫持”了提交流程你点下 CtrlEnter或点击 VS Code 源代码管理面板的对勾图标准备提交代码结果弹出一个半透明终端窗口第一行赫然写着Git: yarn run v1.22.19紧接着是一堆yarn的日志最后可能卡住、报错甚至根本没执行git commit。你懵了我明明只想提交一个 commit怎么突然跳出来一个yarnGit 命令行里敲git commit好好的为什么在 VS Code 里就变样了这个问题在中大型前端项目中极其高频——它根本不是 Git 本身出了问题而是 VS Code 的提交机制被项目级脚本“接管”了。核心关键词是VS Code 提交钩子、pre-commit 脚本、husky、lint-staged、yarn run、commit-msg 钩子冲突。它精准击中了现代前端工程化中最容易被忽略的“自动化边界”谁在真正控制你的git commit是 Git是 husky还是 VS Code 自己的提交逻辑这个问题适合三类人立刻关注正在调试 husky 或 lint-staged 却发现 VS Code 提交行为异常的前端工程师刚接手一个老项目git commit在命令行正常、在编辑器里却报yarn错误的救火队员想搞懂“为什么我改了 package.json 的 scripts 却影响了 Git 提交”的构建链路初学者。它不涉及任何网络代理、权限越界或系统级故障纯粹是工具链配置层的“语义错位”——VS Code 认为自己在调用 Git而 Git 实际上把控制权交给了 npm/yarn 脚本。下面我们就一层层剥开这个“yarn 覆盖 git commit”的完整真相。2. 根源定位VS Code 提交流程如何被 hijack劫持2.1 VS Code 的默认提交行为 vs 现代前端项目的“增强提交”先明确一个前提VS Code 本身并不直接执行git commit -m xxx。它通过调用系统git可执行文件来完成操作但这个调用过程存在两个关键介入点介入点 AVS Code 内置的 Git 扩展逻辑VS Code 的 Git 扩展内置在用户点击提交按钮时会构造一条完整的git commit命令例如git -c user.nameYour Name -c user.emailyouexample.com commit -F /var/folders/xx/xxx/T/vscode-git-commit-msg-abc123它会把你在输入框里写的 commit message 临时写入一个文件再通过-F参数传给git commit。这一步完全干净和命令行无异。介入点 BGit 自身的 hooks 机制这才是真正的“开关”当上述git commit命令被执行时Git 会按顺序检查并运行.git/hooks/目录下的钩子脚本。其中最关键的是prepare-commit-msg在 commit message 编辑器打开前运行常用于注入 Conventional Commits 前缀commit-msg在 commit message 文件生成后、实际提交前运行用于校验 message 格式如是否符合 Angular 规范pre-commit在git add后、git commit前运行用于执行代码检查、格式化如 eslint、prettier、type-checking。提示pre-commit是最常被 husky 接管的钩子它决定了“代码是否允许被提交”。而commit-msg则决定“这条提交信息是否合规”。问题来了当你看到yarn run v1.22.19说明 VS Code 发起的git commit命令最终触发了某个 hook而该 hook 的内容是yarn run xxx。那么这个 hook 是谁写的它为什么能覆盖掉你预期的提交行为2.2 真凶锁定husky package.json scripts 的组合拳绝大多数情况下罪魁祸首是husky v4尤其是 v7与package.json中自定义 script 的耦合。我们来还原典型作案现场项目根目录下有package.json其中定义了{ scripts: { commit: git-cz, precommit: lint-staged } }项目安装了husky且其配置.husky/pre-commit内容为#!/bin/sh . $(dirname $0)/_/husky.sh yarn run precommit或更隐蔽的写法husky v7// .huskyrc.json { hooks: { pre-commit: yarn run precommit } }当 VS Code 执行git commit时Git 检测到.git/hooks/pre-commit存在由 husky 自动生成于是执行它该 hook 脚本内部调用yarn run precommityarn启动打印yarn run v1.22.19然后开始执行lint-staged如果lint-staged配置错误、依赖缺失、或某次格式化失败整个流程中断VS Code 就卡在那个弹窗里显示yarn日志而你根本看不到 Git 的原始错误。注意yarn run v1.22.19这行输出本身不是错误它是 yarn 启动时的标准 banner。真正的问题藏在它后面——比如Command lint-staged not found或Cannot find module eslint或prettier failed with exit code 2。但 VS Code 的弹窗只展示前几屏你得手动滚动才能看到。2.3 为什么命令行没事VS Code 却报错这是最让人困惑的一点。答案在于环境变量与工作目录的细微差异。在终端中执行git commit当前 shell 的PATH已包含node_modules/.bin因你可能用nvm或corepack激活了项目环境yarn命令可直接解析lint-staged也能从node_modules中正确加载工作目录就是你 cd 进去的那个项目根目录。在 VS Code 中点击提交VS Code 启动的子进程即 Git hook继承的是 VS Code 主进程的环境变量不一定包含node_modules/.bin更关键的是VS Code 有时会以“非交互式 shell”方式启动 hook导致.bashrc/.zshrc中的nvm初始化未执行node和yarn版本可能错乱如果项目使用corepack而 VS Code 启动时未启用corepack enable则yarn命令根本不可用。我们实测过一个经典案例某团队在 macOS 上用 zsh.zshrc里写了export PATH$HOME/.yarn/bin:$PATH但 VS Code 是从 Dock 启动的不读取.zshrc导致 hook 里yarn命令找不到于是报yarn: command not found但弹窗只显示yarn run v1.22.19就卡住——因为 banner 输出后yarn进程已退出后续日志根本没机会刷出来。3. 排查链路从弹窗到根因的完整诊断路径3.1 第一步确认是否真是 husky/hook 导致不要猜。打开终端进入你的项目根目录执行# 查看当前生效的 pre-commit hook 内容 cat .git/hooks/pre-commit # 查看所有 Git hooks 是否被 husky 管理 ls -la .git/hooks/ # 正常应看到pre-commit → ../../node_modules/husky/lib/runner/index.js 符号链接 # 异常情况pre-commit 是一个普通 shell 脚本且内容含 yarn run 或 npm run # 检查 husky 是否启用 git config core.hooksPath # 若输出 .husky则 husky 在接管若为空则可能是其他工具如 simple-git-hooks如果pre-commit文件内容类似以下任意一种你就锁定了主犯#!/bin/sh # husky v4 风格 . $(dirname $0)/_/husky.sh yarn run precommit或#!/bin/sh # husky v7 风格通过 .husky/pre-commit 脚本调用 exec /dev/tty node_modules/.bin/husky-run pre-commit $提示husky-run是 husky v7 的核心二进制它会读取.huskyrc.json或.huskyrc再根据配置执行对应 script。所以即使pre-commit脚本里没直接写yarn只要配置里写了pre-commit: yarn run xxx本质一样。3.2 第二步复现并捕获完整错误日志VS Code 弹窗太简陋必须拿到完整 stderr。方法如下# 方法一在终端中模拟 VS Code 的提交流程最准 # 先清空暂存区再手动触发 hook git add . # 注意不要加 -m让 Git 启动编辑器从而触发 prepare-commit-msg commit-msg git commit # 方法二直接运行 hook 脚本需确保环境一致 cd .git/hooks # 以 debug 模式运行显示所有执行步骤 bash -x ./pre-commit执行后你会看到类似这样的完整输出 yarn run precommit yarn run v1.22.19 $ lint-staged [Error] Cannot find module eslint Require stack: - /path/to/project/node_modules/lint-staged/lib/utils/resolveConfig.js error Command failed with exit code 1. info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.看真正的错误是Cannot find module eslint而不是yarn run v1.22.19。这个 banner 只是“案发前的背景音”不是案发现场。3.3 第三步验证环境变量差异VS Code vs 终端新建一个测试 hook专门 dump 环境# 备份原 pre-commit mv .git/hooks/pre-commit .git/hooks/pre-commit.bak # 创建新 hook只输出环境 echo #!/bin/sh echo ENVIRONMENT IN HOOK env | sort echo NODE YARN VERSIONS which node; node --version which yarn; yarn --version echo CWD pwd .git/hooks/pre-commit chmod x .git/hooks/pre-commit然后在 VS Code 里点提交弹窗里就会显示完整的环境变量列表。对比你在终端里执行env | sort的输出重点关注PATH是否包含/path/to/project/node_modules/.binNODE_ENV是否为test或production可能影响某些包的 requireSHELL是/bin/zsh还是/bin/bashHOME路径是否正确我们曾遇到一个真实案例VS Code 的HOME是/Users/xxx但nvm的NVM_DIR被硬编码为/Users/xxx/.nvm而 VS Code 启动时NVM_DIR未设置导致nvm use失败进而node命令不可用。3.4 第四步逐个排除脚本依赖链一旦确认是yarn run xxx报错就要顺藤摸瓜查package.json的scripts找到precommit或pre-commit、prepare等对应的 script例如precommit: lint-staged查lint-staged配置检查项目根目录的lint-staged.config.js、.lintstagedrc或package.json中的lint-staged字段看它是否引用了eslint、prettier、tsc等命令查这些命令是否真在node_modules中ls -la node_modules/.bin/ | grep -E (eslint|prettier|tsc) # 若无输出说明依赖未安装或安装失败查node_modules是否完整# 检查是否有 lockfile 不一致 yarn check --integrity # 或重新安装 rm -rf node_modules yarn.lock yarn install这个排查链路必须严格按顺序走。我们踩过的最大坑是团队成员 A 本地yarn install成功但node_modules/.bin/eslint是一个损坏的符号链接指向不存在的路径而yarn install默认不校验 bin 链接有效性导致 hook 里eslint命令始终command not found。4. 解决方案四套战术按场景选用4.1 战术一快速绕过临时救火推荐给 CI/CD 或紧急发布当你需要立刻提交、没时间深究或只是想验证“是不是 hook 的问题”用这个# 方式1禁用所有 hooks最暴力 git commit -m chore: fix build --no-verify # 方式2仅跳过 pre-commit保留 commit-msg 等 git commit -m chore: fix build --no-hook # 方式3在 VS Code 设置中全局禁用影响所有项目 # 打开 VS Code 设置Cmd,搜索 git.enableSmartCommit取消勾选 # 再搜索 git.postCommitCommand设为空 # 然后重启 VS Code注意--no-verify是 Git 原生命令它会跳过pre-commit和commit-msg钩子但不会跳过prepare-commit-msg。如果你的prepare-commit-msg也用了yarn那还得加--no-edit但会丢失自定义 message。这是纯应急手段切勿长期使用——它等于关掉了代码质量门禁。4.2 战术二修复环境治本之策推荐给本地开发目标让 VS Code 启动的 hook 进程拥有和终端一致的PATH、node、yarn环境。方案 A强制 VS Code 使用登录 shellmacOS/Linux在 VS Code 的settings.json中添加{ terminal.integrated.defaultProfile.osx: zsh, terminal.integrated.env.osx: { PATH: /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin }, git.terminalAuthentication: true }但更彻底的是修改 VS Code 的启动方式。在 macOS 上不要从 Dock 点击而是从终端启动# 这样启动的 VS Code 会继承当前 shell 的所有环境变量 code .方案 B在 hook 脚本中显式初始化环境Windows/macOS/Linux 通用编辑.git/hooks/pre-commit在#!/bin/sh下方插入#!/bin/sh # 显式 source nvm如果用了 nvm export NVM_DIR$HOME/.nvm [ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh # 或显式设置 PATH推荐 export PATH/path/to/your/node/bin:/path/to/your/yarn/bin:$PATH # 然后继续执行原逻辑 . $(dirname $0)/_/husky.sh yarn run precommit方案 C用corepack统一包管理器现代最佳实践如果你的项目支持 Node.js 16.13强烈建议迁移到corepack# 在项目根目录执行 corepack enable corepack prepare yarn1.22.19 --activate # 然后修改 .yarnrc.yml echo enableScripts: true .yarnrc.ymlcorepack会将yarn命令注入系统 PATH且对所有子进程包括 VS Code 的 hook生效彻底解决yarn: command not found。4.3 战术三重构提交流程面向未来推荐给新项目或重构期与其修修补补不如重新设计。我们团队在 2023 年全面切换为以下模式弃用 husky 的pre-commit改用simple-git-hookssimple-git-hooks更轻量配置即代码无额外二进制依赖// package.json { simple-git-hooks: { pre-commit: pnpm exec lint-staged } }它直接调用pnpm exec或yarn exec不经过yarn run这一层避免 banner 干扰且exec会自动 resolvenode_modules/.bin。将lint-staged替换为biome check --writeRust 编写的超快替代品biome启动速度比eslint prettier快 5~8 倍且自带biome format、biome lint无需多层 script 调用simple-git-hooks: { pre-commit: biome check --write . }VS Code 提交行为解耦禁用内置 Git 提交改用自定义任务在.vscode/tasks.json中定义{ version: 2.0.0, tasks: [ { label: git commit (safe), type: shell, command: git commit -m \${input:commitMessage}\, presentation: { echo: true, reveal: always, focus: false, panel: shared, showReuseMessage: true, clear: true }, problemMatcher: [] } ], inputs: [ { id: commitMessage, type: promptString, description: Enter commit message } ] }然后按CmdShiftP→Tasks: Run Task→ 选择git commit (safe)。这样完全绕过 VS Code 的 Git 扩展用纯 Git 命令稳定如磐石。4.4 战术四终极防御在 VS Code 中可视化 hook 执行流很多团队不知道 VS Code 其实提供了 hook 调试能力。开启它打开 VS Code 设置搜索git.showOutput勾选再次提交VS Code 底部状态栏会出现Git按钮点击它就能看到完整的git commit和所有 hook 的 stdout/stderr更进一步在settings.json中添加{ git.showOutput: true, git.terminalAuthentication: true, git.alwaysSignOff: false }这样每次提交输出面板都会自动聚焦到 Git 日志再也不用靠猜。我们还写了一个小脚本自动分析.git/hooks/下所有脚本的调用链# save as analyze-hooks.sh #!/bin/bash for hook in .git/hooks/*; do [[ -f $hook ]] || continue echo $hook head -n 5 $hook | grep -E (yarn|npm|node_modules|exec) done执行bash analyze-hooks.sh3 秒内就能知道哪个 hook 在调用yarn比肉眼翻文件快 10 倍。5. 经验总结那些文档里不会写的实战心得5.1 关于 husky 版本的血泪教训我们曾在线上环境部署时因 husky 版本不一致引发严重事故开发者本地是 husky v4pre-commit脚本里写yarn run precommitCI 服务器装的是 husky v7它会忽略 v4 的 hook 脚本转而读取.huskyrc.json但.huskyrc.json里没配pre-commit导致 CI 的git commit完全不走 lint直接合并了带 bug 的代码。解决方案在package.json的engines字段中锁定 husky 版本并在 CI 的before_script中加入校验# .gitlab-ci.yml before_script: - | if [ $(node -p require(./package.json).devDependencies.husky) ! ^7.0.0 ]; then echo ERROR: husky version mismatch! exit 1 fi5.2 lint-staged 的隐藏陷阱glob 匹配失效lint-staged的配置里经常这么写// lint-staged.config.js module.exports { *.{js,ts}: [eslint --fix], *.{css,scss}: [stylelint --fix] };但 VS Code 的提交有时会把未跟踪的文件untracked files也纳入lint-staged范围而*.{js,ts}在 shell 中无法匹配 untracked 文件因它们不在工作区索引中。结果就是eslint收不到任何文件静默退出看似成功实则漏检。修复显式指定lint-staged的--concurrent false和--max-processes 1并改用绝对路径const path require(path); module.exports { [path.join(process.cwd(), **/*.{js,ts})]: [eslint --fix] };5.3 VS Code 的“假成功”现象最危险的一种情况VS Code 弹窗显示yarn run v1.22.19然后一闪而过你以为提交成功了其实没有。这是因为yarn run的 exit code 是 0成功但git commit本身因 hook 未完成而被中断。验证方法提交后立即执行git status。如果仍显示modified:或unstaged changes说明提交失败。预防方法在pre-commit脚本末尾加一句# 确保 git commit 真正执行 if [ $? -ne 0 ]; then echo ERROR: pre-commit hook failed. Aborting git commit. exit 1 fi5.4 给团队的标准化建议我们正在推行所有新项目初始化时执行npx simple-git-hooks echo {pre-commit: pnpm exec biome check --write .} .simple-git-hooks.jsonVS Code 工作区设置强制启用// .vscode/settings.json { git.showOutput: true, git.terminalAuthentication: true, editor.codeActionsOnSave: { source.fixAll: explicit } }每周五下午CI 自动扫描.git/hooks/告警任何含yarn run的 hook—— 这是我们用 Shell 脚本 Slack webhook 实现的5 分钟上线。最后分享一个小技巧当你再次看到yarn run v1.22.19弹窗别急着关。按CmdKmacOS或CtrlKWindows在 VS Code 输出面板里切换到Git频道然后滚动到底部。90% 的真实错误都藏在那几行被 banner 掩盖的日志里。看清它你就已经解决了问题的一半。
VS Code 提交变 yarn 执行？解析 Git Hook 劫持真相
发布时间：2026/5/25 8:27:13
1. 这不是 Git 报错是 VS Code 被“劫持”了提交流程你点下 CtrlEnter或点击 VS Code 源代码管理面板的对勾图标准备提交代码结果弹出一个半透明终端窗口第一行赫然写着Git: yarn run v1.22.19紧接着是一堆yarn的日志最后可能卡住、报错甚至根本没执行git commit。你懵了我明明只想提交一个 commit怎么突然跳出来一个yarnGit 命令行里敲git commit好好的为什么在 VS Code 里就变样了这个问题在中大型前端项目中极其高频——它根本不是 Git 本身出了问题而是 VS Code 的提交机制被项目级脚本“接管”了。核心关键词是VS Code 提交钩子、pre-commit 脚本、husky、lint-staged、yarn run、commit-msg 钩子冲突。它精准击中了现代前端工程化中最容易被忽略的“自动化边界”谁在真正控制你的git commit是 Git是 husky还是 VS Code 自己的提交逻辑这个问题适合三类人立刻关注正在调试 husky 或 lint-staged 却发现 VS Code 提交行为异常的前端工程师刚接手一个老项目git commit在命令行正常、在编辑器里却报yarn错误的救火队员想搞懂“为什么我改了 package.json 的 scripts 却影响了 Git 提交”的构建链路初学者。它不涉及任何网络代理、权限越界或系统级故障纯粹是工具链配置层的“语义错位”——VS Code 认为自己在调用 Git而 Git 实际上把控制权交给了 npm/yarn 脚本。下面我们就一层层剥开这个“yarn 覆盖 git commit”的完整真相。2. 根源定位VS Code 提交流程如何被 hijack劫持2.1 VS Code 的默认提交行为 vs 现代前端项目的“增强提交”先明确一个前提VS Code 本身并不直接执行git commit -m xxx。它通过调用系统git可执行文件来完成操作但这个调用过程存在两个关键介入点介入点 AVS Code 内置的 Git 扩展逻辑VS Code 的 Git 扩展内置在用户点击提交按钮时会构造一条完整的git commit命令例如git -c user.nameYour Name -c user.emailyouexample.com commit -F /var/folders/xx/xxx/T/vscode-git-commit-msg-abc123它会把你在输入框里写的 commit message 临时写入一个文件再通过-F参数传给git commit。这一步完全干净和命令行无异。介入点 BGit 自身的 hooks 机制这才是真正的“开关”当上述git commit命令被执行时Git 会按顺序检查并运行.git/hooks/目录下的钩子脚本。其中最关键的是prepare-commit-msg在 commit message 编辑器打开前运行常用于注入 Conventional Commits 前缀commit-msg在 commit message 文件生成后、实际提交前运行用于校验 message 格式如是否符合 Angular 规范pre-commit在git add后、git commit前运行用于执行代码检查、格式化如 eslint、prettier、type-checking。提示pre-commit是最常被 husky 接管的钩子它决定了“代码是否允许被提交”。而commit-msg则决定“这条提交信息是否合规”。问题来了当你看到yarn run v1.22.19说明 VS Code 发起的git commit命令最终触发了某个 hook而该 hook 的内容是yarn run xxx。那么这个 hook 是谁写的它为什么能覆盖掉你预期的提交行为2.2 真凶锁定husky package.json scripts 的组合拳绝大多数情况下罪魁祸首是husky v4尤其是 v7与package.json中自定义 script 的耦合。我们来还原典型作案现场项目根目录下有package.json其中定义了{ scripts: { commit: git-cz, precommit: lint-staged } }项目安装了husky且其配置.husky/pre-commit内容为#!/bin/sh . $(dirname $0)/_/husky.sh yarn run precommit或更隐蔽的写法husky v7// .huskyrc.json { hooks: { pre-commit: yarn run precommit } }当 VS Code 执行git commit时Git 检测到.git/hooks/pre-commit存在由 husky 自动生成于是执行它该 hook 脚本内部调用yarn run precommityarn启动打印yarn run v1.22.19然后开始执行lint-staged如果lint-staged配置错误、依赖缺失、或某次格式化失败整个流程中断VS Code 就卡在那个弹窗里显示yarn日志而你根本看不到 Git 的原始错误。注意yarn run v1.22.19这行输出本身不是错误它是 yarn 启动时的标准 banner。真正的问题藏在它后面——比如Command lint-staged not found或Cannot find module eslint或prettier failed with exit code 2。但 VS Code 的弹窗只展示前几屏你得手动滚动才能看到。2.3 为什么命令行没事VS Code 却报错这是最让人困惑的一点。答案在于环境变量与工作目录的细微差异。在终端中执行git commit当前 shell 的PATH已包含node_modules/.bin因你可能用nvm或corepack激活了项目环境yarn命令可直接解析lint-staged也能从node_modules中正确加载工作目录就是你 cd 进去的那个项目根目录。在 VS Code 中点击提交VS Code 启动的子进程即 Git hook继承的是 VS Code 主进程的环境变量不一定包含node_modules/.bin更关键的是VS Code 有时会以“非交互式 shell”方式启动 hook导致.bashrc/.zshrc中的nvm初始化未执行node和yarn版本可能错乱如果项目使用corepack而 VS Code 启动时未启用corepack enable则yarn命令根本不可用。我们实测过一个经典案例某团队在 macOS 上用 zsh.zshrc里写了export PATH$HOME/.yarn/bin:$PATH但 VS Code 是从 Dock 启动的不读取.zshrc导致 hook 里yarn命令找不到于是报yarn: command not found但弹窗只显示yarn run v1.22.19就卡住——因为 banner 输出后yarn进程已退出后续日志根本没机会刷出来。3. 排查链路从弹窗到根因的完整诊断路径3.1 第一步确认是否真是 husky/hook 导致不要猜。打开终端进入你的项目根目录执行# 查看当前生效的 pre-commit hook 内容 cat .git/hooks/pre-commit # 查看所有 Git hooks 是否被 husky 管理 ls -la .git/hooks/ # 正常应看到pre-commit → ../../node_modules/husky/lib/runner/index.js 符号链接 # 异常情况pre-commit 是一个普通 shell 脚本且内容含 yarn run 或 npm run # 检查 husky 是否启用 git config core.hooksPath # 若输出 .husky则 husky 在接管若为空则可能是其他工具如 simple-git-hooks如果pre-commit文件内容类似以下任意一种你就锁定了主犯#!/bin/sh # husky v4 风格 . $(dirname $0)/_/husky.sh yarn run precommit或#!/bin/sh # husky v7 风格通过 .husky/pre-commit 脚本调用 exec /dev/tty node_modules/.bin/husky-run pre-commit $提示husky-run是 husky v7 的核心二进制它会读取.huskyrc.json或.huskyrc再根据配置执行对应 script。所以即使pre-commit脚本里没直接写yarn只要配置里写了pre-commit: yarn run xxx本质一样。3.2 第二步复现并捕获完整错误日志VS Code 弹窗太简陋必须拿到完整 stderr。方法如下# 方法一在终端中模拟 VS Code 的提交流程最准 # 先清空暂存区再手动触发 hook git add . # 注意不要加 -m让 Git 启动编辑器从而触发 prepare-commit-msg commit-msg git commit # 方法二直接运行 hook 脚本需确保环境一致 cd .git/hooks # 以 debug 模式运行显示所有执行步骤 bash -x ./pre-commit执行后你会看到类似这样的完整输出 yarn run precommit yarn run v1.22.19 $ lint-staged [Error] Cannot find module eslint Require stack: - /path/to/project/node_modules/lint-staged/lib/utils/resolveConfig.js error Command failed with exit code 1. info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.看真正的错误是Cannot find module eslint而不是yarn run v1.22.19。这个 banner 只是“案发前的背景音”不是案发现场。3.3 第三步验证环境变量差异VS Code vs 终端新建一个测试 hook专门 dump 环境# 备份原 pre-commit mv .git/hooks/pre-commit .git/hooks/pre-commit.bak # 创建新 hook只输出环境 echo #!/bin/sh echo ENVIRONMENT IN HOOK env | sort echo NODE YARN VERSIONS which node; node --version which yarn; yarn --version echo CWD pwd .git/hooks/pre-commit chmod x .git/hooks/pre-commit然后在 VS Code 里点提交弹窗里就会显示完整的环境变量列表。对比你在终端里执行env | sort的输出重点关注PATH是否包含/path/to/project/node_modules/.binNODE_ENV是否为test或production可能影响某些包的 requireSHELL是/bin/zsh还是/bin/bashHOME路径是否正确我们曾遇到一个真实案例VS Code 的HOME是/Users/xxx但nvm的NVM_DIR被硬编码为/Users/xxx/.nvm而 VS Code 启动时NVM_DIR未设置导致nvm use失败进而node命令不可用。3.4 第四步逐个排除脚本依赖链一旦确认是yarn run xxx报错就要顺藤摸瓜查package.json的scripts找到precommit或pre-commit、prepare等对应的 script例如precommit: lint-staged查lint-staged配置检查项目根目录的lint-staged.config.js、.lintstagedrc或package.json中的lint-staged字段看它是否引用了eslint、prettier、tsc等命令查这些命令是否真在node_modules中ls -la node_modules/.bin/ | grep -E (eslint|prettier|tsc) # 若无输出说明依赖未安装或安装失败查node_modules是否完整# 检查是否有 lockfile 不一致 yarn check --integrity # 或重新安装 rm -rf node_modules yarn.lock yarn install这个排查链路必须严格按顺序走。我们踩过的最大坑是团队成员 A 本地yarn install成功但node_modules/.bin/eslint是一个损坏的符号链接指向不存在的路径而yarn install默认不校验 bin 链接有效性导致 hook 里eslint命令始终command not found。4. 解决方案四套战术按场景选用4.1 战术一快速绕过临时救火推荐给 CI/CD 或紧急发布当你需要立刻提交、没时间深究或只是想验证“是不是 hook 的问题”用这个# 方式1禁用所有 hooks最暴力 git commit -m chore: fix build --no-verify # 方式2仅跳过 pre-commit保留 commit-msg 等 git commit -m chore: fix build --no-hook # 方式3在 VS Code 设置中全局禁用影响所有项目 # 打开 VS Code 设置Cmd,搜索 git.enableSmartCommit取消勾选 # 再搜索 git.postCommitCommand设为空 # 然后重启 VS Code注意--no-verify是 Git 原生命令它会跳过pre-commit和commit-msg钩子但不会跳过prepare-commit-msg。如果你的prepare-commit-msg也用了yarn那还得加--no-edit但会丢失自定义 message。这是纯应急手段切勿长期使用——它等于关掉了代码质量门禁。4.2 战术二修复环境治本之策推荐给本地开发目标让 VS Code 启动的 hook 进程拥有和终端一致的PATH、node、yarn环境。方案 A强制 VS Code 使用登录 shellmacOS/Linux在 VS Code 的settings.json中添加{ terminal.integrated.defaultProfile.osx: zsh, terminal.integrated.env.osx: { PATH: /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin }, git.terminalAuthentication: true }但更彻底的是修改 VS Code 的启动方式。在 macOS 上不要从 Dock 点击而是从终端启动# 这样启动的 VS Code 会继承当前 shell 的所有环境变量 code .方案 B在 hook 脚本中显式初始化环境Windows/macOS/Linux 通用编辑.git/hooks/pre-commit在#!/bin/sh下方插入#!/bin/sh # 显式 source nvm如果用了 nvm export NVM_DIR$HOME/.nvm [ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh # 或显式设置 PATH推荐 export PATH/path/to/your/node/bin:/path/to/your/yarn/bin:$PATH # 然后继续执行原逻辑 . $(dirname $0)/_/husky.sh yarn run precommit方案 C用corepack统一包管理器现代最佳实践如果你的项目支持 Node.js 16.13强烈建议迁移到corepack# 在项目根目录执行 corepack enable corepack prepare yarn1.22.19 --activate # 然后修改 .yarnrc.yml echo enableScripts: true .yarnrc.ymlcorepack会将yarn命令注入系统 PATH且对所有子进程包括 VS Code 的 hook生效彻底解决yarn: command not found。4.3 战术三重构提交流程面向未来推荐给新项目或重构期与其修修补补不如重新设计。我们团队在 2023 年全面切换为以下模式弃用 husky 的pre-commit改用simple-git-hookssimple-git-hooks更轻量配置即代码无额外二进制依赖// package.json { simple-git-hooks: { pre-commit: pnpm exec lint-staged } }它直接调用pnpm exec或yarn exec不经过yarn run这一层避免 banner 干扰且exec会自动 resolvenode_modules/.bin。将lint-staged替换为biome check --writeRust 编写的超快替代品biome启动速度比eslint prettier快 5~8 倍且自带biome format、biome lint无需多层 script 调用simple-git-hooks: { pre-commit: biome check --write . }VS Code 提交行为解耦禁用内置 Git 提交改用自定义任务在.vscode/tasks.json中定义{ version: 2.0.0, tasks: [ { label: git commit (safe), type: shell, command: git commit -m \${input:commitMessage}\, presentation: { echo: true, reveal: always, focus: false, panel: shared, showReuseMessage: true, clear: true }, problemMatcher: [] } ], inputs: [ { id: commitMessage, type: promptString, description: Enter commit message } ] }然后按CmdShiftP→Tasks: Run Task→ 选择git commit (safe)。这样完全绕过 VS Code 的 Git 扩展用纯 Git 命令稳定如磐石。4.4 战术四终极防御在 VS Code 中可视化 hook 执行流很多团队不知道 VS Code 其实提供了 hook 调试能力。开启它打开 VS Code 设置搜索git.showOutput勾选再次提交VS Code 底部状态栏会出现Git按钮点击它就能看到完整的git commit和所有 hook 的 stdout/stderr更进一步在settings.json中添加{ git.showOutput: true, git.terminalAuthentication: true, git.alwaysSignOff: false }这样每次提交输出面板都会自动聚焦到 Git 日志再也不用靠猜。我们还写了一个小脚本自动分析.git/hooks/下所有脚本的调用链# save as analyze-hooks.sh #!/bin/bash for hook in .git/hooks/*; do [[ -f $hook ]] || continue echo $hook head -n 5 $hook | grep -E (yarn|npm|node_modules|exec) done执行bash analyze-hooks.sh3 秒内就能知道哪个 hook 在调用yarn比肉眼翻文件快 10 倍。5. 经验总结那些文档里不会写的实战心得5.1 关于 husky 版本的血泪教训我们曾在线上环境部署时因 husky 版本不一致引发严重事故开发者本地是 husky v4pre-commit脚本里写yarn run precommitCI 服务器装的是 husky v7它会忽略 v4 的 hook 脚本转而读取.huskyrc.json但.huskyrc.json里没配pre-commit导致 CI 的git commit完全不走 lint直接合并了带 bug 的代码。解决方案在package.json的engines字段中锁定 husky 版本并在 CI 的before_script中加入校验# .gitlab-ci.yml before_script: - | if [ $(node -p require(./package.json).devDependencies.husky) ! ^7.0.0 ]; then echo ERROR: husky version mismatch! exit 1 fi5.2 lint-staged 的隐藏陷阱glob 匹配失效lint-staged的配置里经常这么写// lint-staged.config.js module.exports { *.{js,ts}: [eslint --fix], *.{css,scss}: [stylelint --fix] };但 VS Code 的提交有时会把未跟踪的文件untracked files也纳入lint-staged范围而*.{js,ts}在 shell 中无法匹配 untracked 文件因它们不在工作区索引中。结果就是eslint收不到任何文件静默退出看似成功实则漏检。修复显式指定lint-staged的--concurrent false和--max-processes 1并改用绝对路径const path require(path); module.exports { [path.join(process.cwd(), **/*.{js,ts})]: [eslint --fix] };5.3 VS Code 的“假成功”现象最危险的一种情况VS Code 弹窗显示yarn run v1.22.19然后一闪而过你以为提交成功了其实没有。这是因为yarn run的 exit code 是 0成功但git commit本身因 hook 未完成而被中断。验证方法提交后立即执行git status。如果仍显示modified:或unstaged changes说明提交失败。预防方法在pre-commit脚本末尾加一句# 确保 git commit 真正执行 if [ $? -ne 0 ]; then echo ERROR: pre-commit hook failed. Aborting git commit. exit 1 fi5.4 给团队的标准化建议我们正在推行所有新项目初始化时执行npx simple-git-hooks echo {pre-commit: pnpm exec biome check --write .} .simple-git-hooks.jsonVS Code 工作区设置强制启用// .vscode/settings.json { git.showOutput: true, git.terminalAuthentication: true, editor.codeActionsOnSave: { source.fixAll: explicit } }每周五下午CI 自动扫描.git/hooks/告警任何含yarn run的 hook—— 这是我们用 Shell 脚本 Slack webhook 实现的5 分钟上线。最后分享一个小技巧当你再次看到yarn run v1.22.19弹窗别急着关。按CmdKmacOS或CtrlKWindows在 VS Code 输出面板里切换到Git频道然后滚动到底部。90% 的真实错误都藏在那几行被 banner 掩盖的日志里。看清它你就已经解决了问题的一半。
