应使用 select + time.After 防止测试无限阻塞：所有 chan 操作须置于 select 中，配 time.After(500ms) 作超时兜底，避免 time.Sleep 硬等待；超时时间宜适中，且 goroutine 启动后必须显式等待或超时。
用 select + time.After 防止测试无限阻塞
Go 测试异步回调最常踩的坑是：回调没触发，channel 一直阻塞，测试卡死或超时失败。不能靠 `time.Sleep` 硬等，得用可控的超时机制。
实操建议：
- 所有等待回调的
chan操作必须套在select里，搭配time.After(500 * time.Millisecond)作为兜底分支 - 超时时间别设太短（比如 1ms），避免因调度延迟误判失败；也别太长（如 5s），拖慢整个测试集
- 不要在测试中启动 goroutine 后直接 return —— 必须显式等待信号或超时
示例：
done := make(chan error, 1)
go func() {
err := doAsyncWork(callback) // callback 写入 done
done <- err
}()
select {
case err := <-done:
if err != nil {
t.Fatal(err)
}
case <-time.After(300 * time.Millisecond):
t.Fatal("callback never called")
}回调函数里往 channel 发送值要带缓冲或用 select 防死锁
测试中常把 channel 当作回调“通知器”，但若 channel 无缓冲且测试还没来得及接收，回调 goroutine 就会卡在发送处 —— 导致被测逻辑卡住、甚至死锁。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 测试用的 signal channel 建议设缓冲：
make(chan struct{}, 1)或make(chan bool, 1)，避免发送阻塞 - 如果必须用无缓冲 channel，回调里要用
select+default非阻塞发送，防止被测代码 hang 住 - 别在回调里做耗时操作（如 HTTP 请求、文件写入）—— 测试应聚焦逻辑，IO 应 mock
错误写法（可能死锁）：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
done := make(chan struct{}) // 无缓冲
callback := func() { done <- struct{}{} } // 卡在这儿正确写法（带缓冲）：
done := make(chan struct{}, 1)
callback := func() { done <- struct{}{} } // 立即返回多个回调或嵌套异步场景下，用 sync.WaitGroup + channel 组合计数
当被测函数触发多次回调（比如重试、批量处理），或回调里又启了新 goroutine，单个 channel 不够用，容易漏信号或误判完成。
实操建议：
- 用
sync.WaitGroup控制“回调总数”，每个回调执行完调wg.Done() - 用
channel做最终完成通知（比如close(done)），避免轮询wg状态 - 别在回调里直接修改测试作用域变量（如
count++）—— 竞态难排查，优先走 channel 或 wg
示例结构：
wg := sync.WaitGroup{}
done := make(chan struct{})
wg.Add(3)
go func() { defer wg.Done(); callback1(); }()
go func() { defer wg.Done(); callback2(); }()
go func() { defer wg.Done(); callback3(); }()
go func() { wg.Wait(); close(done) }()
select {
case <-done:
case <-time.After(500 * time.Millisecond):
t.Fatal("not all callbacks fired")
}测试 panic 场景时，recover 要在回调 goroutine 内部做
如果被测异步逻辑在回调里 panic，而测试主 goroutine 没捕获，整个测试会崩溃退出，不是失败而是中断 —— 你根本看不到失败原因。
实操建议：
- 在回调函数内部加
defer func(){ recover() }()，把 panic 转成可检查的 error 或信号 - 不要指望测试主 goroutine 的
recover能捕获其他 goroutine 的 panic —— Go 不支持跨 goroutine recover - 如果回调 panic 是预期行为（比如参数校验），就通过 channel 发送特定 error 值，再在测试中 assert
关键点：panic 不会自动传播到发起 goroutine，它只杀死当前 goroutine，除非你主动传递。
