context.withtimeout 不会自动中断 goroutine，必须在 goroutine 内用 select 监听 ctx.done() 并清理资源；time.sleep 不响应取消，应改用 select + time.after。
测试 context.WithTimeout 是否真正中断 goroutine
很多人写完带 context.WithTimeout 的异步任务，一跑单元测试就发现超时没生效——goroutine 还在跑，甚至资源没释放。根本原因不是 Context 本身失效，而是你没在业务逻辑里主动监听 ctx.Done()。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须在 goroutine 内部用
select监听ctx.Done()，不能只靠外部传入 context 就以为自动中断 - 监听到
ctx.Done()后，要清理资源（比如关闭 channel、取消子 context、释放锁） - 别在 goroutine 里直接用
time.Sleep模拟耗时操作——它不响应 cancel，要用time.AfterFunc或配合select+time.After
示例错误写法：
go func() {
time.Sleep(5 * time.Second) // 完全无视 ctx！
result <- "done"
}()正确写法：go func() {
select {
case <-time.After(5 * time.Second):
result <- "done"
case <-ctx.Done():
return // 真正退出
}
}()
用 testify/assert 验证超时路径是否触发
单纯看函数是否返回不够，得确认它走的是超时分支，而不是提前成功或 panic。常见错误是断言返回值，却漏掉对 context 取消行为的验证。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
assert.ErrorIs(t, err, context.DeadlineExceeded)而不是assert.Error(t, err)，避免误判其他错误 - 如果函数返回
result, err，且超时时result应为零值，需显式检查：assert.Zero(t, result) - 若内部启动了 goroutine 并向 channel 发送结果，测试时要加
select+time.After防死锁，比如：select { case r := <-resultCh: t.Fatal("should not receive result on timeout") case <-time.After(100 * time.Millisecond): // expected }
避免测试中 time.Sleep 引发的不稳定
用固定 time.Sleep(101 * time.Millisecond) 等待超时，看似简单，实际在 CI 或高负载机器上极易失败——调度延迟可能让 sleep 不够，或者 GC 暂停拖长执行时间。
详解Android中AsyncTask的使用 中文WORD版
下载
在Android中实现异步任务机制有两种方式，Handler和AsyncTask。本文档主要讲述的是详解Android中AsyncTask的使用；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远用
context.WithTimeout自身的 timeout 值做基准，比如设为10 * time.Millisecond，然后在测试里等20 * time.Millisecond作为安全上限 - 不要依赖 sleep 控制流程，改用 channel 同步：启动任务后，用
select等待结果或超时信号 - 如果必须 sleep（比如等待后台 goroutine 启动），用
time.Sleep(1 * time.Millisecond)而非更长值，再配合重试逻辑
子 goroutine 没继承父 context 的典型表现
测试通过但线上出问题？大概率是你在主 goroutine 里创建了子 goroutine，却没把 ctx 传进去，或者用了新 context（如 context.Background()）。这时即使父 context 超时，子 goroutine 仍永生。
常见错误现象：
- 测试里调用一次函数，pprof 显示 goroutine 数持续上涨
- 用
runtime.NumGoroutine()在 test teardown 前后对比，数值没回落 - 日志里看到“done”输出发生在超时之后
关键检查点：
- 所有
go func() { ... }()内部是否都接收并使用了传入的ctx参数？ - 有没有无意中调用
http.DefaultClient.Do(req)？它不读取 context，应改用http.NewRequestWithContext(ctx, ...)+client.Do(req) - 数据库查询、文件读写等阻塞操作，是否用了支持 context 的封装（如
db.QueryContext）？
测试最难的不是写断言，是确保 goroutine 真的停了，而且停得干净。很多 bug 表面是超时失效，实际是 context 没被任何地方消费，或者 cancel 信号被某层吞掉了。
