性能测试不准的根源在于setup混入benchmark调用路径，必须将数据构造等非算法逻辑移出测量链，正确使用benchmark fixture并配置CI开关确保结果可信。
直接传函数加预置参数就能测，但测出来不准——90%的性能报告抖动、标准差爆表、中位数跳变，根源都在 setup 混进了 benchmark 调用路径里。
为什么 benchmark(sorted, data) 会测出假波动？
因为 data 如果是在测试函数体内生成（比如 data = list(range(10000))），每次 benchmark 迭代都会重新构造列表，这部分开销被算进算法耗时。真实耗时可能只有 50μs，但数据生成占了 800μs，最终报告的 stddev 高得离谱，min/max 差 3 倍。
- 必须把数据构造、对象初始化等非算法逻辑移出
benchmark()调用链 - 推荐写法：
data = make_input(); result = benchmark(sorted, data) - 禁止写法：
result = benchmark(sorted, list(range(10000)))或result = benchmark(lambda: sorted(list(range(10000)))) - 若算法依赖状态（如缓存字典），需在
setup阶段预热并复位，确保每次迭代起点一致
怎么安全调用 benchmark fixture？
benchmark 是 pytest fixture，不是装饰器，调用方式直接影响结果可信度。三种常见用法里，只有两种适合日常：
-
最简干净型：传函数 + 显式参数 →
benchmark(sorted, data)，要求data已就绪 -
灵活隔离型：用
lambda包裹待测主体 →benchmark(lambda: my_algo(data))，但data = make_big_list()必须写在 lambda 外 -
慎用 pedantic 型：仅对亚微秒级函数（如单个
int.__add__）→benchmark.pedantic(my_func, rounds=10, iterations=1000)，它绕过自动校准，容易因机器差异失真
多算法横向对比必须设 group 和 name
不设 benchmark.group，test_quicksort_1000 和 test_mergesort_1000 在报告里就是两条孤立记录，看不出谁快；不设 benchmark.name，同组内不同规模测试会堆成一团，增长趋势全乱。
Python 编程规范
下载
Python 编程规范与最佳实践。强制 PEP 8 代码风格、语法校验、单元测试执行，适用于代码编写、审查和重构。触发词：Python、代码规范、py_compile、单元测试。
- 所有同类算法测试统一设
benchmark.group = "sorting" - 用
benchmark.name标明关键差异："quicksort / 1000 items"、"timsort / 1000 items" - 运行时加
--benchmark-group-by=group --benchmark-sort=name，报告才按组聚合、同组内并排可比 - 漏掉任一字段，CI 里根本没法做自动化性能回归判断
CI 环境下跑不稳？三个硬性开关要打开
本地跑得好好的，推到 CI 就飘 ±40%，通常不是代码问题，而是环境干扰没屏蔽：
- 加
--benchmark-min-time=0.01：强制单轮至少跑 10ms，避免 CI 机器慢导致迭代次数太少、统计失效 - 加
--benchmark-disable-gc：禁用垃圾回收，否则 GC 触发时机不可控，max和stddev直接失真 - 加
--benchmark-warmup：让 JIT 或 C 扩展预热，尤其对orjson、numpy类库很关键 - 别信默认配置——CI 容器常限 CPU/内存，
benchmark不会自动适配，必须显式压住干扰源
真正难的不是写那行 benchmark(func, arg)，而是把所有非核心逻辑从测量路径里物理剥离。一个变量声明的位置、一行 import 的时机、甚至 assert 放在哪，都可能污染结果。测不准，比不测更危险。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
