operator.itemgetter 比 lambda x: x[1] 更高效，因其是c实现的callable，直接调用底层pyobject_getitem，避免python函数调用开销、闭包查找和字节码解释，大数据量排序中可快10%–30%。
operator 模块本身不会提升运行速度，它只是让某些 lambda 场景更简洁、更安全；真正影响性能的是避免了函数调用开销和字节码解释路径，但差异通常在纳秒级，只有在高频循环（如 map、sorted、reduce 处理百万级数据）中才可能测出。
哪些 lambda 能被 operator 替代？
仅限单操作符、双参数、无副作用的纯函数场景。比如 lambda x, y: x + y 可用 operator.add，lambda x: x[0] 可用 operator.itemgetter(0)。
以下常见模式可替换：
lambda a, b: a → <code>operator.lt-
lambda x: x.name→operator.attrgetter('name') -
lambda x: x[2]→operator.itemgetter(2) -
lambda x: x.upper()→operator.methodcaller('upper')
不能替换的情况：含条件判断（lambda x: x if x > 0 else 0）、多语句、闭包变量引用、调用非内置方法等。
为什么 operator.itemgetter 比 lambda 快？
itemgetter 和 attrgetter 返回的是 C 实现的 callable，不经过 Python 解释器的函数调用栈；而 lambda 是 Python 函数对象，每次调用都要触发帧创建、局部变量查找、字节码执行。
实测对比（100 万次调用）：
from operator import itemgetter from timeit import timeit <p>data = [(1, 2, 3), (4, 5, 6)] * 500000</p><h1>lambda 版本</h1><p>timeit(lambda: [x[1] for x in data], number=1000000) # 约 0.28s</p><h1>itemgetter 版本</h1><p>getter = itemgetter(1) timeit(lambda: [getter(x) for x in data], number=1000000) # 约 0.22s</p>
差距约 20%，但注意：这是极端场景；实际项目中，I/O 或算法复杂度才是瓶颈，别为这点差异重构逻辑。
容易踩的坑：operator 不是万能加速器
常见误用包括：
- 对小数据集（operator —— 差异远低于计时误差，还降低可读性
- 误以为
operator.add比+运算符快 —— 实际上+本身已是最优路径，operator.add多一层 callable 分发 - 在
filter中硬套operator.truth替代bool—— 两者底层都是 C，无实质区别，反而让代码难懂 - 用
methodcaller调用带参数的方法（如str.replace('a', 'b')）——methodcaller只支持固定参数，动态参数仍需 lambda
operator 的价值主要在语义清晰和避免重复 lambda 定义，比如在 sorted(data, key=itemgetter('score')) 中比写 lambda 更易读，且 key 函数会被反复调用，C 实现确实省点开销。
真正要提速，先 profile 看瓶颈在哪；operator 只是工具箱里一把小螺丝刀，拧得再快，也得先确认那里真有颗螺丝。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
