补码与取模运算：负数取模、位运算及哈希分片越界实践

前几年帮一位开发者排查一段哈希分片的下标越界代码，现象很奇怪：分片号偶尔会变成负数，程序直接抛出数组越界异常。把日志捞出来看，哈希值是负的，取模运算之后的结果居然也是负的。写这段代码的人理直气壮地说，"负七除以二余一，这不是小学数学吗"。可在这门语言里，-7 % 2的结果是-1，不是1，错误就一直留在那里。这个假设错得如此自然，以至于很少有人会去验证它。

而顺着这条线往下挖，就会碰到一个更底层的东西：补码。补码和取模运算并不是两个独立的知识点，它们其实在讲同一件事——n 位二进制寄存器的回绕，本质上就是模 2^n 的运算；所谓"负数用补码表示"，不过是把这个模空间里的元素重新贴了一遍标签。把这两件事串起来看，很多原本要靠背的结论（比如-x = ~x + 1、x & (2^k-1)能替代取模、abs(INT_MIN)会出问题）就都变成了可以自己推出来的东西。这篇就按我自己踩过的顺序，把这层关系拆开讲，涉及语言差异、位运算等价性、边界值和环形结构里的实际用法，适合写过业务代码但没系统梳理过底层表示的朋友。

1. 哈希分片下标为负的那次排查：模运算的余数到底跟谁走

先从那次排查的具体过程说起。代码逻辑很简单：拿到对象的哈希值，对分片数量取模，得到分片下标。分片数量是 16，正常情况下标落在 0 到 15 之间。问题出在哈希函数对某些键算出来的值是负数，负数取模之后就变成了负下标。当时第一反应是"哈希函数写错了"，改了半天哈希，问题只是变得不那么容易出现，并没有消失。真正的定位是在打印了十几个样本之后才看清的：所有出问题的样本，哈希值都是负数，取模结果也都是负数，而且这个负数的绝对值都小于分片数。

这个现象说明取模的结果符号跟着被除数走，而不是跟着除数走。知道了这一点，修改方案就很直接了：要么在取模前把哈希值变成非负，要么用一段能把负数结果搬回正区间的逻辑。但那次的教训不止于此——同一个表达式在不同语言里的结果不一样，如果这段代码被移植过，坑会以另一种形式重现。所以有必要把除法规则本身讲清楚。

1.1 除数截断与被除数截断：两种除法规则的正面对撞

整数除法的核心问题是：当被除数和除数异号时，商向哪个方向取整。这里存在两种主流约定，一种叫截断除法（向零取整），另一种叫地板除法（向负无穷取整）。商定下来之后，余数就由恒等式被除数 = 除数 × 商 + 余数唯一确定，所以余数的符号完全是被商"带"出来的。

截断除法下，-7 / 2的商是-3（往零的方向靠），代回恒等式得到余数-1；地板除法下，商是-4（往负无穷靠），余数是1。两种都满足恒等式，数学上都没错，区别只在于工程上你更想要哪个。C、C++、Java、Go、Rust、JavaScript 这一派走的是截断除法，Python、Ruby 以及不少数学软件走的是地板除法。这就是为什么同一段取模代码换个语言跑，结果会不一样。

值得补充一句历史背景：C 语言在 C99 之前并没有规定负数除法的舍入方向，只要求商向零截断或向负无穷截断之一，把选择权留给了实现。这意味着早期不同编译器上-7 % 2可能给出不同答案。C99 之后统一规定为向零截断，才算把这件事钉死。如果你维护的是很老的代码或者要跑在非主流编译器上，这个细节值得留意。

1.2 把符号规则整理成一张表

光靠文字描述容易记混，我习惯用一张表把四种符号组合的结果列清楚，需要的时候直接查。下表以a = -7, b = 2和a = 7, b = -2两组为例，对比截断除法（以 C 系语言为代表）和地板除法（以 Python 为代表）的差异。

