Python运算符优先级应靠理解与括号显式控制而非死记；最易出错的5个陷阱包括not in、位运算与比较混用、**右结合性、链式比较与位运算混淆、条件表达式低优先级；括号用于语义安全而非仅可读性。
Python 运算符优先级不是靠死记，而是靠理解结合括号显式控制；盲目依赖记忆顺序极易出错，尤其在混合使用 **、&、^、| 和比较运算符时。
最常踩坑的 5 个优先级陷阱
这些位置最容易写出和预期不符的表达式：
-
not x in y实际等价于not (x in y)（not优先级低于in），但很多人误以为是(not x) in y -
x & y == z等价于x & (y == z)，而非(x & y) == z—— 因为==优先级高于& -
a = b + c * d没问题，但a = b + c ** d中**优先级远高于+，且右结合：2 ** 3 ** 2是2 ** (3 ** 2)= 512，不是(2 ** 3) ** 2= 64 -
x z是合法的链式比较，等价于(x z)，但x 同样合法，而 <code>x 就会先算 <code>y & z再比较 -
lambda x: x + 1 if x > 0 else x - 1中，条件表达式整体优先级很低，低于or、and、not，所以f() or x if cond else y会被解析为(f() or x) if cond else y
什么时候必须加括号？不是“可读性”，而是语义安全
括号不是为了“让别人看懂”，而是堵住优先级歧义的唯一方式。以下情况不加括号就等于埋雷：
- 任何涉及位运算
&/^/|和比较运算符（==、等）混用的地方，例如 <code>flags & MASK == VALUE→ 改为(flags & MASK) == VALUE - 混合逻辑运算与位运算：
a & b or c实际是(a & b) or c，但若本意是a & (b or c)，后者根本非法（类型不匹配），所以更可能是想写(a & b) or c—— 仍建议加括号明确意图 - 指数和负号连用：
-3 ** 2结果是-9（因为**优先级高于-），如需9，必须写(-3) ** 2 - 函数调用后紧跟属性或索引：
func()[i] + 1没问题，但func()[i] == x and y中，==优先级高于and，所以无需额外括号；不过obj.method()[i] & FLAG建议写成(obj.method()[i]) & FLAG，避免视觉断层引发误读
完整优先级表（由高到低，仅列关键层级）
官方文档的完整表有 17 级，但实际只需盯紧这 8 组差异点（同一行内左结合，行间上高下低）：
立即学习“Python免费学习笔记（深入）”；
[expr] # 下标、切片、调用、属性访问 ** # 右结合：2**3**2 → 2**(3**2) +x, -x, ~x # 正负号、按位取反 *, /, //, % # 乘除模整除 +, - # 加减 <<, >> # 位移 & # 按位与 ^ # 按位异或 | # 按位或 ==, !=, <, <=, >, >=, is, is not, in, not in # 比较、成员、身份测试（全部同级，支持链式） not # 逻辑非 and # 逻辑与 or # 逻辑或 if-else # 条件表达式（优先级最低） lambda # lambda 表达式（最低，仅低于赋值）
注意：lambda 和条件表达式都比赋值运算符 = 优先级高，所以 x = lambda: 1 if True else 2 合法，但 x = 1 if True else 2 是赋值整个条件表达式的结果。
真正难的不是记住表格，而是意识到：Python 的优先级设计本身就不鼓励复杂表达式。一旦你发现自己在数括号层数，或者需要查表才能确认 a & b == c | d 怎么分组，就应该拆成多步变量赋值 —— 那不是啰嗦，是把隐式依赖变成显式控制。
