编程运算符的隐藏陷阱：从整除到位运算的深度解析

先讲一个我昨天刚处理完的线上Bug：一段数据清洗脚本，明明逻辑看起来毫无问题，却把一批订单金额全部算成了负数。排查半天，最根子上的原因居然就是一个整除运算符的误用。这种事儿在刚接触编程那几年几乎每隔一阵就冒出来一次，后来我意识到，基本运算符从来不是"认识符号"那么简单，真正理解它的人，是能把类型系统、求值顺序、隐式转换和底层位模式全部串起来的人。

这篇文章不打算按教科书那样把运算符从头到尾罗列一遍，而是从一个实际干活的人视角，把"基本运算符"拆成真正影响你写代码质量的那些细节：哪些地方容易踩坑、哪些行为在不同语言里不一样、排查运算符相关Bug时的完整思路。内容以Python为主线，兼顾C、Java、JavaScript这些主流语言的对照，无论你是刚入门还是已经写了几年，应该都能找到对得上号的东西。

1. 运算符的本质：它只是函数调用的糖衣

很多人学运算符是从记忆"加减乘除、大于小于"开始的，这当然没有错，但如果停留在"符号即操作"这个层面，遇到稍复杂的情况就容易懵。我自己的理解是，运算符本质上是一种编译器或解释器帮你封装好的函数调用，它和我们写add(a, b)、compare(a, b)没有什么根本区别，只是换了一种更贴近数学直觉的写法。

用这个视角看问题，很多疑惑就能解释得通：为什么整数除法在不同语言里结果不一样？因为底层被调用的那个"除法函数"定义了不同的取整规则。为什么NaN不等于自身？因为比较运算封装的语义是基于IEEE 754浮点标准，而这个标准就规定了NaN和任何值都不相等。为什么逻辑运算符能返回非布尔值？因为它底层调用的函数约定"短路时返回操作数本身，而非强制转成布尔值"。

1.1 运算符重载：让糖衣变得更甜，也让Bug更难找

说到函数调用，就绕不开运算符重载。Python在这件事上做得非常彻底，几乎每个运算符都对应一个魔法方法：+对应__add__，==对应__eq__，in对应__contains__。这意味着，当你写出a + b的时候，真正执行的是a.__add__(b)，如果a没有定义__add__，它还可能尝试b.__radd__(a)。

我见过一个很有意思的项目，在里面+被重载成"把两个配置字典合并"，|被重载成"给权限列表添加一项"。对于同一个代码库的开发者来说，这种自定义语义确实提升了表达效率，但对新加入的人来说，阅读成本也随之上升——毕竟看到+，直觉还是数学加法。这个小例子其实点出了一个重要的事情：运算符的"语义稳定性"是代码可读性的隐性支柱，在业务代码里随意重载运算符，往往得不偿失。

所以在后续的每一个章节里，我建议读者都带着"底层在调用什么函数"这个意识去看运算符，而不是只背规则。

1.2 为什么先搞懂类型，再搞懂运算符

运算符能不能正常工作，有一个前置条件，那就是操作数的类型是否满足运算规则。一个字符串和一个整数相加，在Python里直接报TypeError，在JavaScript里却会被隐式转换成字符串拼接，这两种行为没有绝对的对错，但如果你不清楚当前语言走的是哪条路，写出来的代码就非常容易被"看起来对、实际错"的结果迷惑。

这正好引出全篇最重要的一条经验：当你遇到一个运算符相关Bug时，先别急着怀疑运算符本身，先检查操作数的类型是什么。现实中大量"运算符Bug"到最后都被证明是类型Bug——你以为它是整数，它是字符串；你以为它是布尔值，它是个非空列表。后面第8节我会用一个完整的排查案例来演示这条思路怎么落地。

2. 算术运算符的数字陷阱：整除、取模与浮点精度

算术运算符是人人都觉得自己会的部分，但它们恰恰是Bug隐藏最深的区域。尤其是除法，它在不同语言里的行为差异能让人抓狂。Python 3里/是真正的浮点除法，//才是整除；C或Java里/用在两个整数之间时直接截断小数部分；JavaScript则以完全采用浮点数运算。这里最经典、也最隐蔽的坑是Python 2时代的/在整数之间执行整除——很多老代码迁移到Python 3后出现莫名奇妙的计算结果，根子就在这里。

2.1 整除行为的统一理解方式

