Go并发测试需为每个goroutine单独加defer+recover并用chan error收集错误，否则panic会逃逸导致测试静默失败或进程退出；必须确保recover数量与goroutine数量严格一致。
Go 的并发测试本身不“返回结果”，goroutine 启动后即异步执行，错误或 panic 不会自动回传到主协程——所以你无法像调用函数那样“捕获测试结果”。真正要做的，是**主动设计错误传递通道 + 每个 goroutine 独立 recover**，否则测试会静默失败、panic 导致进程退出，甚至掩盖真实问题。
为什么 go test 里直接起 goroutine 容易漏掉 panic
在单元测试中写 go riskyFunc()，若该函数 panic，测试进程大概率直接退出（哪怕你写了 defer 在主函数里），因为：
• recover() 只对**同 goroutine** 中的 panic 有效
• 主 goroutine 的 defer 捕不到子 goroutine 的 panic
• Go 测试框架不会自动为每个 goroutine 注入 recover
- 现象：测试输出
panic: ... exit status 2，但没看到任何t.Error或日志，测试直接中断 - 根本原因：子 goroutine panic 后未被 recover，触发 runtime 默认终止行为
- 后果：你以为测试通过了，其实某个并发路径早已崩溃
必须给每个 goroutine 单独加 defer + recover
不是“加一次就够了”，而是每个可能出错的并发任务入口，都要包裹自己的错误防护。这是硬性要求，没有例外。
func safeGo(f func()) {
go func() {
defer func() {
if r := recover(); r != nil {
// 注意：这里不能直接 t.Error，因为不在测试 goroutine 上下文中
log.Printf("goroutine panic: %v\n%s", r, debug.Stack())
// 更推荐：把错误发到 channel，由主 goroutine 统一断言
}
}()
f()
}()
}- 别试图在
safeGo内部调用t.Error——*testing.T不跨 goroutine 安全 - 如果需要断言 panic 是否发生，用
chan error收集子 goroutine 错误 -
debug.Stack()必须加，否则只看到panic: xxx，完全无法定位哪一行
用 chan error 汇总并发任务错误（实操推荐）
这是最可控、可断言、符合 Go 风格的做法：让每个 goroutine 把错误（包括 recover 到的 panic）写入同一个 error 通道，主测试 goroutine 读取并校验。
立即学习“go语言免费学习笔记（深入）”；
func TestConcurrentOperations(t *testing.T) {
errCh := make(chan error, 10) // 缓冲足够，避免 goroutine 阻塞
for i := 0; i < 5; i++ {
go func(id int) {
defer func() {
if r := recover(); r != nil {
errCh <- fmt.Errorf("goroutine %d panicked: %v", id, r)
return
}
}()
// 模拟可能 panic 的操作
if id == 2 {
panic("simulated failure")
}
errCh <- nil
}(i)
}
// 等待所有 goroutine 结果（简单起见用计数，生产建议用 sync.WaitGroup）
for i := 0; i < 5; i++ {
if err := <-errCh; err != nil {
t.Errorf("task %d failed: %v", i, err)
}
}}
- 缓冲通道大小必须 ≥ goroutine 数量，否则写入会阻塞，导致死锁
- 不要用
for range errCh—— 通道不会自动关闭，会永远等待 - 若需区分 panic 和业务错误，可在 error 中嵌入类型或前缀，比如
fmt.Errorf("panic: %v", r)
最容易被忽略的一点：你在测试里启动了 10 个 goroutine，就得确保有且仅有 10 次 recover 设置——少一个，就有一个 panic 会逃逸出去，让整个 go test 进程跪掉。这不是理论风险，是每天都在 CI 里发生的真事。
