t.Parallel未提速的根本原因是测试间存在共享状态或隐式依赖，导致运行时强制串行化甚至panic；它仅声明可并行，不解决资源竞争，需配合独立资源、正确调用位置及-go test -p参数才生效。
testing.T.Parallel 为什么没让测试变快？
根本原因通常是：测试函数里仍有共享状态或隐式依赖，导致并行实际被阻塞。Go 的 testing.T.Parallel 只是声明“这个测试可以并行”，不解决竞争问题——一旦多个测试 goroutine 同时读写同一个全局变量、临时文件路径、数据库连接池或未加锁的 map，运行时会强制串行化（甚至 panic），反而拖慢整体速度。
常见错误现象包括：fatal error: concurrent map writes、随机性失败、测试结果不稳定、CPU 利用率始终低于 50%。
- 每个并行测试必须拥有独立的资源上下文（如单独的临时目录、内存数据库实例、mock 客户端）
- 避免在测试中直接修改包级变量（
var db *sql.DB、var cfg Config） - 如果必须复用昂贵资源（如启动一次 HTTP server），用
sync.Once+ 全局锁初始化，但确保后续操作是线程安全的读取
如何正确调用 testing.T.Parallel()
testing.T.Parallel() 必须在测试函数开头、任何副作用发生前调用，否则会被忽略（Go 不报错，但无效）。它本质是向 test runner 注册该测试可与其他标记了 Parallel() 的测试并发执行。
示例中容易踩的坑：
func TestFetchUser(t *testing.T) {
t.Parallel() // ✅ 正确：第一行就调用
tmpDir := t.TempDir() // 自动清理，且每个测试独享路径
cfg := Config{DBPath: filepath.Join(tmpDir, "test.db")}
// ... 测试逻辑
}
错误写法：
func TestFetchUser(t *testing.T) {
db := getSharedTestDB() // ❌ 已经访问了共享资源
t.Parallel() // ⚠️ 太晚了，已失去意义
}
- 不能在子测试（
t.Run()）内部调用t.Parallel()来加速子测试——子测试默认就和父测试并行，除非显式阻塞 - 若测试中用了
t.Setenv()或t.Cleanup()，它们对并行安全，但环境变量修改只作用于当前 goroutine，不影响其他测试
哪些测试不适合加 Parallel()
不是所有测试都适合并行。关键判断依据是：是否存在跨测试的隐式顺序依赖或外部系统瓶颈。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 涉及真实网络请求（如调第三方 API）的测试：可能触发限流，或因响应延迟导致整体等待时间拉长
- 操作同一张 SQLite 文件或 PostgreSQL 表的测试：即使用了不同表名，也可能因 WAL 锁或连接池争用卡住
- 依赖系统时间的测试（如
time.Now().Unix()）：并行下时间戳高度接近，容易暴露逻辑漏洞 - 使用
os.Chdir()或修改os.Stdout的测试：全局进程状态不可隔离
这类测试建议显式跳过并行：// t.Parallel() // disabled: requires exclusive DB access，并在注释中说明理由，方便后续重构。
验证并行是否真正生效
光加 t.Parallel() 不代表提速。最直接的验证方式是用 -cpu=1 和 -cpu=4 对比执行时间，并观察 go test -v 输出中测试开始/结束的时间戳是否交错。
更可靠的方法是启用测试 trace：
go test -trace=trace.out && go tool trace trace.out
在浏览器打开后，切换到 “Goroutines” 视图，能看到多个 TestXXX 是否真正在不同 P 上同时运行。如果大量 goroutine 处于 runnable 或 semacquire 状态，说明存在锁竞争或 I/O 阻塞。
另一个信号是 go test -bench=. -benchmem 结合 -cpu 参数跑基准测试时的吞吐变化——若并行测试的基准性能无提升，大概率是资源瓶颈没拆开。
真正难的是把“看起来能并行”的测试，变成“实际上无干扰、可稳定提速”的测试；这往往需要重写 setup/cleanup 逻辑，而不是加一行 t.Parallel() 就完事。