从表里能读出两条规律。截断除法下，余数的符号永远和被除数一致，绝对值小于除数的绝对值；地板除法下，余数的符号永远和除数一致，取值范围落在[0, |除数|)区间内。后者正是"非负余数"需要的性质——只要把除数取绝对值，结果天然就落在非负区间，不需要任何后处理。这也是为什么很多算法题解在 Python 里写起来格外顺手，取模结果不会有负号骚扰。

反过来，在 C 系语言里想拿到非负余数，就得自己动手。最常见的写法是r = a % b; if (r < 0) r += b;，前提是b为正。这个写法在b为正数时成立，因为a % b的结果落在(-b, b)开区间内，最多加一次b就回到[0, b)。如果b可能是负数，还得再处理一次，或者干脆对b取绝对值。另一种写法是(a % b + b) % b，多一次取模，逻辑上更"无脑"，但多了一次除法指令，在热点路径上不划算。

1.3 工程上为什么普遍想要"非负余数"

明明两种约定都自洽，为什么工程代码里一边倒地倾向于非负余数？答案在于余数的典型用途：当下标用。数组下标、分片编号、槽位序号，这些东西的取值范围天然是0到n-1，一旦出现负数就是非法值。截断除法给出的带符号余数，等于把"检查并修正符号"这件事推给了每一个调用方，漏掉一处就是一个越界隐患。

我在几个项目里都遇到过类似的情况：同一套取模逻辑被复制到五六个地方，其中两处记得加符号修正，剩下几处忘了。这类 bug 的特点是触发条件苛刻（需要哈希值为负、且绝对值小于模数），测试环境里很难稳定复现，上线之后变成偶发异常。后来我们干脆在工具层封装了一个floorMod函数，所有需要按下标语义取模的地方统一调用它，从源头上消灭这个分支。

提示：判断一个取模表达式该用哪种语义，问自己一个问题——结果的用途是"当下标/槽位"，还是"算差值的符号"。前者一律要非负余数，后者用哪种都行，但要保证上下游一致。

2. 补码不是"取反加一"的口诀，它是模 2^n 的一个同余类

讲补码的资料大多从"取反加一"这个操作讲起，结果很多人记住了口诀却不知道它为什么成立，遇到-128这种边界值就懵。我更愿意从模运算的角度切入：n 位寄存器能表示的位模式一共 2^n 个，把它们看成一个环，加法就是在环上顺时针走格子，走满一圈自动回到起点。这个"走满一圈回到起点"的行为，就是模 2^n 的加法。

在这个环上，"减去 x"和"加上某个数"是等价的——只要你加的那个数恰好是 x 在环上的"补"（补到整数圈）。举个生活里的例子：钟表上现在是 3 点，要往回拨 5 小时，可以往回调 5 格到 10 点，也可以往前拨 7 格到 10 点。对 12 小时制的钟来说，减 5 和加 7 是同一件事，因为 5 + 7 = 12，正好一整圈。计算机里的补码三个字，说的就是这个"补满一圈"的意思，只不过圈长是 2^n 而不是 12。

2.1 从钟表回绕到 n 位寄存器的回绕

把上面这个类比搬到 8 位寄存器上。8 位能表示 256 个位模式，从00000000到11111111，加法逐格前进，走满 256 格回到原点。想让减法a - b变成加法，就要找一个数c，使得b + c ≡ 0 (mod 256)，也就是c = 256 - b。这个c就是-b在这个环里的表示。对 8 位来说，b = 1时c = 255 = 11111111，b = 5时c = 251 = 11111011。

把255和-1对应起来，把251和-5对应起来，就得到了补码的映射规则：高位为 1 的那一半位模式，解释成负数。具体说，位模式的无符号值是u，如果u < 2^(n-1)，解释成u本身；如果u >= 2^(n-1)，解释成u - 2^n。8 位时，u = 251对应的有符号值就是251 - 256 = -5，和预期一致。这个映射是双射，256 个位模式一一对应到[-128, 127]这 256 个整数，一个不多一个不少。

