为何Python中`in list`检查比逐个元素相等判断更快？

核心原因：Python底层实现的效率差异 #

Python的in操作符针对序列（列表、元组等）的检查是C语言底层实现的，而纯Python代码里的索引访问（expression[0]、expression[2]）和相等比较（==）是由Python解释器逐行执行字节码完成的。C代码的执行速度比Python字节码快几个数量级——哪怕in操作多做了一次遍历，整体开销仍然低于两次Python层面的操作。

具体操作步骤的开销对比 #

假设expression是长度为3的序列（比如[a, op, b]）：

• 版本1（先in再判断位置）：
  1. 执行cur_monkey in expression：C底层循环遍历序列的3个元素，找到匹配就立即返回True，全程在C层面完成，几乎没有Python解释器的额外开销。
  2. 确认存在后，只需要一次比较cur_monkey == expression[0]——如果成立就是第一个元素，否则必然是第三个（因为in已经确认存在，而表达式的操作数只有首尾两个）。
• 版本2（直接两次索引比较）：
  1. 第一次执行cur_monkey == expression[0]：需要通过Python字节码完成索引访问（计算偏移、取出元素），再执行相等比较，全程由Python解释器处理。
  2. 如果第一次不成立，再重复一轮上述操作检查expression[2]，等于多了一轮Python字节码的执行开销。

短序列的in操作优势更明显 #

对于长度极小的序列（比如这里的3个元素），in操作的遍历成本可以忽略不计，而C层面的遍历速度完全碾压Python层面的两次独立操作。哪怕cur_monkey是序列的第三个元素，in操作遍历3个元素的C代码耗时，也比Python解释器执行两次索引+比较的耗时少。

内容的提问来源于stack exchange，提问作者Some nerd who does not have a