go test -bench=. 是唯一能同时捕获执行速度、内存分配与 gc 压力的原生基准测试手段，需配合 -benchmem、b.resettimer()、b.reportallocs() 和 b.setbytes() 使用，并通过 -gcflags="-m -l" 验证内联。
直接用 go test -bench=. 测，别绕路
Go 模块没有“模块级运行开销”这个东西——internal 目录、跨 go mod、不同包路径，都不影响函数调用性能。真正要测的，是具体函数在真实编译和运行环境下的表现。go test -bench=. 是唯一能同时捕获执行速度、内存分配、GC 压力的原生手段。它不依赖外部压测工具，也不受磁盘缓存或网络延迟干扰，结果稳定可复现。
Benchmark 函数里必须调用 b.ResetTimer()
常见错误是把初始化逻辑（比如 make([]byte, 1024)、读配置、构建 mock 对象）写在循环里，导致 ns/op 包含了无关开销。这会让你误判优化效果。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 预处理代码（如变量声明、资源准备）放在
for循环之前 - 紧接在循环前加
b.ResetTimer() - 被测逻辑只保留你要评估的那几行，比如
json.Unmarshal(data, &v)或strings.Builder.WriteString(s) - 如果函数返回值没被使用，编译器可能直接跳过计算；用全局变量兜住结果：
var blackhole interface{}; blackhole = yourFunc()
必须加 -benchmem，否则看不见真瓶颈
ns/op 只告诉你快不快，B/op 和 allocs/op 才暴露内存行为。一个函数耗时降了 30%，但 allocs/op 从 0 升到 5，上线后 GC 频次可能翻倍，接口毛刺就来了。
- 加
b.ReportAllocs()开启统计 - 对 IO 或编解码类操作，再加
b.SetBytes(int64(len(data)))，输出才有MB/s -
B/op是平均每次操作分配的字节数，allocs/op是分配次数；后者更敏感——1 次分配 1KB 和 100 次分配 10B，GC 压力差异巨大 - 不加
-benchmem，输出里根本不会显示内存指标
验证是否真被内联，而不是靠猜
跨包调用慢？大概率不是因为“模块隔离”，而是函数没被内联，或者用了接口/指针接收者/逃逸对象。别凭感觉判断，用工具看：
- 加
go build -gcflags="-m -l"编译，搜索目标函数名：看到inlining call to表示成功，cannot inline: unhandled node说明被拒（常因闭包、defer或体过大） - 对比汇编：
go tool compile -S pkg/foo.go | grep "MyFunc"，确认调用是否为直接CALL，而非经寄存器间接跳转 - 高频路径上避免
interface{}调用和(*T).Method()；优先传函数值或具体类型
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
