Go基准测试必须严格遵循命名、签名、计时控制三重规范，否则go test -bench=.会静默跳过；函数名须为BenchmarkXXX(b *testing.B)，文件须为_test.go后缀且同包；b.ResetTimer()须置于初始化后、循环前以排除初始化开销。
Go 的基准测试不是“写个循环测时间”，而是必须严格遵循命名、签名、计时控制三重规范，否则 go test -bench=. 会静默跳过——不报错、不提示、不运行。
函数名和签名为什么必须是 BenchmarkXXX(b *testing.B)
这是 go test 唯一识别基准测试的模式。任何偏差都会导致函数被完全忽略：
-
BenchmarkFibonacci✅ 正确：首字母大写 + 驼峰 +*testing.B参数 -
benchmark_fib❌ 错误：小写开头，下划线分隔 -
BenchmarkFib(b testing.B)❌ 错误：漏掉指针符号*，类型不匹配 -
BenchmarkFib(b *testing.B, ctx context.Context)❌ 错误：多一个参数
文件也必须是 _test.go 后缀，且和被测代码同包。常见现象是执行 go test -bench=. 输出 no tests to run，大概率卡在这三处之一。
为什么 b.ResetTimer() 必须放在初始化之后、循环之前
基准测试默认从函数入口开始计时。如果初始化开销大（比如 make([]byte, 1e6) 或读文件），它会被计入 ns/op，导致结果严重失真——你看到的不是函数耗时，是“建大数组 + 调用函数”的总和。
立即学习“go语言免费学习笔记（深入）”；
正确结构：
func BenchmarkJSONMarshal(b *testing.B) {
data := map[string]int{"a": 1, "b": 2}
// 初始化完成，但不计时
b.ResetTimer() // 从此刻起才开始统计
for i := 0; i < b.N; i++ {
_ = json.Marshal(data)
}
}
若函数有副作用（如修改全局 map），重置逻辑也得放在 b.ResetTimer() 之前，否则后续迭代可能复用前次状态，测出假快。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
怎么避免编译器优化让函数“没跑”却显示 0.1 ns/op
Go 编译器会把未使用的返回值、无副作用的纯计算整个删掉。典型现象：函数明明很重，ns/op 却低得离谱（如 0.33 ns/op），allocs/op 也是 0。
解决办法只有一条：强制消费结果：
- 用
_ = yourFunc()不够——编译器仍可能优化掉整行 - 更可靠的是赋给全局变量：
var blackhole interface{}; blackhole = yourFunc() - 或在循环末尾加一句
blackhole = blackhole，防止进一步优化
验证是否被优化：加 go test -gcflags="-l" -bench=. 关内联；或看汇编：go tool compile -S your_bench_test.go，确认关键调用还在。
结果里 -8、B/op、MB/s 这些字段到底什么意思
BenchmarkJSONMarshal-8 中的 -8 表示当前 GOMAXPROCS=8，即调度器最多用 8 个 OS 线程——不是 CPU 核心数，也不代表实际并发度。跨环境对比前，务必统一该值，否则 ns/op 差异可能来自调度干扰而非代码。
B/op 和 allocs/op 比 ns/op 更危险：一个函数 ns/op 降了 30%，但 allocs/op 从 0 升到 5，上线后 GC 可能突然毛刺。必须加 -benchmem 才显示这两项。
MB/s 不是自动出来的。对 IO 或编解码类操作，需手动调用 b.SetBytes(int64(len(input))) 告诉框架“每次处理多少字节”，否则输出里不会出现 MB/s 字段——传错单位（比如该传 1024*1024 却传 1024），MB/s 就差 1000 倍。
