跨架构基准测试不能直接比较ns/op绝对值，因时钟源、内存屏障、内联策略等差异导致结果不可比；需同机对比相对变化、锁频、统一参数、避免优化干扰，并识别硬件级差异。
跨架构比 ns/op 绝对值？别信，会误判
ARM64（如 M 系列、Graviton）和 AMD64（x86_64）的基准测试结果不能直接比数字。比如 BenchmarkJSONUnmarshal 在 M2 上跑出 85 ns/op，在 i9 上是 72 ns/op，不代表后者快 15%——因为两者的时钟源、内存屏障开销、内联策略、甚至 runtime.mcall 的采样深度都不同。
- ARM64 默认启用帧指针，
pprof火焰图调用栈更深，不是性能差，是编译器没内联更多函数；加-gcflags="-l"关闭内联再对比才公平 - Go 1.22+ 在 ARM64 上已忽略
GOAMD64=v1，别指望靠它“开启 AVX 加速”——那根本不存在 - 真正可比的是同一台机器上两个实现的相对变化：比如你把
strings.Builder换成bytes.Buffer，在 M2 上快了 12%，这个结论可信；但拿 M2 的 85 ns/op 和服务器的 72 ns/op 去算“跨平台损耗”，纯属误导
go test -bench 怎么排除 CPU 频率干扰？
Linux/macOS/Windows 的节能策略会让 CPU 动态降频，一次 go test -bench=. 可能因某次调度被压到 1.2 GHz，下一次又拉满，ns/op 差 20% 都不奇怪。
- Linux：运行
sudo cpupower frequency-set -g performance锁定最高主频；跑之前先go clean -cache -testcache清旧产物 - macOS（M 系列）：没法锁频，但要插电、关掉“自动切换图形卡”和“优化电池充电”，否则 Energy Saver 会悄悄降频
- Windows：电源计划切“高性能”，BIOS 里关掉 Intel SpeedStep 或 AMD Cool’n’Quiet
- 所有平台：必须加
-count=5，让go test取中位数，单次抖动直接过滤掉
math/big 和 unsafe.Slice 在 ARM64 上为啥慢？
这不是 Go 编译器 bug，而是硬件指令集差异导致的实测性能落差，尤其在密码、序列化等关键路径上容易踩坑。
-
math/big.Mul在 ARM64 上比 AMD64 慢 20–30%，因为缺少原生高位乘法指令（umulh），得靠软件拆分模拟；RSA 2048 运算时特别明显 -
unsafe.Slice(ptr, n)在 ARM64 后端的边界检查消除还没完全对齐，循环里高频调用会多出 1–2 条cmp/b.hs分支，而 AMD64 已基本消除 - CGO 调用在 ARM64 更易 panic：C 函数声明用
int，Go 侧传C.int64(x)，AMD64 可能侥幸过，ARM64 直接从错误寄存器读值——必须严格用int32_t/int64_t声明 C 函数，并加CGO_CFLAGS="-Wall -Werror"
用 benchstat 对比前，必须确认三件事
很多人导出 old.txt 和 new.txt 后直接 benchstat old.txt new.txt，结果发现 p 值不显著或 delta 波动大，其实问题常出在数据采集阶段。
立即学习“go语言免费学习笔记（深入）”；
- 两个文件必须用完全相同的
-benchmem -count=5 -benchtime=5s参数生成，缺一不可；-benchtime=5s是为了压住 GC 周期波动 - 确保被测逻辑的结果被真正使用，比如
_ = json.Unmarshal(data, &u)中的_ =不能少，否则 Go 1.21+ 会整段优化掉 - 初始化数据（如
make(map[int]bool, 1000)）必须放在b.ResetTimer()之前，且不能在循环里重复构造；否则allocs/op会虚高，掩盖真实 CPU 开销
跨平台基准测试最难的不是跑命令，而是识别哪些差异来自代码，哪些来自芯片——比如 atomic.LoadUint64 在 ARM64 上多出的 10–15% 开销，是内存模型弱序导致的 barrier 更保守，不是你写错了。这类底层差异不会报错，只会悄悄拖慢服务吞吐，得靠 go tool trace 和反复验证才能揪出来。
