Python运算符优先级怎么算？附优先级表与避坑指南

一、运算符优先级是怎么计算的？核心推导法则

在 Python 中，当一个表达式中包含多个不同种类的运算符时，解释器不会单纯按代码书写的物理先后顺序求值，而是按照语法定义的结合树（Abstract Syntax Tree, AST）逐步规约。掌握优先级的核心推导，主要依赖以下三个不可分割的维度：

• 绑定优先级别（Precedence）：优先级高的运算符就像磁石一样，会优先与其相邻的操作数结合形成子表达式。例如在 2 + 3 * 4 中，* 的优先级高于 +，因此 3 和 4 优先绑定，先计算 3 * 4 得 12，再计算 2 + 12。
• 结合方向（Associativity）：当相邻的运算符具有相同优先级时，结合性决定了求值次序。Python 中绝大多数二元运算符都是左结合（Left-to-Right）的（如加减乘除、位运算）；但唯一的例外是幂运算符 ** 是右结合（Right-to-Left）。
• 短路与惰性求值（Short-Circuiting）：布尔逻辑运算符 and 与 or 并不总是计算两侧的表达式。一旦左侧子表达式的值已足以确定整体真假，右侧表达式将被完全跳过。

为了清晰呈现这一连续推导过程，我们以一个涵盖算术、幂运算、比较与逻辑运算符的综合表达式为例：
result = 2 + 3 * 4 ** 2 > 40 and not False

图 1：复杂表达式各运算符层层绑定的分步求值流程

二、Python 运算符优先级权威速查表（从高到低）

下表汇总了 Python 官方语言规范中定义的完整运算符优先级顺序。列表顶端的运算符拥有最高优先级，将最优先与操作数进行绑定；列表底端的运算符优先级最低。

图 2：Python 运算符核心六大梯队全景分层与特性概览

三、常见踩坑场景与避坑指南

在实际工程开发中，运算符优先级引发的 Bug 往往不会直接抛出 SyntaxError，而是默默以不符合预期的逻辑运行，产生极难排查的业务逻辑隐患。以下总结了 4 个最为经典的翻车陷阱及对应的防御编码方案。

1. 陷阱一：一元负号与幂运算的优先级次序（-2 ** 2）

在数学书写中，很多人容易将 -2² 理解为 (-2) × (-2) = 4。但在 Python 中：

val = -2 ** 2
print(val)  # 输出结果是 -4，而不是 4！

原因剖析：查阅上表可知，幂运算符 ** 位于第 3 梯队，而一元符号 - 位于第 4 梯队。因此解释器会先计算 2 ** 2 得 4，再应用一元减号得到 -4，即等价于 -(2 ** 2)。
避坑方案：对负数底数进行乘方运算时，必须显式包裹圆括号：(-2) ** 2。

2. 陷阱二：按位与（&）与比较运算符（==）的优先级颠倒

在处理状态掩码（Bitmask）或权限系统时，常需要判断某个位是否被置位。很多开发者会顺手写出如下代码：

PERMISSION_READ = 0x01
user_flags = 0x05

# 危险陷阱：想要判断 user_flags 中是否包含读权限
if user_flags & PERMISSION_READ == PERMISSION_READ:
    print("拥有读取权限")
else:
    print("无权限")  # 实际上会走入这里！

原因剖析：在 C 语言及 Python 中，比较运算符 ==（第 11 级）的优先级居然高于按位与 &（第 8 级）！上述代码实际上被解析为：
user_flags & (PERMISSION_READ == PERMISSION_READ)
由于 PERMISSION_READ == PERMISSION_READ 结果为 True（在数值上下文中等于 1），整个表达式变成了 user_flags & 1。如果判断的是非 1 的掩码位（例如 user_flags & 0x02 == 0x02），右侧直接变为 0x02 == 0x02 -> 1，计算 user_flags & 1，逻辑彻底崩塌！
避坑方案：进行位运算判断时，务必对位操作部分单独加括号：if (user_flags & PERMISSION_READ) == PERMISSION_READ:。

