前几年帮一位开发者排查一段哈希分片的下标越界代码现象很奇怪分片号偶尔会变成负数程序直接抛出数组越界异常。把日志捞出来看哈希值是负的取模运算之后的结果居然也是负的。写这段代码的人理直气壮地说负七除以二余一这不是小学数学吗。可在这门语言里-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 为代表的差异。表达式截断除法C/Java/Go地板除法Python恒等式验证-7 / 2-3-4—-7 % 2-11截断2×(-3)(-1)-7地板2×(-4)1-77 / -2-3-4—7 % -21-1截断(-2)×(-3)17地板(-2)×(-4)(-1)77 % 211同号两者一致-7 % -2-1-1同号两者一致从表里能读出两条规律。截断除法下余数的符号永远和被除数一致绝对值小于除数的绝对值地板除法下余数的符号永远和除数一致取值范围落在[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 11111111b 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。十进制值8 位补码位模式与00000111相与结果非负余数模 8C 语言%结果130000110100000101555-1111111110000011177-1-5111110110000001133-5-81111100000000000000-1281000000000000000000表里最后两列的分歧一目了然位运算给出的是[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 位有符号这是个隐藏的坑。语言/环境有符号溢出行为abs(最小值)结果典型风险C / C未定义行为未定义编译器激进优化逻辑被改Java静默回绕仍为负数下游当索引用导致越界Go静默回绕仍为负数同上Rustdebugpanicpanic开发期即可发现Rustrelease静默回绕仍为负数上线后才暴露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; }对比一下几种常见写法就能看出为什么朴素版本反而更稳。写法对INT_MIN安全额外开销备注(a % b b) % b是两次除法逻辑正确但慢a 0 ? a % b b : a % b是一次除法 分支分支可预测性尚可r 0 ? r b : r是一次除法 分支推荐语义清晰abs(a) % b否一次除法 取绝对值abs在最小值上失效a (b - 1)是一条指令仅当b是 2 的幂性能上除法指令确实是瓶颈一次 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 位有符号整数这是额外的坑。场景PythonC / Java / GoJavaScript-7 % 21-1-17 % -2-111结果符号跟随除数跟随被除数跟随被除数大整数支持任意精度取决于类型宽度安全整数上限 2^53-1位运算任意精度按位按类型宽度先截断到 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、最小值、最大值、模数本身、模数的相反数快速跑一遍目标表达式对比预期结果。这个过程不超过两分钟但能挡掉八成的符号类问题。真正难的是那些看起来对但其实错了的情况——比如测试时只用了正数负数的分支从来没被执行过。这类问题的根源还是在于很多人把取模理解成求余数这个小学概念没有意识到它在补码表示下多了一层模空间的含义。一旦把这个含义建立起来符号规则、位运算等价、边界行为就都成了自然的推论而不是需要逐条背诵的规则。这也是我写这篇的初衷——规则会忘推导不会。