很多资料会把//描述成"向下取整"，这个说法容易误导。真正准确的理解应该是：a // b 返回的是不大于a / b精确结果的最大整数。注意这里有个微妙之处，它和"向零取整"（C语言整数除法的默认行为）在两个操作数符号不同的时候会得到不同的结果。

看一个对比例子：

python复制# Python：向下取整
print(-7 // 3)    # -3，因为 -7/3 = -2.333...，不大于它的最大整数是 -3
print(7 // -3)    # -3，因为 7/-3 = -2.333...，不大于它的最大整数是 -3

c复制// C语言：向零取整
// -7 / 3 的结果是 -2，直接丢掉小数部分
// 7 / -3 的结果也是 -2

这种差异在涉及方向、偏移量计算的场景里非常致命。比如你在写一个分页逻辑，offset = page // size，如果某个边界参数为负，Python和C得到的结果可能差1，进而导致数据错位。

2.2 取模运算符的符号跟随规则

和整除紧密相关的是%取模运算。Python的%结果总是和除数（右侧操作数）符号一致，而C语言的%结果总是和被除数（左侧操作数）符号一致。这个区别在循环数组下标、时钟计算这类场景里会造成完全不同的行为。

python复制# Python
print(-7 % 3)   # 2，因为 -7 = (-3)*3 + 2，余数和除数3同号
print(7 % -3)   # -2，余数和除数-3同号

c复制// C
// -7 % 3 的结果是 -1，余数和被除数-7同号
// 7 % -3 的结果是 1，余数和被除数7同号

在写循环数组指针的时候，我通常会用Python风格的取模，因为它天然保证结果落在[0, n)区间，用来做环形队列的下标计算非常顺手。而在做底层协议解析时，如果需要和C代码保持一致的语义，就得特别小心，建议显式写出取模之后的正负修正逻辑，而不是依赖语言默认行为。

2.3 浮点精度：不是运算符的锅，但运算符背锅

再来说浮点数。很多人会把0.1 + 0.2 != 0.3归咎于加法运算符出错，其实加法本身算得非常准，问题出在浮点数无法精确表示0.1和0.2，以及运算结果需要按IEEE 754标准舍入到最近的可表示值。这个机制是所有现代CPU共用的，和Python、JavaScript、C都没有关系。

处理这类问题的思路，不是把加法运算符换掉，而是改变比较和舍入的策略。实际工程中，我一般这样处理：

python复制# 不要直接比较浮点结果
if 0.1 + 0.2 == 0.3:
    pass

# 用绝对误差或相对误差比较
epsilon = 1e-9
if abs((0.1 + 0.2) - 0.3) < epsilon:
    pass

# 或者在需要精确十进制计算的场景使用 Decimal
from decimal import Decimal
result = Decimal("0.1") + Decimal("0.2")

注意：Decimal("0.1")和Decimal(0.1)完全不同，前者从字符串构造，能得到精确的十进制的0.1；后者先把二进制浮点数0.1转成字符串再构造，带入了二进制误差。这个细节我见过很多人踩坑，建议直接用字符串或整数构造。

2.4 自增自减：一个让Python程序员羡慕C语言的语法糖

i++和++i在C系语言里是极其常用的运算符，但当习惯它们的人转写Python时，会发现Python并不支持自增自减运算符。这并非Python的缺失，而是因为Python的设计哲学是"显式优于隐式"，它鼓励你直接写i += 1。

i++的前置和后置差异（先返回旧值再自增，还是先自增再返回新值）在很多C语言笔试题目里都是经典考点，但在实际业务代码中，这种微妙差异引发的Bug远比它带来的便利要多。我的建议是：即使你写的是C语言，也尽量把自增自减单独放在一行，不要混在复杂的表达式里，这是很多资深团队的实际规范。

3. 相等性判断的暗坑：==与is的底层逻辑

在Python里，==比较的是值是否相等，is比较的是两个变量是否指向同一个对象。这个区别初一接触很好理解，但在实际代码里，is被误用导致的Bug一点也不比==被误用的少。

3.1 为什么Python的小整数可以被is判定为相等

有一个很经典的现象：a = 256; b = 256; a is b的返回结果是True，但a = 257; b = 257; a is b的返回结果是False。这是因为CPython解释器在启动时就会缓存-5到256之间的小整数对象，所有对这个范围内整数的赋值，实际拿到的都是同一个对象的引用。超过这个范围，每次计算都会创建新的对象。

这个缓存机制是CPython的实现细节，Python语言规范并没有强制要求，所以拿它当判断依据属于危险行为。但理解它有助于你理解"对象引用"到底是什么概念。我之前排查过一个诡异的Bug，一段代码在本地跑得好好的，部署到服务器上偶尔出现行为不一致，后来定位到正是因为代码里用is比较了一个较大的整数，两个环境的内存分配和对象复用策略有差异，导致结果不稳定。

3.2 比较数组、字典和自定义对象时发生了什么

对于列表和字典来说，==做的是结构性比较：逐项比较元素或键值对。但对于自定义对象，如果类没有重写__eq__方法，==的默认行为就退化为is，也就是比较对象地址。

python复制class User:
    def __init__(self, name):
        self.name = name

u1 = User("zhang")
u2 = User("zhang")

print(u1 == u2)   # False，因为User没有定义__eq__

这就是一个非常容易出Bug的点：新建了两个内容一样的对象，原以为==会是True，结果却是False。修复方式是在类里定义__eq__，同时建议定义__hash__，否则这个类会变成不可哈希对象，无法放入集合或作为字典键。

python复制class User:
    def __init__(self, name):
        self.name = name

    def __eq__(self, other):
        if not isinstance(other, User):
            return False
        return self.name == other.name

    def __hash__(self):
        return hash(self.name)

3.3 JavaScript的双等号与三等号：隐式转换的代价

JavaScript是另一个极端，==会做复杂的类型转换规则，'1' == 1为true，null == undefined为true，[] == false也为true。这些规则虽然可以在官方规范里查到，但在真实代码里，它们带来的阅读困惑和隐性Bug远大于便利。

所以现代JavaScript工程规范几乎都会强制要求使用===（严格相等），它不会做类型转换，只有类型和值都相等时才返回true。我个人非常支持这个规范，因为代码是写给人读的，显式的比较行为才符合直觉。这里有个经验可以分享：如果你发现自己需要依赖==的隐式转换才能让代码跑通，通常说明前面的设计已经出现了类型混乱。

4. 逻辑运算符的短路计算：返回值比你想象的多

逻辑运算符and、or、not是很多人从"真值表"开始学的，但实际使用中，and和or返回的并不一定是布尔值。这在Python里尤其明显——它们是短路运算符，返回值是最后一次被求值的操作数。

举个例子：

python复制a = 0 or "default"      # a = "default"，因为0是假值，继续求值"default"，返回它
b = [] or {}            # b = {}，因为[]是假值，继续求值{}，返回它
c = "hello" and "world" # c = "world"，因为"hello"是真值，需要再判断第二个操作数才能确定结果
d = 1 and 2             # d = 2

这个机制用得好，可以写出非常简洁的默认值逻辑：name = user_input or "anonymous"。但这也带来一个潜在风险：如果你在条件表达式里直接使用了and、or的结果，而忽视了它可能是非布尔值，就可能让后面的逻辑出问题。

4.1 短路求值和条件判断嵌套

短路求值最实际的价值在于，它可以避免无效计算甚至无效操作：

python复制# 避免除零错误
if b != 0 and a / b > 2:
    print("ratio > 2")

# 避免访问空对象属性
if obj is not None and obj.value > 10:
    print("value > 10")

这里and右侧的表达式只有在左侧为真时才会执行，从而天然承担了"前置条件检查"的职责。同样地，or也常被用来做回退逻辑：配置项为空时，用默认配置替代。

4.2 警惕长链式逻辑表达式的可读性问题

虽然短路求值很有用，但一个表达式里串了四五个and、or再加一堆括号，对阅读者来说就是一场灾难。我以前接手过一个老项目，里面有一行条件判断差不多有120个字符，缩进式排版后仍然很难一眼看出优先级和边界，最后调试时只能一步步拆开打印中间结果。

后来我的习惯是：只要逻辑链超过两个运算符，就把它拆成有名字的中间变量。比如把if (a or b) and (c or d) and not e:拆成：

python复制is_valid = (a or b) and (c or d)
is_blocked = e
if is_valid and not is_blocked:
    ...

这样做有三个好处：第一，代码意图清晰可读；第二，调试时可以分别检查每个中间变量；第三，修改条件时不用小心翼翼地在长表达式里挪括号。

5. 位运算的低调力量：从权限标记到压缩存储

位运算（&、|、^、~、<<、>>）是所有运算符里最容易被忽略的，但在底层系统、协议解析、性能敏感场景中，它又是无可替代的利器。它处理的是整数的二进制位，不会出现浮点误差，也不会被隐式转换成其他类型（Python里需要操作数本身就是整数）。

5.1 用位掩码实现权限标记

最常见的位运算应用是权限管理。假设一个系统有三种权限：读、写、执行，分别对应二进制位：

python复制READ = 1  # 0b001
WRITE = 2 # 0b010
EXEC = 4  # 0b100

一个用户拥有读和执行权限，权限值就是 READ | EXEC = 5（0b101）。判断用户是否有某个权限，用按位与：

python复制permission = READ | EXEC
print(permission & READ)   # 非0，说明有读权限
print(permission & WRITE)  # 0，说明没有写权限

这种方案的妙处在于，多个权限的状态可以压缩到一个整数里存储，数据库里只需要一个字段，判断也只需要一次位运算。相比用["read", "exec"]这样的字符串列表，既节省空间，判断又快。

权限的"叠加"用|，"移除"用& ~：

python复制permission |= WRITE      # 添加写权限
permission &= ~WRITE     # 移除写权限

5.2 移位运算与乘除法的底层关系

左移一位相当于乘以2，右移一位相当于除以2后向负无穷取整（Python行为）。这种等价关系在性能优化场景中会用到：比如一段需要运行千万次的代码，把x * 2改成x << 1，把x // 2改成x >> 1，确实可以省下一些时间。但现在的编译器基本已经能自动做这种优化，我在业务代码里并不会刻意去做这个改写，只有在明确需要处理位模式、实现自定义协议、或者写嵌入式固件时才会直接操作移位。

5.3 异或的经典用途：交换、加密与校验

^异或有一个非常有趣的性质：相同位为0，不同位为1。由此可以推导出几个实用技巧。一是用异或交换两个数，不需要临时变量：

python复制a = 5
b = 9
a ^= b
b ^= a
a ^= b
print(a, b)  # 9 5

虽然这个技巧在Python里更多是炫技，实际不值当为了省一个临时变量而牺牲可读性，但理解它的原理对理解二进制运算很有帮助。

二是异或在简单校验中的应用：两个相同的数异或为0，一个数和0异或不变。这意味着x ^ y ^ y恒等于x，所以异或也可以用于简单的数据恢复或对称加密技巧。当然，真正做加密脱敏必须用正规算法，异或只能算玩具级别。

5.4 不同语言中的位运算差异

位运算在不同语言里也有细微差异，最典型的是对有符号整数的右移行为。在C和Java里，>>是算术右移（符号位填充），>>>（仅Java）是逻辑右移（0填充）。Python里没有无符号右移概念，因为它的整数可以无限长，>>对负数也采用的是算术右移，配合Python的无限精度特性，整个过程不容易出现符号位溢出困扰。

我见过不少从Java转写Python的开发者，在解析二进制协议时习惯性找>>>，找不到就去手动模拟。实际上Python中处理无符号语义，最稳妥的方式是先用& 0xFFFFFFFF把数截断成32位无符号整数再做右移。

6. 赋值运算符与求值顺序：一个=和==引发的连环事故

赋值运算符看起来最简单，但"=和==写混"这种错误在任何年代都可能发生。在Python里，if a = 1这种写法会直接语法报错，而在C语言里却是合法的：它先把1赋给a，再判断a是否为真。无数C语言新手（以及资深程序员在疲惫时）都吃过这个亏。

6.1 赋值表达式的值：语言间的一个核心差异

在Python中，赋值语句不是表达式，没有值，所以不能放进条件判断里。在C语言中，赋值是一个表达式，它的值就是被赋的那个值，所以if (x = foo())这种写法合法且常见。在JavaScript中，赋值同样可以作为表达式，但团队规范通常会在这种场景要求写得更明确，比如先用临时变量再接判断。

这个语法层面的差异，导致了一个有趣的现象：Python开发者转写C或Java代码时，很少会在条件里写赋值；但C开发者转写Python时，往往会不自觉地敲出if (x = get_value())，然后Python直接抛语法错误，反而是一种安全保护。

6.2 链式赋值和多重赋值：底层引用指向同一对象

Python里可以写a = b = []，这种链式赋值会让a和b指向同一个空列表对象。这常常是新手Bug的来源：

python复制a = b = []
a.append(1)
print(b)  # [1]，因为a和b是同一个列表

如果你想要两个独立的空列表，必须是a = []; b = []或a, b = [], []。我见过一个数据处理的脚本，因为这里一个误用，导致两个本该独立的统计数据被写到了同一份列表里，最后产出的报表错得很隐蔽。

6.3 复合赋值运算符的原地操作与新建操作

Python的+=、*=这类复合赋值有一个微妙之处：对于可变对象，它可能执行原地修改；对于不可变对象，它一定会生成新对象并重新绑定。但Python的+=实际上先调用操作数对象的__iadd__方法，如果该方法不存在，才会退化为__add__。

看这个例子：

python复制a = [1, 2]
b = a
a += [3]      # 调用__iadd__，原地修改
print(a)      # [1, 2, 3]
print(b)      # [1, 2, 3]，b也变了，因为a和b指向同一个列表

a = a + [4]   # 调用__add__，生成新列表
print(a)      # [1, 2, 3, 4]
print(b)      # [1, 2, 3]，b还是原来的列表

这个差异在函数传参场景里尤其容易引发连锁反应。一个列表被传入函数，函数内部执行items += new_items，如果没有意识到这是原地修改，外层调用者就会惊讶地发现自己的列表也被改了。这种Bug排查起来很费劲，因为问题不在报错，而在"数据什么时候变了"。

6.4 一行赋值多个变量时的求值顺序

Python里a, b = b, a可以交换两个变量，因为右边的元组会先被完整求值，再依次赋值。但如果你想写更复杂的交换，比如a[b] = a[b], a[c]，这里的求值顺序就值得注意了：Python会先求出等号右侧的所有表达式，然后再按从左到右的顺序对左侧目标做赋值。虽然语言规范保证了这一点，但复杂的目标赋值最好还是拆开写，否则可读性太差。

7. 运算符优先级：一张表背后的规则本质

每个语言都有一个运算符优先级表，工程师看着它写代码，其实不是靠背表的，而是靠一个原则：不确定就先加括号。但为什么优先级仍然值得深究？因为优先级不仅仅是优先级，它背后是整个表达式求值顺序的规则骨架。

7.1 优先级和结合性要一起看

单独记住*比+优先级高是不够的，还要知道当两个同优先级运算符连在一起时，是左结合还是右结合。幂运算符**在Python里是右结合的，所以2 ** 3 ** 2等于2 ** (3 ** 2)，结果是512而不是64；赋值运算符是右结合的，所以链式赋值a = b = 1先从右往左处理。

乘法、加法这些满足交换律和结合律的运算，左右顺序在语义上往往不敏感，但除法、减法和比较运算就完全不同了，它们对顺序极其敏感。我之前遇到过一个案例：a - b - c是(a - b) - c，这符合左结合。但如果你理解成a - (b - c)，结果就截然不同，所以结合性完全不是可以忽略的细节。

7.2 一个典型的优先级错误案例

有一种比较常见的写法是：

python复制if a & 1 == 1:
    ...

乍一看像是在判断a & 1结果是否等于1，但实际上Python的优先级规则里，==的优先级高于&，所以这行代码实际被解析为a & (1 == 1)。而1 == 1的结果是True，在按位运算时被当作1，于是整个表达式变成了a & 1。大部分时候这个结果恰好是对的，但一旦你希望判断的是其他位模式，就会悄悄出错。

这类Bug最恶心的点在于它不报错，结果还经常碰巧正确，所以特别难发现。排查这类问题时，我通常会把表达式用括号完全写开再推一遍，或者直接跑一小段代码验证解析结果。

7.3 Python、Java、C的优先级差异对照

Python、Java、C这三种语言的运算符优先级大同小异，但有几个边界差异值得注意。第一是位运算符和比较运算符的相对位置：在C里==优先级高于&，Python和Java遵循同样的规则，这符合我们的直觉吗？并不，数学直觉里面按位与应该"更紧"，但语言规范不是这么定的。第二是移位运算符和加减法的优先级：C里<<优先级低于加减法，所以1 << 2 + 3被解析为1 << (2 + 3)，而很多新手期望它是(1 << 2) + 3。

这些差异在跨语言阅读代码时最容易产生误解。我的建议是，所有涉及混合运算的表达式，一律显式括号。这不丢人，反而减少团队沟通成本。

8. 一次真实排查记录：运算符Bug的典型生命周期

理论讲了不少，现在用一个我实际经历过的案例来演示，遇到运算符相关的疑难Bug时，完整的排查思路是什么。

某个数据报表服务，每天早上跑批统计前一天的订单量。逻辑大致是：订单数据里有个状态字段，状态值是2代表已完成；已完成的订单分成三组，折扣组、满减组和普通组；最后按组汇总金额。某天运营反馈，其中一个组的金额总是偏大，而且没有明显规律。

8.1 错误表现：不是报错，是数字不对

这种Bug最麻烦，因为程序不报异常，只有最终数字对不上。排查第一步，我先确认触发范围：是所有日期都偏大，还是特定日期？抓了一周数据，发现周一、周三偏大，周二、周四正常，完全看不出模式。这时候线索不足，我决定在汇总逻辑里加临时日志，把每一组的订单明细和对应的金额判断条件打出来。

8.2 定位过程：把复合条件拆开

看到日志后，问题一下子就清楚了。在分组逻辑里，有一段类似下面的判断：

python复制if status == 2 and order_type == "discount" or order_type == "full_reduction":
    ...

你以为的条件是"状态为已完成，并且（类型是折扣或满减）"，但Python的实际解析是"（状态为已完成且类型是折扣）或（类型是满减）"。也就是说，当时状态字段不是2、但订单类型是满减的订单，也会被错误地分到这个组。这就是and和or优先级不同导致的逻辑范围扩大。

为什么只在特定日期出现？因为那些日期的满减订单里，恰好有部分订单状态不是已完成（比如刚创建但未支付），而其他日期这类数据偏少或为零。所以现象看起来随机。

8.3 修复方案与复盘

修复很简单，给条件加上括号：

python复制if status == 2 and (order_type == "discount" or order_type == "full_reduction"):
    ...

复盘时我给自己定了两条铁律。第一，涉及多个逻辑运算符的条件，必须用括号明确分组，无论语言优先级规则如何。第二，条件表达式如果超过一行，就先抽成命名清晰的布尔变量，哪怕看起来多写了几个字，换来的是后人（包括自己）读代码时不会误解。

8.4 从这次排查沉淀出的自检清单

我把这类问题的检查思路固化成了一个清单，每次遇到"结果不符合预期"的Bug，都会按顺序过一遍：

• 第一步，确认操作数的真实类型，特别是从外部数据源读进来的字段，十有八九是字符串。
• 第二步，把复合条件表达式按运算符优先级展开成树状结构，逐节点验证。
• 第三步，检查是否有隐式类型转换，尤其是跨语言边界的数据。
• 第四步，检查操作数里的边界值，比如0、空字符串、None、NaN。
• 第五步，用最小化数据量写单元测试，把每个运算符的行为钉死在测试里。

这套流程不敢说能解决所有Bug，但在运算符相关问题上，命中率非常高。

9. 把运算符用好，是一辈子的事

这些年在不同语言、不同项目里和运算符打交道，最大的感受是：运算符的符号永远只有那么几个，复杂的是它背后连接的类型系统、求值顺序和语言设计哲学。一个能清楚解释0.1 + 0.2为什么不等于0.3、-7 // 3为什么等于-3、``a = b = []`为什么两个变量指向同一个对象的人，大概率也能在别的语言里快速定位类似的坑。

如果这篇文章能给你留下一个具体的行动建议，那就是：拿你正在用的语言，把每个运算符的边界行为都写进单元测试里。比如整除负数、取模负数、浮点比较、短路返回、空值隐式转换、混合类型运算——每个场景写一个断言。这个过程会逼你查文档、做实验，最终形成你自己的运算符直觉，这比看十篇教程都管用。我之前在团队里推过一次，花半天时间写出来的测试文件，后续帮大家挡掉了很多线上问题。

最后分享一个写代码时的个人习惯：凡是让我犹豫"这个表达式会不会有什么隐藏规则"的地方，一律拆开写清楚。不是因为我记不住优先级表，而是因为几年后回头看代码的人不一定是当初那个带着上下文记忆的自己。写代码是给未来的自己看的，运算符这种最基础的零件，越是基础，越值得多花一点心思把它摆得明明白白。