该用 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、隔离命名空间、绕过全局变量查找开销——这些优化让它精准，但也让它「不真实」。
常见翻车场景：
- 测
list.append(x)：每次循环都操作同一个 list，第二次起就不是「首次追加」了，数据状态污染导致结果偏低 - 测
json.loads(s)但s是全局变量：timeit默认不导入外部作用域，会报NameError: name 's' is not defined - 测文件读取：
timeit可能缓存文件句柄或 OS page cache，后续轮次远快于首次，数值失去参考意义
正确做法：把待测逻辑封装成函数，并通过 setup 参数显式传入依赖项，例如：
Python 3.14.3
微软官方的 Python 扩展，是 VS Code 安装量最高的扩展（209M+）。集成 IntelliSense（通过 Pylance）、调试（通过 Python Debugger）、代码检查、格式化、重构和单元测试等功能。支持 Jupyter Notebook、虚拟环境管理和多 Python 版本切换。
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() 测出的时间会变长，但不代表代码变慢了——这是硬件层面对「经过时间」的诚实反映，而非测量错误。
