一叶舟・记

限制 & 初始思路#

mc 原版的计分板，是我给自己设的限制：
运算只有 + - × ÷ % 交换 比较，没有数组、没有数据库、不能遍历、不能存历史——
换言之：你只能用上一个 UID，和几个常数，算出下一个。

那最朴素的骨架自然浮现：

1
next_uid = (current × A) % M

其中：

• M 很好定：int32 正整数上限 = $2^{31} - 1 = 2147483647$（一个质数，记作 $p$）
• 但是 A 不能随便选，选错了序列可能：
  • 很快撞车（周期短）
  • 卡在 0 不动（死循环）
  • 或者……前几百个看着“随机”，一千个后就开始跳 1,2,3……（周期性崩坏）

于是问题转为：

什么样的 A，能让这个乘法模运算是“走最长的路还不回头”的？

从“试试看”到“为什么”#

我一开始也想：要不……写个脚本枚举 A=2,3,4… 看哪个周期长？
懒是一回事，更怕的是：就算试出一个“周期够 5 万”，我也不知道它为什么好，哪天崩了也说不出原因。

得往数学深处瞄一眼 🧐

模数 $p = 2^{31} - 1$ 是一个梅森质数。
这很关键——在模质数 $p$ 下，集合 $\{1, 2, ..., p-1\}$ 对乘法构成一个循环群。
而其中，存在一些特殊的数，叫“原根”，它的一个幂次，就能跑遍整个群：

这串数，刚好是 1 到 $p-1$ 的一个排列，周期 = $p-1 = 2147483646$。

换句话说：
如果 A 是 $p$ 的原根，且初始 UID ≠ 0，
那么 next_uid = (current × A) % p 生成的序列，会在 21 亿次内绝不重复。

而实际的玩家数？满打满算不超过 5 万。相当于你有一条绕地球 50 圈的跑道，却只打算跑 1 公里，稳得一塌糊涂~

找那个“对的人”#

现在问题缩成：在 $p = 2147483647$ 下，哪个小整数是原根？

理论上，原根存在，且数量不少（约 $\phi(p-1) \approx 5 \times 10^8$ 个），但：

• 太大的数（比如 1e9 级）乘法开销高
• 太小的数（2, 3, 5）常因阶太小被排除
• 得找一个 又小、又快、又有名有姓 的

答案早已写在历史里：16807。

它等于 $7^5$，是 1988 年 Park & Miller 提出的「最小标准随机数生成器」的核心乘子 ——
一个被写进教科书、用在早期 rand() 实现中的经典选择。

验证它？只需检查对 $p-1 = 2×3^3×7×11×31×151×331$ 的每个质因子 $q$，都满足：

这个验证在 1988 年 Park & Miller 的论文中已被严格完成；现代工具（如 Python 的 sympy）甚至毫秒内就能复现。
所以说实话，我们不必每次都亲手推一遍轮子，就像没人会在调用 rand() 前先证明一遍 LCG 的周期性：有些信任，是站在巨人肩上的效率。

好看在哪？#

从 seed = 1 开始：

没有“10001, 10002”那样的工整，也没有“1, 3, 9, 27…”那样的幂次感——
它像一条看似曲折、实则永不回头的单行道。

⚠ 声明#

先说清楚：此方案安全性几乎为零，不可用于任何真实系统，现成的成熟安全方案一抓一大把。
它存在的唯一理由，是回应我当初的执念：在基岩版原版的限制下，生成一个“看起来不单调、实际上不重复”的 UID。

换句话说：

这不是一个“好”的通用 UID 方案，它只是我试了所有路之后，在原版 MC 的规则夹缝里，唯一能跑通的那条小径。

在 Minecraft 基岩版中实现#

问题来了：直接套用原公式，第 4 次就会溢出成负数（实测得到 -1199696159）。
理论上可以用拆位累加法防溢出，但太麻烦了。

于是思路一转：既然用户远不到 21 亿，何必硬扛 21 亿的模数？
→ 改用更轻量的组合，上限100w：

• $M = 1000003$（大于 10⁶ 的最小质数）
• $A = 2$（是模 1000003 的原根，周期 = 1000002，刚好覆盖需求）

推荐把初始种子（即第一个 uid 的值）设为 48573 ——
这是 2²⁰ % 1000003 的结果，能让序列从“折返点”开始，避开前面那串像 2 的幂次的单调增长，观感更好

注意

这只是核心生成逻辑；计分板创建、虚拟玩家（如 "2" 和 m）的初始化等基础步骤需自行补充。

实际只需两行命令：

1
scoreboard players operation uid uid *= "2" num
2
# 将 uid 乘以 2（即 current × A）
3
# 前提：num 计分板中，虚拟玩家 "2" 的分数为 2
4

5
scoreboard players operation uid uid %= m num
6
# 对结果取余 1000003（即 (current × A) % M）
7
# 前提：num 计分板中，虚拟玩家 m 的分数为 1000003

示 例

写在最后：为什么还值得折腾？#

你说得对——它和「自增+映射」本质差不多。
但是，当玩家看到自己 UID 是 1033006068 而不是 5，
他第一反应不是「哦，第 5 个注册」，而是：

“这数字……怎么来的？”
“用的random？怎么避免重复的？”

那一瞬的好奇，就能让我轻哼起来~

算法可以朴素，但思考不该潦草。
在限制中跳舞，在确定中造“随机”——
这大概，是我对“好看”的执念吧