该用 time.perf_counter() 时：只想测单次代码实际耗时，如调试算法分支、验证 api 延迟或粗略比对逻辑耗时；它返回纳秒级单调递增时间，不受系统时钟影响，是官方推荐的经过时间测量首选。
直接用 time.perf_counter() 测单次代码块最准，timeit 适合测小函数的重复执行均值——别拿 timeit 去包带 I/O 或状态变更的代码，结果会失真。
什么时候该用 time.perf_counter()
你只想知道「这段逻辑实际跑了一次花了多久」，比如调试一个算法分支、验证某次 API 调用延迟、或者快速比对两段处理逻辑的粗略耗时。
它返回的是单调递增的高精度计时器值（纳秒级），不受系统时钟调整影响，是 Python 官方推荐的「测量经过时间」的首选。
- 用法简单：
start = time.perf_counter(); your_code_here; end = time.perf_counter(); print(end - start) - 注意：必须成对调用，且中间不能有不可控延迟（比如
input()、time.sleep()、磁盘读写） - 如果代码执行太快（timeit 多次运行取平均
为什么 timeit 不适合测含副作用的代码
timeit 默认会把语句重复执行多次（默认 100 万次），并自动禁用 GC、隔离命名空间、绕过全局变量查找开销——这些优化让它精准，但也让它「不真实」。
常见翻车场景：
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 测
list.append(x)：每次循环都操作同一个 list，第二次起就不是「首次追加」了，数据状态污染导致结果偏低 - 测
json.loads(s)但s是全局变量：timeit默认不导入外部作用域，会报NameError: name 's' is not defined - 测文件读取：
timeit可能缓存文件句柄或 OS page cache，后续轮次远快于首次，数值失去参考意义
正确做法：把待测逻辑封装成函数，并通过 setup 参数显式传入依赖项，例如：
import timeit
timeit.timeit('f(data)', setup='from __main__ import my_func as f; data = [1,2,3]*1000', number=10000)
timeit 的三种调用姿势和适用场景
命令行最快上手，模块内调用更灵活，装饰器最省事——但三者底层都是同一套逻辑。
- 命令行：
python -m timeit -s "import math" "math.sqrt(123)"，适合临时比对单行表达式 - 函数调用：
timeit.timeit(lambda: x**0.5, number=1000000)，适合闭包捕获变量，避免字符串拼接风险 - 装饰器（需自写）：对函数做透明计时，但要注意它测的是「函数调用开销 + 执行体」，不等于纯执行体耗时
参数 number 不建议盲目设大。Python 3.12+ 中 timeit 会自动校准最佳迭代次数，设 number=0 即启用自动模式。
容易被忽略的精度陷阱
time.perf_counter() 返回 float，但 Python float 只有 53 位有效位——当时间差小于 ~100 纳秒时，减法结果可能为 0；而 timeit 默认返回秒单位，对微秒级操作要手动乘以 1e6 转换，否则打印出来全是 0.0。
更隐蔽的问题是 JIT 或 CPU 频率调节：笔记本在电池模式下 CPU 降频，time.perf_counter() 测出的时间会变长，但不代表代码变慢了——这是硬件层面对「经过时间」的诚实反映，而非测量错误。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
