go test -timeout 仅作用于整个测试包，不控制单个测试函数；它只在测试函数返回后检查超时，若测试卡死在 sync.WaitGroup.Wait() 或无缓冲 channel 操作上则无法及时终止。
go test -timeout 只管“整包”，不管单个测试
它只在测试函数返回后才检查是否超时，如果测试卡死在 sync.WaitGroup.Wait()、无缓冲 channel 的 或 <code>net.Dial() 这类阻塞调用里，go test -timeout=30s 就完全失效——进程不会退出，CI 流水线只能硬等超时或被平台强杀。
- 适用场景：防整包挂死（比如 init 函数死循环、全局 goroutine 泄漏未回收）
- 不适用场景：HTTP 请求、DB 查询、sleep 等单个耗时操作的精准控制
- 它不触发任何取消信号，也不影响
context或time.After的行为 - 默认不设值时，
t.Deadline()返回零时间，直接time.Until(deadline)会 panic
单个测试内必须自己加 context.WithTimeout
真正能中断卡住逻辑的，是你在 t.Run() 里主动创建并传入的 context.Context，且被测代码必须监听 ctx.Done() 并及时退出。
- HTTP 请求要用
req.WithContext(ctx)，不能只靠http.Client.Timeout（它不覆盖 DNS 解析） - 数据库查询必须用
db.QueryContext(ctx, ...)，而非db.Query(...) -
time.Sleep(5 * time.Second)无法被取消，得换成select { case - 启动的 goroutine 必须在
ctx.Done()后 clean exit，主协程要wait它们，否则算泄漏 -
cancel()一定要调，哪怕已超时——否则 timer 不释放，可能引发 GC 压力（尤其高频测试）
t.Deadline() 和 context.WithTimeout 别混用冲突
如果你在 CI 里跑了 go test -timeout=10s，又在测试里写 context.WithDeadline(ctx, time.Now().Add(15*time.Second))，那这个 context 根本不会超时——它比整个测试时限还长，起不到保护作用。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：先检查
t.Deadline()是否有效，再用time.Until(deadline)算出剩余时间，传给context.WithTimeout - 示例：
if deadline, ok := t.Deadline(); ok { ctx, cancel := context.WithTimeout(context.Background(), time.Until(deadline)/2) defer cancel() // 用 ctx 调用被测逻辑 } - 别硬编码超时值，尤其嵌套
t.Run()时，子测试应继承父测试的剩余时间预算 -
t.Cleanup()不受超时保护，清理函数里仍需手动检查t.Failed()或ctx.Err()
模拟慢服务验证超时逻辑，别只信真实接口
光看 context.DeadlineExceeded 错误出现不算完。你得确认系统在超时后是否真的没堆积 goroutine、没复用失败连接、没返回错误状态码。
立即学习“go语言免费学习笔记（深入）”；
- 用
httptest.Server搭配time.Sleep控制响应延迟，比依赖不稳定第三方更可靠 - 测试前后记一次
runtime.NumGoroutine()，差值异常增长说明有 goroutine 泄漏 - 设置低
MaxIdleConnsPerHost+ 高频超时请求，观察是否出现connection refused - 错误断言别只写
assert.Error(t, err)，要具体到errors.Is(err, context.DeadlineExceeded)或 HTTP 状态码是否 fallback 成功
超时不是加个 context.WithTimeout 就完事——被测函数是否真响应 ctx.Done()、goroutine 是否收干净、清理函数是否绕过超时检查，这些地方一漏，测试就只是看起来“过了”。
