应使用 timeit 而非 time.time() 测量 python 代码性能，因其自动多次执行、禁用 gc、返回最小值以逼近真实下界，并需注意作用域、状态一致性、重复测试与输入预热。
用 timeit 测单行代码，别用 time.time()
直接拿 time.time() 做差值，误差常达毫秒级，尤其在函数执行快于 1ms 时，结果基本不可信。这是因为系统调度、CPU 频率波动、其他进程干扰都会污染测量。
正确做法是用标准库的 timeit——它自动重复多次、禁用 GC、绕过解释器启动开销，并返回最稳定的若干次中的最小值（更接近真实下界）。
-
timeit.timeit('x ** 2', number=1000000)：适合单表达式，字符串形式传入 -
timeit.timeit(lambda: x**2, number=1000000)：适合带变量或复杂逻辑，避免字符串拼接风险 - 别在
timeit中测 IO、网络、随机数生成——这些本身抖动大，测出来不是 CPU 性能，是系统行为
测函数性能必须控制变量作用域
timeit 默认在独立命名空间里执行，你定义的函数或变量如果没显式传进去，会报 NameError；而硬塞进字符串又容易引发作用域混乱或变量捕获错误。
常见翻车点：写 timeit.timeit('my_func(42)', number=10000) 却忘了 my_func 不在 timeit 的作用域里。
立即学习“Python免费学习笔记（深入）”；
- 用
setup参数导入：timeit.timeit('my_func(42)', setup='from __main__ import my_func', number=10000) - 更稳的方式是用
globals()：timeit.timeit(lambda: my_func(42), globals=globals(), number=10000) - 如果函数依赖外部状态（如全局 dict），务必确认每次运行前状态一致，否则基准失真
别信单次 timeit 结果，看分布和最小值
Python 的内存分配、JIT（如 PyPy）、CPU 睿频、后台 GC 都会导致单次测量偏差。一次跑出 “A 比 B 快 15%” 很可能只是噪声。
timeit.repeat() 才是生产级姿势：它执行多轮完整测试（每轮内重复 number 次），返回每轮耗时列表，你可以观察波动范围。
-
timeit.repeat('a + b', setup='a="x"*100; b="y"*100', number=100000, repeat=5)返回类似[0.012, 0.014, 0.011, 0.015, 0.012] - 取最小值（
min()）比均值更可靠——它避开 GC 尖峰、缓存未命中等偶然拖慢 - 若五次结果方差 > 10%，说明环境不干净（比如开了浏览器+IDE+Docker），换台机器再试
对比不同实现时，确保输入完全一致且预热充分
有人测 list.append() vs deque.append()，但一边用空 list，另一边用已填充 1000 项的 deque——这根本不是比 API，是在比内存布局。
还有人忽略“首次调用开销”：CPython 的某些内置函数（如 json.loads）第一次运行会触发模块加载和字节码编译，后续才稳定。
- 所有被测函数，输入数据对象必须每次新建或重置，不能复用同一对象引用
- 对可能有冷启动成本的函数，先单独调用一次“预热”，再开始计时（但预热本身不计入
number） - 如果测的是算法复杂度，至少换 3 个数量级输入（如 n=100/1000/10000）看趋势，别只盯一个数字
真正难的从来不是跑出一个数字，而是让这个数字不被 Python 自身的呼吸节奏带偏。变量作用域、内存状态、CPU 调度——它们不声不响，但每一步都在悄悄改写你的结果。