这种映射带来的最大好处是硬件不用为减法单独做一套电路。CPU 里只有一个加法器，减法通过"取补再相加"完成，符号位和有符号溢出靠几个逻辑门单独判断。这是补码能一统天下的根本原因——省硬件，也就省钱。早期确实存在过反码和原码的方案，各自都有"正零负零"或者"减法要特判"的麻烦，最终都被淘汰了。

2.2 完全剩余系与有符号映射

用数学语言把上一段的话重说一遍：n 位补码表示的整数集合，与模 2^n 的完全剩余系{0, 1, ..., 2^n - 1}之间存在一一对应。运算在模 2^n 意义下进行，最后按映射规则解释回有符号数。这句话看起来抽象，但它解释了一个反直觉的现象：有符号加法和无符号加法在机器层面是完全相同的指令，CPU 根本不区分你声明的是int还是unsigned，它只负责把两个位模式加起来，进位丢掉。

差异只出现在两处：一是比较大小，二是除法和取模（因为除法要把位模式解释成数值才能算），三是溢出时的行为定义。比较大小之所以不同，是因为有符号数的最高位是符号位，无符号比较会把它当成数值权重。这也解释了一个经典坑：把-1赋给无符号变量，会变成一个极大的正数，因为位模式111...111解释成无符号就是2^n - 1。

理解了这个映射，很多"看起来玄学"的位运算技巧就变成了自然推论。比如判断x是否为奇数，x & 1对有符号负数同样有效，因为& 1只看最低位，而最低位在补码和原码里含义相同。再比如快速求x的相反数，~x + 1的正确性也能直接推出来，下面一节展开。

2.3 -x = ~x + 1 的推导过程

这个恒等式几乎是每个学计算机的人都背过的，但推导一遍才知道它依赖什么。设x的位模式是 n 位。~x是逐位取反，那么x + ~x会得到什么？每一位上x_i + (1 - x_i) = 1，没有进位干扰，所以x + ~x = 2^n - 1，也就是全 1。于是~x = (2^n - 1) - x。

现在要验证的是~x + 1 ≡ -x (mod 2^n)。代入得(2^n - 1 - x) + 1 = 2^n - x ≡ -x (mod 2^n)。证毕。整个过程只用了两个事实：逐位取反等于用全 1 减去原数，以及模 2^n 下2^n等价于 0。没有任何对x正负的假设，所以这个式子对x为正、为负、为零都成立。

这个推导还顺带解释了一个容易忽略的边界：当x = -2^(n-1)（也就是最小值）时，-x在 n 位里表示不出来，因为2^(n-1)超出了[-2^(n-1), 2^(n-1)-1]的范围。用位运算执行~x + 1，结果还是x自己，看起来"什么都没发生"。这不是运算出错，而是模空间里2^(n-1)和-2^(n-1)本来就是同一个同余类。硬件 faithfully 执行了这个等价关系，出错的是调用方的语义假设。关于这个边界带来的连锁反应，第 4 节会专门展开。

3. x & (2^k - 1) 与取模：为什么位运算在负数上更"听话"

把取模换成位与，是性能优化里最常见的一招，前提是模数是 2 的幂。x % 8等价于x & 7，前者是一条除法指令（现代编译器会把常量除法优化成乘加移位，但仍然是好几条指令），后者只要一条and。这个替换在正数范围内毫无争议，但在负数范围内，等价的含义需要仔细界定——因为%给出的是带符号余数，而&给出的一定是非负值，两者在负数上并不相等。

这个"不相等"其实是好事。前面说过，工程上绝大多数取模是为了拿下标，需要的正是非负余数。位与运算天然满足这个要求，而且不需要任何修正分支。这就形成了一个挺有意思的结论：在 2 的幂模数这个特定场景下，位运算不仅更快，语义上也更接近你真正想要的东西。但前提是你清楚自己在做什么，别把它当成%的通用替代品。

3.1 掩码天然给出非负结果的原因

