该选 time.perf_counter()：它单调递增、高精度、不受系统时钟调整影响；time.time() 可能因 ntp 同步导致负耗时，仅适合记录绝对时间点。
time.time() 和 time.perf_counter() 该选哪个
计时不准，八成是用了 time.time()。它受系统时钟调整影响——比如 NTP 同步后倒退几毫秒，你的耗时可能直接变负数。
time.perf_counter() 才是专为性能测量设计的：单调递增、高精度、不受系统时间干扰，Python 3.3+ 默认推荐。
- 测函数执行耗时 → 无条件用
perf_counter() - 记录“什么时间点开始”（如日志打点）→ 可用
time.time()或time.strftime() - 在容器或虚拟机里跑，
perf_counter()依然稳定；time.time()可能因宿主机时钟漂移出问题
@timer 装饰器写法与闭包陷阱
自己写装饰器时，最容易漏掉 functools.wraps(func)，导致被装饰函数的 __name__、__doc__ 全变成装饰器里的名字，调试和 IDE 补全直接失效。
另一个坑是把计时逻辑写在装饰器外层——那样只运行一次，不是每次调用都计时。
- 计时代码必须放在返回的内层函数里（即实际执行逻辑的位置）
- 务必用
@functools.wraps(func)包装内层函数 - 别在装饰器参数里默认传
print——想输出就显式传logger=print，否则单元测试没法捕获或屏蔽
import functools
import time
<p>def timer(logger=None):
def decorator(func):
@functools.wraps(func)
def wrapper(*args, *<em>kwargs):
start = time.perf_counter()
result = func(</em>args, **kwargs)
elapsed = time.perf_counter() - start
if logger:
logger(f"{func.<strong>name</strong>} took {elapsed:.4f}s")
return result
return wrapper
return decorator</p>
嵌套调用时的累计耗时怎么拆解
一个函数调了三个子函数，你只看到总耗时 200ms，但不知道哪块拖慢了——这时候不能靠单个 @timer，得加上下文标识或层级标记。
简单有效的方式是传入 level 参数，或者用 threading.local() 记录调用栈深度，再配合缩进输出。不过更轻量的做法是让装饰器支持可选前缀：
- 给
timer()加个prefix参数，比如@timer(prefix="[DB]") - 避免用全局变量存“当前路径”，多线程下会串
- 如果真要完整调用树，别硬刚装饰器，改用
contextvars（Python 3.7+）或直接上logging的extra字段传上下文
异步函数（async def）不能直接套 time.perf_counter()
对 async def 函数加普通 @timer，你会发现计时结果总是 0.0000s——因为装饰器没 await，只计了协程对象创建时间，不是实际运行时间。
必须写异步版本的装饰器，且内部要用 await 调用原函数，并用 asyncio.get_event_loop().time() 或保持用 time.perf_counter()（它本身是线程安全的，也适用于 async 场景）。
- 别用
time.time()在 async 里计时，精度低还可能跳变 - 异步装饰器里不能用
time.sleep()，但计时本身不阻塞，放心用perf_counter() - 若函数既可能是 sync 也可能是 async，装饰器得做类型判断，但通常不值得——明确区分
@timer和@async_timer更清晰
事情说清了就结束。真正难的不是写对那几行计时代码，而是当耗时突然翻倍时，你能一眼看出是 I/O 阻塞、GIL 争抢，还是装饰器本身在反复创建 logger 实例。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