3. 陷阱三：链式比较（Chaining Comparisons）带来的反直觉真值

观察下面这行一度让许多资深程序员困惑的代码：

result = False == False in [False]
print(result)  # 输出结果居然是 True！

直觉误区：很多开发者猜测这会先执行 False == False 得到 True，然后判断 True in [False]，最终输出 False。
原因剖析：在 Python 语法中，== 和 in 都是同属第 11 梯队的比较运算符。Python 规定多个连续的比较运算符会被重写为链式比较（Chained Comparison）：
a op1 b op2 c 会被等价转换为 (a op1 b) and (b op2 c)。
因此原表达式实际被展开为：
(False == False) and (False in [False])
其中左侧 False == False 为 True，右侧 False in [False] 同样为 True，两者执行 and 后结果自然是 True！
避坑方案：绝不要将等值判定与容器成员检测写在同一连续比较链条中。若意在判断比较结果是否在列表中，必须显式加括号隔离：(False == False) in [False]。

4. 陷阱四：混合逻辑中的 not、and、or 与短路返回值

在布尔表达式中，经常有人忘记 and 的优先级高于 or：

# 场景：当用户是超级管理员，或者属于活跃且已认证的用户时放行
is_super = False
is_active = False
is_verified = True

# 错误直觉：认为从左到右依次判断 (is_super or is_active) and is_verified
# 实际行为：解释器解析为 is_super or (is_active and is_verified)
if is_super or is_active and is_verified:
    print("通过校验")

另外，Python 中的 and 与 or 返回的不是固定的 True/False，而是决定最终真假的操作数本身（短路求值）：

• "hello" or "world" 返回 "hello"（左侧为真，立即短路返回）。
• [] and "world" 返回 []（左侧为假，立即短路返回）。
• 0 or [] or "default" 返回 "default"。

图 3：常见运算符优先级陷阱的错误机理与防御性编码示范

四、工程排错与验证：利用 AST 查看真实解析结构

当遇到团队遗留代码中极其复杂的长表达式，或者无法笃定某个运算符的绑定关系时，无需在生产环境中“猜谜”。Python 标准库内置的 ast（抽象语法树）模块提供了最权威的底层验证手段。

我们可以编写一段仅需 3 行的小脚本，直接打印出 Python 语法分析器对表达式的真实结合视图：

import ast

# 待验证的表达式字符串
expr_str = "flags & 0x01 == 0"

# 解析为 AST 语法树并格式化打印
tree = ast.parse(expr_str, mode='eval')
print(ast.dump(tree, indent=2))

运行该脚本后，可以看到如下清晰的输出：

Expression(
  body=Compare(
    left=BinOp(
      left=Name(id='flags', ctx=Load()),
      op=BitAnd(),
      right=Constant(value=1)),
    ops=[
      Eq()],
    comparators=[
      Constant(value=0)]))

通过语法树的嵌套层级可以一眼看清：最外层的节点是 Compare，它的左操作数是 BinOp(BitAnd)，右操作数是 0。这就铁证如山地表明：在没有外层干扰时，BinOp 会作为整体成为 Compare 的操作数，但一旦混合了多项逻辑，AST 结构能立刻揭示谁先结合、谁后结合。

五、总结：编写无歧义 Python 表达式的决策清单

理解运算符优先级是为了在阅读他人代码时拥有精准的洞察力；而在自己编写代码时，最好的实践是“不依赖读者的记忆力”。以下是推荐的日常编码与代码审查决策流程：

图 4：复杂表达式审查与防御性编码决策路径

记住这一条核心心法：在 Python 中，加括号不是因为你不懂优先级，而是为了让看你代码的人无需去背优先级。编写清晰、显式、无歧义的表达式，是编写生产级高质量 Python 代码的基本功。