原因很直接：2^k - 1的位模式是低 k 位全 1、其余位全 0。任何数和它做位与，高位一律被清零，结果的二进制表示里不可能有符号位，所以结果必然落在[0, 2^k - 1]这个区间。这个过程和"取低位"完全等价，而"取低 k 位"在模 2^k 的意义下就是求余数——无论被除数是有符号还是无符号、是正还是负。

反过来看%运算，它需要先把位模式解释成有符号数值，再做除法，除法的舍入规则决定了余数符号。多了一步"解释"，就多了一层可能和你预期不符的地方。位运算跳过了这个解释步骤，直接在位模式上操作，所以它给出的结果和"模 2^k 的非负余数"永远一致。这个差异在写哈希表、环形缓冲、位图的时候很关键。

有个细节值得强调：x & (2^k - 1)和"x模2^k的非负余数"严格等价，这个结论对所有 n 位补码整数成立，包括负数，也包括最小值。你可以随手验算：8 位下-1的位模式是全 1，& 7得7，而-1模 8 的非负余数确实是7；-8的位模式低三位全 0，& 7得0，-8模 8 也确实是0。

3.2 逐位验证几个负数样例

光说结论不够直观，下面把几个典型值展开算一遍。以 8 位为例，取k = 3，掩码为7 = 00000111。

表里最后两列的分歧一目了然：位运算给出的是[0, 7]区间内的值，%给出的是(-8, 0]区间内的值。两者在-8和-128这两个恰好能被 8 整除的点上重合，因为此时余数为零，符号无从谈起——这也解释了为什么某些测试用例只覆盖了能被整除的情况，问题就被漏过去了。

3.3 编译器的强度削减与它的前提条件

现代编译器对常量取模有成熟的优化：把x % 8削减成移位加掩码的组合，甚至在模数不是 2 的幂时，用"乘以魔数再右移"的方式把除法换成乘法和移位。这套优化的正确性依赖语言标准对取模语义的规定，所以对负数也能保证结果与直接计算一致——它优化的是指令，不是语义。

这里有个容易被误传的说法：有人以为编译器会把x % 8直接优化成x & 7。这个说法只在x为非负（或类型为无符号）时成立。对有符号x，优化器必须保留"结果符号跟随被除数"的语义，所以生成的指令序列会包含额外的修正步骤，比如先做掩码，再根据符号位补一个偏移。你可以把这两种写法编译出来对比汇编，差异很明显。

注意：手工把% (2^k)改写成& (2^k - 1)是一次语义变更，不是纯粹的等价替换。只有当调用方确实需要非负余数时才能这么改。改完之后建议在代码里留一行注释说明意图，否则下一个维护的人很可能"顺手改回去"。

真正需要留意的，是另一类场景：模数不是 2 的幂，但你想用位运算加速。这时候没有通用技巧，只能通过设计来规避——比如把哈希表的容量、环形队列的长度强制设为 2 的幂。这个约束换来的是每次索引计算的常数级提速，在每秒几百万次访问的热点路径上是实打实的收益。

4. INT_MIN 踩雷合集：取负、取绝对值、取模三连

边界值这块值得单独拎出来讲，因为出问题的模式高度相似：都是"某个操作在数学上应该产生一个数，但这个数在类型范围内表示不出来"。补码的非对称性——最大值是2^(n-1)-1，最小值是-2^(n-1)，正数比负数少一个——是这一切的根源。用 32 位有符号整数来说，范围是-2147483648到2147483647，负数的绝对值上限比正数大 1。

这个不对称看起来只是个小瑕疵，但它会沿着调用链传播。取负、取绝对值、取模、比较大小，只要碰上INT_MIN，行为就可能和预期不符。更麻烦的是这里的"不符"在不同语言里表现不一样：有的直接触发未定义行为，有的安静地回绕成自己，有的抛异常。下面按我实际踩过的顺序讲。

4.1 最小负数没有对应的正数

