应显式用recover捕获goroutine内panic，并通过channel传递错误供主goroutine断言；配合sync.WaitGroup确保goroutine执行完毕，避免time.Sleep。
如何用 test 包捕获 goroutine 中的 panic
Go 测试中，goroutine 内部 panic 不会传播到主测试 goroutine，导致测试“假通过”。比如你写了 go fn() 但没加 recover，panic 会被吞掉，go test 仍显示 PASS。
实操建议：
- 在启动 goroutine 的函数内显式加
recover()，并把错误发到 channel 供主 goroutine 断言 - 用
sync.WaitGroup确保 goroutine 执行完再结束测试 - 避免用
time.Sleep等待，它不可靠且拖慢测试
示例：
func TestAsyncPanic(t *testing.T) {
errCh := make(chan error, 1)
var wg sync.WaitGroup
wg.Add(1)
go func() {
defer wg.Done()
defer func() {
if r := recover(); r != nil {
errCh <- fmt.Errorf("panic: %v", r)
}
}()
panic("boom")
}()
wg.Wait()
select {
case err := <-errCh:
if err == nil {
t.Fatal("expected panic but got none")
}
default:
t.Fatal("no error received, panic not captured")
}
}如何验证异步操作是否在指定时间内完成
超时控制是异步测试的核心。直接依赖 time.Sleep 会导致测试不稳定（太快可能没完成，太慢又拖累 CI）；而用 select + time.After 是标准做法。
立即学习“go语言免费学习笔记（深入）”；
注意点：
-
time.After不能替代 context 超时——若操作提前完成，timer 仍会触发，需用select配合default或闭 channel 判断是否已结束 - 对带 context 的函数（如
Do(ctx)），测试时应传入context.WithTimeout，并在 defer 中 cancel - 避免在测试中用
time.Now().Add(...)做逻辑判断，应统一走 channel 通信
示例（验证操作 ≤ 100ms 完成）：
func TestAsyncTimeout(t *testing.T) {
ctx, cancel := context.WithTimeout(context.Background(), 100*time.Millisecond)
defer cancel()
<pre class="brush:php;toolbar:false;">done := make(chan struct{})
go func() {
defer close(done)
time.Sleep(50 * time.Millisecond) // 模拟异步工作
}()
select {
case <-done:
// 成功
case <-ctx.Done():
t.Fatal("operation timed out")
}}
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
如何测试并发写共享变量的竞态问题
Go 的 -race 检测器是唯一可靠手段。仅靠人工检查或加锁逻辑推演无法发现真实竞态，尤其当读写发生在不同 goroutine 且无同步原语时。
关键动作：
- 所有涉及并发读写的测试必须用
go test -race运行，CI 中也应开启 - 不要在测试里“手动加锁模拟安全”，那测的是锁逻辑，不是原始代码行为
- 如果被测函数本身不处理并发安全（如一个全局 map），测试中就该暴露它——让 race detector 报错，再决定是否加
sync.RWMutex或改用sync.Map
典型错误现象：WARNING: DATA RACE 日志中会明确标出 read/write 的 goroutine 栈、文件与行号，直接定位到问题变量。
如何验证回调函数是否被正确调用（含参数校验）
异步 API 常以 callback 或 channel 返回结果，测试重点不是“是否调用”，而是“是否按预期时机、参数、次数调用”。
推荐方式：
- 用匿名函数捕获调用状态：定义
called bool、args []interface{}、callCount int等变量，在 callback 内修改它们 - 避免用指针传参去“间接修改”，容易因闭包捕获引发意外共享
- 对多次调用场景（如流式回调），用
sync.WaitGroup控制等待，而非固定 sleep - 注意 callback 是否在 goroutine 内执行——若被测代码自行启 goroutine 调用 callback，测试需同步等待
示例片段：
func TestAsyncCallback(t *testing.T) {
var called bool
var received string
callback := func(s string) {
called = true
received = s
}
<pre class="brush:php;toolbar:false;">DoAsyncWork(callback) // 启动异步操作
// 等待完成（实际中建议用 channel 或 WaitGroup）
time.Sleep(10 * time.Millisecond)
if !called {
t.Fatal("callback was not called")
}
if received != "expected" {
t.Fatalf("expected 'expected', got %q", received)
}}
异步测试最易忽略的，是“完成”的定义本身——它可能指 goroutine 退出、channel 关闭、callback 执行、或某个共享状态变更。不同场景要匹配不同的同步机制，而不是套用一种模板。
