应使用timeit模块而非time.time()来准确比较Python代码性能，因其自动处理循环、垃圾回收干扰、多次运行取平均，结果更可靠。
想准确比较两段Python代码谁更快？别靠“感觉”或简单用time.time()——timeit才是专为这个设计的标准工具。它自动处理循环、垃圾回收干扰、多次运行取平均，结果更可靠。
为什么不用time.time()直接测？
手动用time.time()前后打点看似简单，但容易踩坑：单次执行受系统调度、CPU瞬时负载、GC暂停等影响太大；没排除导入开销；也没重复验证稳定性。比如测一个列表推导式和map的性能，一次跑出“map快”，再跑可能就反过来了。
而timeit默认执行100万次（可调），自动剔除异常值，还能禁用GC、预热解释器，让对比真正反映代码逻辑本身的开销。
三种常用调用方式，按场景选
命令行最快上手：
python -m timeit -s "data = list(range(1000))" "[x*2 for x in data]"
python -m timeit -s "data = list(range(1000))" "list(map(lambda x: x*2, data))"-s是setup语句（只执行一次，不计入耗时），后面是待测表达式。适合快速比对单行代码。
在脚本里精确控制：
用timeit.Timer对象，支持多行语句、自定义number、repeat次数：
- 用
stmt传多行代码字符串（注意缩进和换行） - 用
setup准备测试环境（如导入模块、构造数据） -
timer.timeit(number=100000)执行指定次数 -
timer.repeat(repeat=5, number=100000)重复5轮，每轮10万次，返回5个耗时列表，取最小值更稳健
装饰器写法（适合函数级对比）：
自己封装一个@timeit装饰器，把函数调用包装进timeit，避免每次手动写setup。注意别在装饰器里测函数定义本身，而是测调用行为。
真实对比案例：生成10万数字的平方
对比三种写法：
-
[x**2 for x in range(100000)]（列表推导） list(map(lambda x: x**2, range(100000)))-
list(x**2 for x in range(100000))（生成器转列表）
用timeit.repeat(repeat=3, number=1000)运行，通常会发现：列表推导最快，生成器转列表次之，map+lambda最慢——因为lambda调用有额外开销，且map返回迭代器还需list()强制展开。
关键提醒：数据规模会影响结果。小数据量下差异不明显；大数据量时内存分配模式、缓存局部性也会介入。所以务必用贴近你实际使用场景的数据规模来测。
避开常见误区
- 别在
stmt里写变量赋值（如"a = [1,2,3]; a.sort()"），这会让赋值也计入耗时。应把初始化放setup - 避免测试含I/O、网络、随机数的代码——这些外部因素会让结果失真
- 不要只看“平均值”，
repeat后取min()更合理，因为最小值代表最佳稳定性能（排除系统抖动干扰） - 确保对比的代码功能完全等价。比如测排序，要确认输入数据相同、是否原地修改、是否影响后续逻辑
timeit不是万能的，它擅长微观操作对比；宏观服务响应、内存占用、多线程竞争等问题得用cProfile、memory_profiler或压测工具。但只要你想知道“这一行到底快多少”，timeit就是最轻量、最可信的选择。