对INT_MIN取负，数学上应该得到2147483648，但这个值超出了int的范围，最高只能到2147483647。在补码机制下，-INT_MIN的计算过程~x + 1会把位模式1000...000变成0111...111再加1，回绕成1000...000，也就是原值。所以-INT_MIN == INT_MIN，取负操作变成了一次恒等变换。

在 C/C++ 里这个行为属于有符号整数溢出，标准上定义为未定义行为，编译器有权假设它不会发生，从而做出一些看起来匪夷所思的优化。我见过的一个真实案例是某个编译器把if (-x > 0)直接优化成了恒真，理由是"如果x是负数，那么-x必然是正数"——这个推理在数学上成立，但在补码边界上不成立。这类优化导致的问题极难排查，因为源码看上去完全正常。

Java 的处理方式更"老实"：语言规范明确规定整数溢出按二进制补码回绕，-Integer.MIN_VALUE == Integer.MIN_VALUE是稳定行为，Math.abs(Integer.MIN_VALUE)返回的还是负数。这不算 bug，但如果你拿abs的结果去当数组下标，那就是 bug 了。所以在这类语言里，防御的责任完全落在开发者身上，语言不会帮你拦。

4.2 带符号溢出在语言层面的后果

不同语言对溢出的态度差异很大，值得整理成对照。C 和 C++ 把有符号溢出定为未定义行为，追求性能；Java 和 Go 规定为回绕，行为确定；Rust 在 debug 模式下 panic、release 模式回绕；Python 的整数是任意精度，压根不会溢出，但也因此慢；JavaScript 的位运算会先截断到 32 位有符号，这是个隐藏的坑。

这张表里我最想强调的是 Rust 的 debug/release 差异和 JavaScript 的隐式截断。前者意味着测试环境和生产环境的行为不一致，如果测试全部跑在 debug 模式，溢出 panic 会被当成"测试环境的严格检查"而忽略；后者意味着数学上正常的运算在位运算里会突然变形，2**31 | 0得到的是负数。

4.3 一条安全的取模辅助函数与它的性能代价

综合前面这些，我在项目里固化的做法是：凡是按下标语义使用的取模，一律走封装函数，不做裸写。核心逻辑就是先取模、判断符号、必要时补一个模数。写法看起来朴素，但它是唯一能同时覆盖正数、负数和最小值的方式——因为整个过程没有对x取负，也就绕开了最小值的雷区。

// 适用于除数 b > 0 的场景，结果落在 [0, b) static inline int floor_mod(int a, int b) { int r = a % b; // r 落在 (-b, b) return r < 0 ? r + b : r; }

对比一下几种常见写法，就能看出为什么朴素版本反而更稳。

性能上，除法指令确实是瓶颈，一次 32 位整数除法在多数架构上要几十个时钟周期。但只有在明确的性能剖析结果显示这里是热点时，才值得考虑把模数改成 2 的幂然后切到位运算。凭直觉提前优化，往往换来的是"模数必须为 2 的幂"这个约束扩散到整个模块，后续想改成动态容量就得大改。

5. 环形结构里的模运算：循环队列、时间轮、哈希环

取模运算在真实代码里的高频出没地，是各种环形结构。这类结构的共同特征是：元素个数固定，指针不断前进，走到末尾就回绕到开头。回绕这个动作，数学上就是取模。理解了补码的模空间，再看这些结构会顺畅很多，因为它们共享同一套"在有限空间里做无限推进"的思维模型。

这一节挑三个我实际写过或改过的结构来讲，重点不在数据结构本身，而在取模那几行代码的选择——用%还是用&，容量取多少，边界怎么判。这几行代码看起来简单，但我见过的环形结构 bug 九成出在这里。

5.1 循环队列容量选 2 的幂的取舍

循环队列的入队和出队都要推进尾指针和头指针，tail = (tail + 1) % cap是最直白的写法。如果cap取 2 的幂，就可以改成tail = (tail + 1) & (cap - 1)，省掉一次除法。这个优化在单线程、低延迟场景里很常见，比如日志缓冲、网络包的收发队列。

