Benchmark函数必须以Benchmark开头并接收*testing.B参数，否则go test -bench会忽略；命名建议为BenchmarkQuicksort以便筛选，且必须用b.N控制循环次数。
为什么 Benchmark 函数必须以 Benchmark 开头且接收 *testing.B
Go 的测试框架只识别符合命名规范和签名的函数作为基准测试入口。如果写成 TestSort 或参数是 *testing.T，go test -bench 会直接忽略——它根本不会执行你写的逻辑。
实操要点：
-
Benchmark后建议接具体算法名，比如BenchmarkQuickSort，方便-bench=Quick精准筛选 - 必须调用
b.N控制循环次数，不能自己写for i := 0; i —— 否则b.ResetTimer()和统计逻辑失效 - 耗时操作（如数据生成）应放在
b.ResetTimer()之前，避免计入基准时间
如何避免切片复用导致的排序结果污染
多次调用 sort.ints() 时若反复使用同一底层数组，前一次排序会改写原始数据，后续 benchmark 实际测的是“已排好序的数组”的再排序，结果严重失真。
正确做法：
立即学习“go语言免费学习笔记（深入）”；
- 每次
b.N迭代中都用append([]int{}, data...)或make+copy创建新切片 - 不要在
Benchmark函数外预分配全局切片并反复传入 - 可借助
b.Run拆分子测试，每个子测试独立准备数据，例如：b.Run("1000", func(b *testing.B) { ... })
go test -bench 常见误判场景和应对
默认 go test -bench=. 只运行一次 warm-up，若算法对输入敏感（如快排遇到已排序数组退化为 O(n²)），单次随机 seed 可能掩盖真实性能波动。
关键控制点：
- 加
-benchmem查看内存分配，sort.Slice比sort.Ints多一次函数调用开销，但可能少一次类型断言，需实测权衡 - 用
-count=5多次运行取中位数，避开瞬时系统干扰 - 避免在笔记本上边充电边跑 —— CPU 频率降频会让
ns/op波动超 20%，建议插电或用cpupower frequency-set -g performance（linux） - 若对比自定义排序（如按结构体字段），确保
less函数无闭包捕获、无接口动态调用，否则会引入非排序本身的开销
为什么 sort.Stable 比 sort.Sort 慢，但有时不得不选它
sort.Stable 强制使用归并排序（稳定），而 sort.Sort 默认用快排+堆排+插入排序混合策略（不稳定）。前者最坏 O(n log n)，后者快排分支最坏 O(n²)，但平均快 10%–30%。
是否启用稳定排序，取决于业务语义：
- 若排序键相同的数据有先后依赖（如先按分数排，再按提交时间排），必须用
sort.Stable，否则二次排序会打乱首次顺序 - 若只是求最终有序结果，且键唯一或顺序无关，优先用
sort.Sort或专用函数（sort.Ints） - 注意：自定义
sort.Interface实现时，len/Swap被频繁调用，避免在其中做任何非必要计算或内存分配
实际写 benchmark 时，最容易被忽略的是数据初始化方式和稳定性要求之间的隐含冲突——不是所有“看起来一样”的排序调用，背后语义负担都相同。