不是必须用 t.Parallel()，但不用它测试函数仍串行执行；t.Parallel() 仅允许与其他标记该方法的测试并发运行，需配合 -p 参数生效，且须避免状态竞争与 goroutine 中误调 t 方法。
并发测试必须用 t.Parallel() 吗？
不是必须，但不用它就不是真正的并发执行。Go 的测试框架默认串行运行每个 TestXxx 函数；t.Parallel() 仅表示“允许该测试与其他标记了 t.Parallel() 的测试并发运行”，前提是它们不共享状态或竞争资源。
- 多个测试函数都调用
t.Parallel()，Go 测试主程序才会并行调度它们（受-p参数控制） - 单个测试函数内部想并发执行子任务（比如启动 10 个 goroutine 模拟请求），不需要
t.Parallel()，直接用go即可 - 误在有状态依赖的测试里加
t.Parallel()，极易触发 data race ——go test -race会立刻报出类似Read at 0x00c000012340 by goroutine 7的错误
如何安全地在单个测试中启动多个 goroutine？
关键不是“能不能开 goroutine”，而是“怎么等它们结束 + 怎么捕获 panic + 怎么避免共享变量竞争”。推荐组合使用 sync.WaitGroup 和 defer recover()（如需捕获 panic）。
func TestConcurrentHTTPCalls(t *testing.T) {
var wg sync.WaitGroup
errors := make(chan error, 10)
for i := 0; i < 5; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
// 注意：不要直接引用循环变量 i，要传参
resp, err := http.Get("https://httpbin.org/delay/1")
if err != nil {
errors <- err
return
}
resp.Body.Close()
}(i)
}
go func() {
wg.Wait()
close(errors)
}()
// 收集所有错误（最多等 3 秒）
timeout := time.After(3 * time.Second)
for {
select {
case err, ok := <-errors:
if !ok {
return
}
if err != nil {
t.Errorf("request %d failed: %v", i, err) // 注意：这里 i 已失效，应改用闭包传入的 id
}
case <-timeout:
t.Fatal("timeout waiting for requests")
}
}}
go test -p=4 和 t.Parallel() 是什么关系？
-p=N 控制测试进程级并行度（即最多同时跑 N 个 TestXxx 函数），而 t.Parallel() 是告诉测试驱动：“这个函数可以被放入并行池”。两者配合才生效。
立即学习“go语言免费学习笔记（深入）”；
- 没调用
t.Parallel()：即使-p=10，该测试也永远排在串行队列里 - 调用了
t.Parallel()但-p=1：所有标记的测试仍会串行执行（因为只允许 1 个活跃测试） - 典型配置：
go test -p=8 -race—— 启用竞态检测的同时，最多并行跑 8 个测试函数 - 注意：
-p值不能超过 GOMAXPROCS，默认等于 CPU 核心数，但可被GOMAXPROCS环境变量覆盖
为什么并发测试经常 panic 却没输出具体位置？
因为 goroutine 中的 panic 不会自动传播到主测试 goroutine，会被静默吞掉，除非显式 recover 或使用 t.Log/t.Error 在主 goroutine 汇总。
- 最简修复：在每个 goroutine 内部加
defer func() { if r := recover(); r != nil { t.Errorf("panic in goroutine: %v", r) } }() - 更稳妥做法：把错误通过 channel 发回主 goroutine，在那里统一
t.Error（如上例） - 别依赖
log.Fatal或os.Exit—— 它们会直接终止整个测试进程，跳过其他测试和清理逻辑 - 如果用了
t.Parallel()，还要注意：不能在 goroutine 中调用t.Helper()或修改t的状态（如t.Skip()），会 panic 报test is not running
并发测试真正难的不是启 goroutine，是厘清“谁负责等待、谁负责错误收集、谁负责超时控制”——这三个角色一旦混在一起，失败时根本看不出是卡死、panic 被吞，还是 channel 漏读。
