必须手动调用 b.RunParallel 或启动 goroutine；testing.B 默认串行执行，不显式启用并发则无法测试真实场景，b.RunParallel 自动分摊迭代且并发度由调度器动态决定，精确控并发需手动实现。
用 testing.B 测并发函数时，必须手动调用 b.RunParallel 或启动 goroutine
Go 的基准测试默认是单线程串行执行的，即使你代码里写了 go f()，testing.B 也不会自动并发运行。不显式启用并行，测出来的只是单 goroutine 下的吞吐，和真实并发场景脱节。
常见错误是写完并发逻辑后直接跑 go test -bench=.，发现结果波动大、数值低，却没意识到根本没触发并发执行路径。
-
b.RunParallel是最简单的方式：它会自动分配b.N次迭代到多个 goroutine 中，适合无状态、可乱序执行的压测（如纯计算、HTTP client 请求） - 若需控制并发数、共享状态或自定义调度（比如带连接池、限速、依赖初始化），就得手动用
sync.WaitGroup+go启动，且必须在b.ResetTimer()后开始计时，否则初始化开销会被计入耗时 - 别在
b.N循环内反复创建 goroutine 并等待——这本质还是串行；应把“启动 N 个 goroutine”作为一次操作，让它们持续工作直到完成全部任务量
b.RunParallel 的 poolSize 不等于 GOMAXPROCS，实际并发度由调度器动态决定
b.RunParallel 接收一个函数，该函数参数是 *testing.PB，它内部会按需拉起多个 goroutine 调用该函数。但这个“多个”不是固定值，也不受 GOMAXPROCS 直接限制——它取决于 b.N 总迭代数、调度器当前负载以及 runtime 对 work-stealing 的判断。
例如：b.RunParallel(func(pb *testing.PB) { for pb.Next() { doWork() } })，哪怕 b.N = 1000，也可能只启 4 个 goroutine 分摊这 1000 次调用，而非 1000 个。
立即学习“go语言免费学习笔记（深入）”；
- 想逼近最大并发能力，可先设
runtime.GOMAXPROCS(0)让 Go 使用全部逻辑 CPU，再配合足够大的b.N（比如百万级） - 若要精确控制并发数（如模拟 50 个客户端），不用
b.RunParallel，改用手动for i := 0; i +sync.WaitGroup -
b.RunParallel内部不保证各 goroutine 执行次数均等，pb.Next()是原子递减，所以总调用次数严格等于b.N，但分布可能不均
并发基准测试中，共享资源竞争会导致结果失真，必须隔离或模拟真实瓶颈
很多并发函数看似快，一放到基准测试里就变慢甚至 panic，原因常是测试代码无意中引入了竞争：比如多个 goroutine 共用一个未加锁的 map、共用一个未复用的 http.Client、或反复创建 sync.Mutex 实例。
更隐蔽的问题是：测试环境没有真实瓶颈（如内存充足、无网络延迟、磁盘 I/O 极快），导致测出的“高 QPS”在生产环境完全不可复现。
- 对 map、slice 等共享数据结构，要么用
sync.Map，要么为每个 goroutine 分配独立实例（如每个 worker 持有自己 local cache） - HTTP 客户端务必复用
http.Client和底层http.Transport，否则 DNS 解析、TCP 握手、TLS 协商全被重复执行，测的不是业务逻辑而是网络栈开销 - 若目标是测数据库访问，并发测试里不能用内存 mock，至少要用本地 sqlite 或 dockerized PostgreSQL，否则绕过了连接池、事务锁、索引竞争等关键路径
避免用 time.Sleep 或 rand 在基准测试中引入非确定性
基准测试要求每次运行可复现、结果稳定。加入 time.Sleep(10 * time.Millisecond) 或 rand.Intn(100) 会让每次 b.N 迭代耗时不一致，go test -bench 统计的 ns/op 就失去意义，还会因超时导致 BenchmarkXXX 失败。
尤其注意：某些库的 “wait for ready” 逻辑（如 etcd client 等待 leader 选举完成）在测试中会退化成随机等待，必须用 testify/mock 或接口注入可控的 clock 来规避。
- 需要模拟延迟？用
time.Now()记录起点，用time.Since()控制逻辑分支，但不要阻塞 goroutine - 需要随机数据？用固定 seed 初始化
rand.New(rand.NewSource(123))，确保每次生成序列一致 - 涉及 channel 阻塞或
select超时？把 timeout 设为固定值（如time.Second），而不是time.Duration(rand.Int63n(1e9))
真实并发性能不是看单次 goroutine 多快，而是看系统在资源约束下能维持多少稳定吞吐。最容易被忽略的是：没把初始化开销（如连接池 warm-up、cache 预热）和测量区间分开，或者把 GC 峰值抖动当成了业务延迟。
