pre-push钩子在VSCode中不触发，根本原因是VSCode推送绕过Git原生命令链，需移至终端或自定义Task执行；并行测试须删--runInBand、用--threads/--maxWorkers，并确保exit码透传。
pre-push钩子在 VSCode 里不触发 Node 测试？先确认 Git 是否真走原生流程
VSCode 点“推送”按钮时，pre-push 钩子不执行，根本原因不是 Husky 没配好，而是 VSCode 默认用内部逻辑绕过 Git 原生命令。它调用的是 git push 的封装 API，而非 shell 中的完整命令链，导致钩子文件压根没被加载。
验证方法：在终端里手动运行 git push origin main，如果这时钩子能跑、测试能并行，那问题就锁定在 VSCode 提交路径上。
- 必须关闭
git.enableSmartCommit（它只影响 commit，但很多人误以为关了就万事大吉） - 真正要关的是
git.useEditorAsCommitMessage和git.postCommitCommand这类干扰项，但更关键的是——VSCode 推送行为本身不可配置为“强制走 shell” - 所以唯一可靠路径：把推送操作从 VSCode 图形界面移出，统一收口到终端或自定义 Task
如何让 pre-push 脚本真正并发跑 Jest / Vitest 测试
Husky 的 .husky/pre-push 是 shell 脚本，Node 测试命令默认单线程串行。想并行，不能靠 npm test 本身（除非脚本里已封装），而要显式控制进程粒度。
常见错误是直接写 npx jest --runInBand —— 这个 flag 强制单线程，专为调试留的，上线前必须删掉。
- 使用
npx vitest run --threads（Vitest 默认开启多线程，--threads可显式启用） - Jest 需加
--maxWorkers=50%或具体数值，比如--maxWorkers=4，避免榨干 CPU 导致机器卡死 - 若测试分散在多个包（monorepo），别用
pnpm run test全局跑，改用pnpm -r --filter ./packages/* test -- --threads，否则顶层 script 可能阻塞子包并发 - 注意
jest.config.js里别设maxConcurrency: 1，这个配置会覆盖 CLI 参数
VSCode Tasks 替代图形推送：让 pre-push 有 Node 环境且可调试
与其折腾 VSCode 推送按钮，不如用 tasks.json 定义一个“带 Node 环境的推送任务”，既能保证 pre-push 触发，又能复用 nvm 或 volta 管理的 Node 版本。
关键点在于：VSCode Task 启动时默认不加载 shell profile（~/.zshrc），nvm 切换的 Node 对它不可见，结果 pre-push 里 node 命令找不到或版本错乱。
- 在
.vscode/tasks.json里显式指定env，例如："env": {"PATH": "/Users/you/.nvm/versions/node/v20.15.0/bin:${env:PATH}"} - 或者改用
shell类型 +command调用完整 shell，如："command": "zsh -i -c 'git push origin ${input:branch}'"，-i表示交互模式，会加载~/.zshrc -
pre-push脚本开头加echo "NODE_VERSION: $(node --version)"，用于快速验证环境是否对齐
pre-push 并行测试失败后，Git 不该静默吞掉错误
很多团队发现测试失败但推送仍成功，是因为 pre-push 脚本末尾没正确传递退出码，或者用了 && 连接符但中间某条命令失败后没终止后续逻辑。
典型陷阱：npx vitest run && git push 写在钩子里 —— 这会让 git push 在测试失败后仍被执行，因为 && 只控制同一行命令流，而 Husky 执行的是整个脚本，需靠 exit 显式中断。
- 必须在测试命令后加判断：
if [ $? -ne 0 ]; then exit 1; fi - 更稳妥写法是用
set -e开头，让任意命令失败立即退出脚本 - 如果用了
lint-staged或其他工具链，确保它们的 exit code 被透传，比如npx lint-staged || exit 1 - 别依赖 VSCode 的“推送成功”提示框——它只反映 Git 操作是否完成，不管钩子返回值
实际生效的关键，从来不是“怎么写并发参数”，而是确保 pre-push 脚本真正在你期望的 Node 环境下、以你期望的权限、被你期望的 Git 流程调用。三者缺一，再多线程也白搭。
