context.WithTimeout不生效的典型表现是异步goroutine未被取消且测试超时panic；常见错误包括未将ctx传给实际执行的goroutine或I/O操作，以及select中遗漏case
Go test 中 context.WithTimeout 不生效的典型表现
测试里调用 context.WithTimeout 后，异步 goroutine 依然没被 cancel，甚至 test panic 报 test timed out after 10s —— 这说明 context 没真正传下去，或者下游没响应 Done()。
- 常见错误：只在函数入口创建
ctx, cancel := context.WithTimeout(context.Background(), time.Second)，但没把ctx传给实际干活的 goroutine 或依赖的 I/O 操作（比如http.Client.Do、time.Sleep、自定义 channel 等） - 更隐蔽的问题：用了
select但漏了case 分支，或写了但没调 <code>cancel()导致资源泄漏 - 注意：
context.WithTimeout的超时是相对于它被创建的那一刻，不是测试开始时刻；如果中间有延迟再启动 goroutine，实际可用时间会变短
验证链路超时必须检查的三个位置
一个完整的 timeout 链路要贯穿「发起 → 执行 → 响应」，缺一不可。重点看这三处是否都接入了 context：
-
http.Client是否设置了Timeout字段？否。应该用client.Do(req.WithContext(ctx))，而不是靠 client 自身 timeout - 自定义 goroutine 内部是否监听
ctx.Done()？例如：select { case - 被测函数返回前是否调用了
cancel()？不调不会直接 break 测试，但会导致 goroutine 泄漏，后续 test 可能变慢或失败
写可测异步函数时 context 参数的位置约定
Go 社区惯例如下：context 必须是第一个参数，且类型为 context.Context。这不是语法要求，但影响可测性与一致性。
- 反例：
func DoWork(id string, data []byte, timeout time.Duration) error—— timeout 是 magic number，无法在 test 中灵活控制 - 正例：
func DoWork(ctx context.Context, id string, data []byte) error—— test 里可自由注入context.WithTimeout或context.WithCancel - 注意：如果函数内部 spawn goroutine，必须显式将
ctx传进去；不能依赖闭包捕获外部 ctx 变量，因为那可能是已 cancel 的旧 ctx
测试中模拟超时失败的最小可靠写法
别用 time.Sleep 等待超时，容易受调度影响；用 ctx.Done() + select 显式等待结果更稳。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
func TestDoWork_Timeout(t *testing.T) {
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Millisecond)
defer cancel()
<pre class="brush:php;toolbar:false;">err := DoWork(ctx, "test", []byte("data"))
if !errors.Is(err, context.DeadlineExceeded) && !errors.Is(err, context.Canceled) {
t.Fatalf("expected timeout error, got %v", err)
}}
- 关键点：用
errors.Is(err, context.DeadlineExceeded)判断，而不是字符串匹配，因为不同 Go 版本错误文本可能微调 - 别在 test 里写
time.Sleep(20 * time.Millisecond)等待超时 —— 这会让 test 变慢，且不稳定 - 如果被测函数本身不返回 error，而是通过 channel 返回结果，那就必须在 test 里用
select监听ctx.Done()和 result channel，否则无法断言超时行为
context 传不进 goroutine、Done() 没被 select 监听、错误类型没用 errors.Is 判断 —— 这三处最容易漏，一漏测试就形同虚设。
