VSCode里推送时，pre-push钩子不触发，这事儿其实挺常见的。根源不在Husky配置，而是VSCode的推送机制绕过了原生命令链——它调用的是一套封装API，不是shell环境里完整的git push命令，钩子文件压根没被加载。
怎么验证？很简单，打开终端，手动跑一次git push origin main。如果这时候钩子能正常跑，测试也能并行执行，那问题就锁定在VSCode的提交路径上。
说到这里，有几个设置需要留意：git.enableSmartCommit当然要关，但很多人以为关了它就万事大吉。真正需要警惕的其实是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，否则顶层脚本可能会阻塞子包的并发 - 记得检查
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)"，用来快速验证环境是否对齐
并行测试失败后，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流程调用。这三者缺一不可，再多线程配置也白搭。