代价是容量被迫向上取整到 2 的幂。比如你实际只需要 1000 个槽位，就得分配 1024，浪费 24 个。这个浪费通常可以接受，但如果元素本身很大（比如每个槽位是一个几 KB 的结构体），浪费量就值得算一算：1024 个元素每个 4 KB，实际用 1000 个，白白占掉 96 KB。这时候可能宁可吃一次除法。

还有一个更隐蔽的取舍：容量取 2 的幂之后，"队列满"和"队列空"的判断变容易了。经典做法是空出一个槽位不用，用(tail + 1) & mask == head判断满，这样可以避免额外维护一个计数器。但如果用%写法，判满逻辑是一样的，只是多那次除法。所以真正的收益点其实在每次推进指针时的常数开销，而不是判满逻辑本身。

提示：环形队列用"空一格"判满时，实际可用容量是cap - 1。如果你按cap去算容量规划，会莫名其妙地少一个槽位。这个坑我在两个项目里都见过，第二次是别人踩的，看到那段代码时我立刻想起了第一次。

5.2 时间轮自增下标的回绕

时间轮的核心是一个不断自增的 tick，每次 tick 推进一个槽位，槽位下标是tick % wheelSize。任务按延迟时间被挂到对应的槽位上，到期时执行。这个结构里，tick通常是 64 位整数，会持续自增到溢出，而wheelSize通常取 2 的幂（比如 512 或 1024）。

这里有个容易被忽略的点：tick溢出之后，tick % wheelSize的结果仍然是正确的，因为模运算对加法的分配律——(a + 2^64) mod m = a mod m只在m整除2^64时成立。而wheelSize是 2 的幂，正好整除，所以结论成立。如果用& (wheelSize - 1)，那就更省心了，掩码只看低位，高位溢出与否根本不影响结果。

反过来说，如果wheelSize不是 2 的幂，tick溢出后下标就会错位，任务会被挂到错误的槽位上，表现为"某些定时任务偶发不执行"或"提前执行"。这种 bug 的复现周期极长（要等tick溢出，64 位下几乎不可能，但 32 位下几个小时就可能撞上），排查难度很高。所以时间轮这类长期运行的结构，容量取 2 的幂不只是为了性能，也是为了正确性。

5.3 一致性哈希环上的负值修正

一致性哈希把节点和键都映射到一个环上，通常是[0, 2^32)的整数空间。哈希函数的输出如果直接当有符号 32 位整数解释，就会出现负值，落到环上就是非法位置。第 1 节那个分片下标的 bug，本质上就是这个问题。

修正方式有两种。一种是在哈希计算完成后立刻转成无符号，把负值映射到环的另一半，代价是改变了哈希分布的连续性（但从均匀性角度看没影响）。另一种是对结果做非负化处理，(h & 0x7FFFFFFF)把符号位清零，这样得到的范围是[0, 2^31)，牺牲了一半的环空间但保留了低位分布的均匀性。两种方式各有取舍，关键是全流程保持一致——如果写入时用无符号、查询时用非负化，两边算出来的位置不同，就会查不到数据。

我在实际项目里倾向第一种：哈希函数统一返回无符号值，所有比较和取模都在无符号域里做。这样从源头上避免了符号问题，代价是代码里所有相关类型都得改成无符号，类型转换的地方要格外小心。第二种方式改动小，但"只用了半个环"这件事容易在后续扩容时被人忘记，导致新节点被映射到一个永远不会有数据的区间。

6. 跨语言对照与我在实际项目里固化的几条习惯

前面几节的东西散落在具体场景里，最后收拢一下，讲几个跨语言对照的细节和我自己已经形成肌肉记忆的做法。这些不是什么高深理论，都是从 bug 里长出来的条件反射，写代码时不太过脑子就会自动执行，但每一条背后都能对应到前面讲过的某个原理。

