time.time()适用于记录真实世界时间戳，如日志、文件名、超时计算；time.perf_counter()是测量耗时的默认选择，单调高精度；time.process_time()仅统计cpu时间，不适用于响应时间；微基准测试应使用timeit。
time.time() 适合记录真实世界时间戳
当你需要把程序运行时刻和日历时间对齐（比如打日志、生成文件名、计算超时截止点），time.time() 是唯一合理选择。它返回的是 Unix 时间戳，和系统时钟同步，能直接转成 datetime 或用于 HTTP Date 头等场景。
常见错误现象：time.time() 在 NTP 同步或手动调时后可能跳变甚至倒退——这会导致你算出负耗时，或误判“执行了 5 秒”其实只过了 2 秒。
- 必须用在需要可读时间语义的地方：如
logging.info(f"started at {time.time()}") - 不能用于测量耗时，尤其在服务器长期运行、有自动时间校准的环境中
- 精度受限于系统时钟分辨率（常为毫秒级），短于 1ms 的操作基本测不准
time.perf_counter() 是测耗时的默认选项
所有代码段执行时间测量，都该无条件优先用 time.perf_counter()。它不关心“现在几点”，只专注“从 A 到 B 真实过去了多久”，单调、高精度、跨平台一致。
使用场景：函数性能对比、关键路径监控、CI 中的耗时断言、调试慢请求。
- 两次调用必须成对出现，且不能混用其他计时器（比如拿
perf_counter()开始，用process_time()结束） - 它包含 sleep 和 I/O 等等待时间，符合“用户感知耗时”的直觉
- 若需纳秒级整数结果，可用
time.perf_counter_ns()，避免浮点误差累积
别用 time.process_time() 测“响应时间”
time.process_time() 只统计当前进程的 CPU 占用时间，跳过所有阻塞（sleep、input、网络等待、磁盘读写）。它适合分析纯计算瓶颈，但完全不适合衡量端到端延迟。
容易踩的坑：你在本地测试一个带 requests.get() 的函数，用 process_time() 发现只花了 0.001s —— 这不是快，是它根本没把 2 秒网络延迟算进去。
- 适用场景：CPU 密集型算法优化前后对比、profiler 中的 CPU 时间归因
- 不适用场景：Web 请求耗时、命令行工具总运行时间、用户等待体验评估
- 注意：多线程下
process_time()返回的是整个进程累计值，不是单线程独占时间
微基准测试交给 timeit，别手写 perf_counter 套壳
如果你要比较 list.append() 和 deque.append() 的单次开销，或者验证某个正则是否更优，time.perf_counter() 手动套两层是错的——它无法屏蔽 GC、JIT 预热、缓存效应等干扰。
timeit.timeit() 内部做了三件事：禁用 GC、重复执行多次、剥离 setup 开销。你写的那句 "[x*2 for x in range(100)]"，它会真正跑一百万次再除以次数。
- 命令行快速试：
python -m timeit -s "import re" "re.search(r'\d+', 'abc123')" - Jupyter 中直接用
%timeit [x*2 for x in range(100)] - 代码中调用：
timeit.timeit(lambda: my_func(), number=10000)，比手写循环 + perf_counter 更可信
perf_counter()，单次测量仍可能因 CPU 频率调节、后台进程抢占而偏差 30%。至少跑 3 次取最小值，或用 timeit 跑够 1000+ 次——否则你优化的可能只是噪声。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
