改一行文案，git commit 卡了九分多钟才出结果。钩子里跑的是 eslint 全量和全量单测，输出滚了几百行。日志里能对上时间点，这种反而好排。
钩子没有按暂存文件过滤，每次提交都对整个仓库跑一遍检查，文件越多越慢。测试类钩子还串行执行，本地机器上比 CI 慢好几倍。这一点先确认清楚，后面就不用反复试。
git diff --cached --name-only --diff-filter=ACM | grep -E '\.(js|ts)$' | xargs npx eslint SKIP=pytest git commit -m 'fix copy'
这次卡住的地方就在「pre-commit 耗时」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。偶发问题先统计频率，一小时几次和一天一次，查法完全不同。
改完顺手把文档补一句，省得下次自己重新推一遍。监控和日志的时间要对上，时区不一致会多绕很大一圈。
处理上按这个顺序：先看 .git/hooks/pre-commit 或 .pre-commit-config.yaml 里跑的命令；lint 改成只处理 git diff --cached --name-only 列出的文件；单测从提交钩子挪到 pre-push 或 CI；临时跳过用 SKIP 加钩子名 并记下原因；把耗时写进钩子输出 超过阈值就提示。
结果对不对很好判断，改一行再提交 钩子在十几秒内结束 检查范围只覆盖本次暂存文件。