先说说为什么强调"跨语言"。现在一个系统里混用两三种语言太常见了，服务端用一种、脚本用一种、前端又是一种，同一套数据在不同语言里过一遍，取模语义不一致就是隐患。尤其是一些看起来"只是配置文件"的地方，其实藏着表达式求值。

6.1 Python、C 系、JavaScript 的取模结果对照

这三种语言覆盖了大部分日常场景，把它们放在一起对比最实用。核心差异还是第 1 节讲的除法规则：Python 用地板除法，C 系用截断除法，JavaScript 的%沿用了 C 的语义（截断），但它的位运算会先把操作数转成 32 位有符号整数，这是额外的坑。

JavaScript 的位运算行为值得单独说一句。2**31 | 0的结果是-2147483648，因为|会把操作数转成 32 位有符号整数再运算，2^31的位模式是1000...000，解释成有符号就是最小值。很多人在前端做位运算优化时踩过这个坑，尤其是涉及时间戳、ID 这类大数的时候。安全做法是：超过 32 位的数别碰位运算，或者使用 BigInt 并接受性能损失。

Python 这边的问题反过来：因为整数是任意精度，-7 % 2永远给1，看起来"更友好"，但一旦和 C 系的服务交互，同样的数据算出来的结果不同。我在一个混合技术栈的项目里就遇到过：Python 脚本生成的分片号是1，服务端用同样公式算出来是-1，两个结果对不上，数据被写进了错误的分片。修复方式是在接口协议里明确规定取模语义，两端都调用等价于floorMod的实现。

6.2 固化成习惯的几条规则

第一条：按下标语义取模，永远走封装函数。不管当前语言是不是给非负余数，都走同一个封装。这样做的好处是逻辑集中，将来换语言或者换实现只改一处。反例是"这个语言本来就给正数，直接写%就行"——这种想法在项目变大、加上第二门语言之后一定会失效。

第二条：涉及 2 的幂的模数，优先考虑位掩码，但要把语义想清楚。如果调用方需要的是非负余数，掩码是更好的选择；如果需要的是带符号余数（比如算两个数的差值余数），老老实实用%。这个判断要在写代码时就做完，不能等到出问题再回头改。

第三条：见到abs就想边界值。只要abs的入参可能来自外部输入或者哈希计算，就要问自己"最小值会不会进来"。如果会，就换成更安全的写法，比如先转成更宽的类型再取绝对值，或者用条件判断绕开。这条规则帮我挡掉过好几次潜在问题。

第四条：环形结构的容量优先取 2 的幂。除非元素特别大或者容量必须精确，否则取 2 的幂能让所有索引计算退化到位与。这条规则的收益是复合的——性能、正确性（溢出回绕）、代码简洁度三方面都受益。

第五条：跨语言的取模语义不一致，写进接口约定。不只是代码注释，要写进文档、写进测试用例。测试用例里至少要有三组：正数、负数、恰好整除的值。第三组最容易漏，但也最容易掩盖问题，因为余数为零时两种语义结果相同。

第六条：有符号和无符号不要混着用。这是老生常谈，但在取模场景里格外重要，因为隐式转换会把负数变成一个巨大的正数，然后取模的结果就完全跑偏了。开编译器的类型警告，别关掉。

最后分享一个我自己常用的小验证手法：拿几个边界值（0、1、-1、最小值、最大值、模数本身、模数的相反数）快速跑一遍目标表达式，对比预期结果。这个过程不超过两分钟，但能挡掉八成的符号类问题。真正难的是那些"看起来对但其实错了"的情况——比如测试时只用了正数，负数的分支从来没被执行过。

这类问题的根源，还是在于很多人把取模理解成"求余数"这个小学概念，没有意识到它在补码表示下多了一层"模空间"的含义。一旦把这个含义建立起来，符号规则、位运算等价、边界行为就都成了自然的推论，而不是需要逐条背诵的规则。这也是我写这篇的初衷——规则会忘，推导不会。