基准测试应以真实负载为准，优先使用 testing.B；初始化须在 b.ResetTimer() 前完成，避免计入分配开销；slice 随机读快但中间增删需拷贝，append 容量突变引发 realloc；map 查找均摊 O(1)，小数据时性能未必优于 slice。
用 go test -bench 测量 slice、map、sync.Map 的实际开销
基准测试不是看代码多“优雅”，而是看在真实负载下谁更扛压。Golang 自带的 testing.B 是唯一推荐起点，别手写计时器——它自动处理预热、多次运行、统计抖动。
常见错误是直接在 BenchmarkXxx 函数里做初始化：比如每次迭代都 make([]int, 1000)，这会把内存分配时间全算进结果。正确做法是把初始化提到 b.ResetTimer() 之前，或者用 b.ReportAllocs() 分离观察分配次数。
-
slice随机读快，但插入/删除中间位置需拷贝；测append时注意容量突变（如从 1024→2048）会触发 realloc，拉高单次耗时 -
map查找平均 O(1)，但小数据量（[]struct{key,val} 线性扫描快，因为哈希计算+指针跳转有固定开销 -
sync.Map只在并发读多写少场景有优势；纯单协程下比原生map慢 3–5 倍，别无脑替换
避免 BenchmarkMapSet 类测试被编译器优化掉
Go 编译器看到没副作用的循环（比如只往 map 写值但不读），可能直接删掉整个循环。结果跑出来是 0 ns/op，这不是性能好，是测试失效。
强制保留计算的方法很简单：在循环末尾加一行 blackhole = m[key]（blackhole 是全局变量或传入的指针），或者用 runtime.KeepAlive(m)。更稳妥的是让每次操作依赖前一次结果，例如 key = key * 31 + 1。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别用
fmt.Println或log打点——I/O 会严重污染结果 - 用
b.SetBytes(int64(n))告诉工具本次操作处理的数据规模，后续可换算成 MB/s - 加
-benchmem参数看每操作分配多少字节，map的桶扩容和slice的 grow 都会在这里暴露
对比并发安全结构时必须控制 goroutine 数量和竞争强度
sync.Map 和 map + sync.RWMutex 的分水岭不在“是否并发”，而在“有多少 goroutine 同时读写同一键”。测错这点，结论就全偏了。
典型错误是启动 100 个 goroutine 全往同一个 key 写：sm.Store("shared", i)。这时 sync.Map 的 read map 快速路径完全失效，退化成锁竞争，反而比 RWMutex 更慢（因额外指针跳转）。要模拟真实场景，得让 key 分布足够散，比如用 fmt.Sprintf("key-%d", i%1000)。
- 用
b.RunParallel替代手起 goroutine，它自动分片输入并同步结束 - 测试
sync.Pool时，务必调用pool.Put回收对象，否则内存持续增长导致 GC 干扰结果 - Linux 下加
GOMAXPROCS=1跑单核基准，排除调度器抖动；再开多核看扩展性
注意 go test 默认不跑 CPU 密集型 benchmark 的充分预热
小循环（比如 10 次操作）容易被 CPU 频率调节、分支预测器冷启动影响，首几次迭代慢得离谱。Go 的 testing.B 默认只跑够总时间（如 1s），不保证迭代次数下限。
解决方法是显式设置最小迭代数：b.N = 1e6（放在 b.ResetTimer() 前），或用 -benchtime=5s 延长总时长。更重要的是看输出里的 “~” 符号：如果某次结果标着 123ns/op ± 15%，说明方差太大，需要检查是否混入 GC、系统中断或测试逻辑本身不稳定。
- 用
go tool trace抓取一次 benchmark 运行的完整调度轨迹，确认没有意外的 Goroutine 阻塞或 GC STW - 不同机器上对比数据前，先跑
go test -run=XXX -bench=.测本机 baseline，避免跨环境误判 - 真正关键的性能拐点往往在边界条件：比如
map从 64 个桶涨到 128 个桶的瞬间，或slice容量从 2^16 到 2^17 的 realloc —— 这些单次毛刺在平均值里会被抹平，得单独拉出来压测
