t.parallel() 并非“越多越好”，它仅对真正耗时的测试才有实际加速价值；普通快速测试并行化反而可能因调度开销抵消收益，标准库极少使用正体现了这一设计哲学。

在 Go 的 testing 包中，t.Parallel() 是一个显式声明——它不开启全局并行，而是将当前测试函数标记为“可与其他调用了 t.Parallel() 的测试并发执行”。关键在于：它只影响 go test -p=N（默认 N=1）下测试组的调度行为，且*所有并行测试必须在同一 `testing.T上调用t.Parallel()` 才会被 Go 测试主框架识别为可并行集合**。

✅ 正确使用场景（何时加？）

仅当满足以下全部条件时，才应添加 t.Parallel()：

• 测试本身执行时间显著（例如 ≥100ms），常见于涉及 I/O、网络请求、数据库操作或复杂计算的集成/端到端测试；
• 测试间无共享状态依赖（如全局变量、临时文件、数据库表、HTTP 服务端口等），否则极易引发竞态或 flaky failure；
• 你已通过 -race 检测确认测试代码线程安全。

func TestAPIEndpoint_WithDatabase(t *testing.T) {
    t.Parallel() // ✅ 合理：DB 查询通常较慢，且每个测试使用独立事务或测试 DB 实例

    db := setupTestDB(t)
    defer db.Close()

    resp, err := http.Get("http://localhost:8080/api/users")
    if err != nil {
        t.Fatal(err)
    }
    // ... 断言逻辑
}

❌ 错误使用场景（为何标准库不用？）

标准库测试普遍极快（多数

• 触发 testing 包内部的串行化锁争用；
• 放大隐式状态污染（如多个测试同时修改同一全局 map）；
• 使 -race 难以捕获真实竞态（因调度不可控）。

正如 Russ Cox 所强调：“Most of our tests run so fast that parallelizing them is unnecessary.” —— 并行是特例，不是默认。

⚠️ 注意事项与最佳实践

• 不要盲目批量添加：grep -r 't.Parallel()' stdlib/ 结果稀少，正是经过权衡的设计选择；
• 必须配合 -p 参数生效：单独调用 t.Parallel() 不会提速，需显式运行 go test -p=4（推荐值 ≤ CPU 核心数）；
• 避免混合模式陷阱：若一个测试文件中部分测试调用 t.Parallel()，其余未调用，则后者仍按顺序执行，且会阻塞整个并行组的启动（Go 测试框架要求所有并行测试就绪后才统一并发调度）；
• 优先优化单测性能：对慢测试，先考虑是否可替换为 mock（如用 httptest.Server 替代真实 HTTP 调用）、减少 I/O、复用资源（如连接池），而非直接并行化。

总之，t.Parallel() 是一把精准的性能手术刀，而非万能加速器。理解其设计意图——为少数慢测试解耦执行时序，而非给所有测试“贴并行标签”——才能写出稳定、高效、可维护的 Go 测试套件。