Go测试慢主因是运行方式不当：需同时配置-p（包级并行）、-parallel（子测试并发）、-count=1（禁用缓存），并收窄测试范围、调整初始化顺序至t.Parallel()之后，避免共享资源竞态。
Go测试慢，八成不是代码问题，而是运行方式没调对。 并行、范围、缓存、初始化这四点没动，光改逻辑几乎没用。
go test -parallel 要配 -p 和 -count=1 一起用
只加 -parallel 4 不够——它只控制子测试（t.Parallel()）的并发度，而 Go 默认仍单线程跑包；真正提速得靠 -p 控制包级并行数。
-
go test -p 4：让 4 个包同时编译+运行，适合多模块项目 -
go test -parallel 4：仅对打了t.Parallel()的子测试生效，不加速串行测试函数 -
go test -count=1：禁用默认的两次运行缓存，避免误判“第二次快是真快”，实测中常掩盖真实耗时 - 常见错误：在 CI 中漏掉
-count=1，导致本地跑得慢、CI 看着快，结果上线才暴露性能毛刺
只测变更文件，别扫全量目录
大型项目里 go test ./... 动辄扫描上百个包，其中 90% 和本次修改无关。pre-commit 或本地验证阶段必须收窄范围。
- 用
git status --porcelain | grep '\.go$' | xargs dirname | sort -u提取变更目录，再传给go test - 配合
files过滤（如 pre-commit 配置中写files: ^(internal|pkg)/），跳过cmd/和examples/ - 对集成测试打构建标签：
//go:build integration，日常用go test -tags=unit隔离 - 注意：
go test不会自动识别 git 变更，必须手动传路径或靠钩子脚本驱动
初始化逻辑必须挪到 t.Parallel() 之后
很多测试把 DB 连接、mock 初始化写在函数开头，再调 t.Parallel()——这会导致所有并行子测试抢同一份资源，实际变成串行，还可能引发竞态。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 正确顺序：
t.Parallel()→ 各自独立 setup（如 new mock、开内存 DB）→ 执行被测逻辑 - 反模式示例：
db := setupTestDB(); t.Parallel(); runQuery(db)——db是共享的，t.Parallel()白加 - 若 setup 开销大（如启动 HTTP server），考虑用
sync.Once+ 全局变量做一次初始化，但务必确保线程安全 - 容易踩的坑：用
testify/mock时，忘记在每个子测试里重置 mock 行为，导致断言失效或漏报
golangci-lint 和 go test 别混在同一钩子里跑
pre-commit 中把 golangci-lint 和 go test 放进同一个钩子，等于强制串行——哪怕你开了 parallel: true，它们仍是单个 hook 进程里的两个步骤。
- 拆成两个独立 hook：
id: golangci-lint和id: go-unit-tests，pre-commit 才能真正并行调度 - 给
golangci-lint加--fast和--cache，跳过goconst、gosimple等慢 linter - 给
go-unit-tests加-short和-p 4，跳过耗时 >1s 的测试（需在测试函数里用if testing.Short() { t.Skip() }） - 注意：golangci-lint 的
--concurrency和 go test 的-p不是一个维度，前者是 linter 内部 worker 数，后者是包级调度数
最常被忽略的一点：b.ResetTimer() 在 benchmark 里是常识，但在普通测试里没人管初始化耗时——结果就是你优化了半天，其实 70% 时间花在了 make([]byte, 1e6) 上，而不是被测函数本身。
