因为Go语言中for循环的初始化、条件、后置语句三部分必须完整，缺一不可，若省略条件会导致无限循环。
为什么不能直接用 for i := 0; i 测并发？
因为 b.N 是整个基准测试的**总迭代次数**，不是每个 goroutine 的次数。如果你在 b.RunParallel 内部手写循环跑 b.N 次，多个 goroutine 就会重复执行、严重超量，导致 ns/op 失真甚至 panic。
- 正确做法：只靠
pb.Next()驱动——它是并发安全的计数器，自动把b.N分摊给所有 worker - 错误现象：
BenchmarkXXX-8 200000000 5 ns/op看似极快，实则是 8 个 goroutine 各跑b.N次，总次数翻了 8 倍 - 后果：结果不可比、无法反映真实吞吐、可能触发数据竞争（比如共用 map 未加锁）
b.RunParallel 怎么初始化被测对象才安全？
共享资源初始化位置错了，测的就不是业务逻辑，而是锁争抢或 GC 压力。
- 线程安全对象（如
sync.Map、atomic.Value）：放在b.RunParallel外部初始化，一次创建、多 goroutine 共用 - 非线程安全或需隔离状态的对象（如缓存、连接、临时 slice）：必须在
b.RunParallel回调内部创建，或用sync.Pool管理 - 反例：在外部建一个普通
map，然后在pb.Next()循环里读写——直接 panic 或结果崩溃
如何观察并发扩展性？关键命令和参数怎么配？
单次跑 -cpu=8 没意义，必须横向对比不同并发度下的 ns/op 和吞吐变化趋势。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
-cpu=1,2,4,8让 Go 自动切换GOMAXPROCS，输出形如BenchmarkConcurrentMap-1、-2、-4…方便识别 - 加
-benchmem查看allocs/op：高并发下分配次数飙升，往往意味着逃逸或频繁 new，比 CPU 耗时更早暴露瓶颈 - 加
-count=3 -benchtime=3s减少系统噪声，避免首轮冷启动偏差影响判断 - 别漏掉
b.ReportAllocs()—— 没它，-benchmem可能不统计部分分配
table-driven + b.RunParallel 怎么组合才高效？
想同时压测多种算法、不同数据规模、多个并发 worker 数？硬写几十个 BenchmarkXxx 函数太累，用表格驱动+嵌套 b.Run 更清晰。
立即学习“go语言免费学习笔记（深入）”；
- 外层用
b.Run定义场景（如"sync.Map-1e5"），内层用b.RunParallel并发执行 - 名字要唯一可读：
fmt.Sprintf("%s-%d-workers%d", algo, size, workers)，否则结果日志分不清谁是谁 - 避免在
b.RunParallel里做耗时初始化（如make([]byte, size)）——应提至外层b.Run中，并用b.ResetTimer()排除 - 若某组用例需要独立资源（如每个 worker 用专属
http.Client），就在b.RunParallel回调开头创建，别复用
b.RunParallel 测试，必须让每个 goroutine 的工作流彼此独立、资源访问路径可扩展，否则你优化的只是锁的排队速度。 
