最近刷到一个很有梗的标题：【4nim0sity丨99.999999999%】宰鱼了。4nim0sity 这个 ID 用数字替换字母，属于 Leet 拼写，本质就是把 Animosity 改得更有“代码味”；99.999999999% 则比标题本身更抓眼；而“宰鱼了”三个字，在玩家社区里基本可以翻译成“碾压局，轻松拿下”。
这个标题看起来就是娱乐产物，但戴着系统设计的眼镜看，它正好点中了很多开发者容易忽略的问题：当一个概率被写到 99.999999999% 的时候，代码层面到底会发生什么？玩家真的会得到近乎必然的结果吗？
我的核心判断是：接近 100% 的概率，在游戏系统中并不等于“稳妥”。它最考验的不是概率本身，而是数值精度、随机数实现、服务端判定和兜底策略。这一篇就围绕这个判断展开。
1. 为什么 99.999999999% 在代码里不是你以为的“必中”
1.1 浮点数的有效数字，存得下 11 个 9 吗？
在人类的直觉里，99.999999999% 就是“只有百亿分之一概率失败”，非常接近必然。但在计算机里，这个数字首先要被转成二进制浮点数。
Java、C++、C# 里的 double 大概有 15 到 17 位十进制有效数字，看起来存 11 个 9 没有问题。真正的问题在于十进制小数到二进制小数的转换不是一一映射。0.99999999999 在二进制里很可能是无限循环小数，double 存的是一个近似值。也就是说，你写进代码的字面量，和真正参与比较的数字，可能有 1e-15 量级的误差。
这个误差对普通概率可能无所谓。比如 0.3 和 0.30000000000000004 在业务上很难感知差异。但当一个概率已经接近 1 时，误差会被放大。结果可能是：理论上有极小概率失败，但实际永远不触发；或者反过来，玩家拿到 99.999999999% 的增益，却在一万次后遇到一次莫名其妙的失败。
如果用的是 float，问题更严重。float 大约只有 7 位十进制有效数字，0.99999999999 会被直接舍入成 1.0f。此时写if (random < 1.0f)，只要随机数不会等于 1.0，条件就永远为真，代码里的 99.999999999% 就变成了 100%。这类 bug 非常隐蔽，日常测试很难看出来，因为大部分用例根本跑不到边界。
// 错误示意：直接用浮点常量参与判断 double rate = 0.99999999999; double roll = ThreadLocalRandom.current().nextDouble(); if (roll < rate) { // 成功路径 }这段代码不一定每次都错，但在极高概率场景下，精度损失确实会被放大。不要拿业务正确性去赌浮点舍入。
1.2 用整数表达概率，先把分母固定下来
更稳妥的写法，是把概率放大成整数比例。比如把分母固定为 100000000000（1e11），那么成功概率 99.999999999% 就是分子 99999999999。随机数不再生成 [0,1) 的小数，而是生成 [0, 100000000000) 的整数，roll < 99999999999 即成功。
long total = 100000000000L; long success = 99999999999L; long roll = ThreadLocalRandom.current().nextLong(total); boolean hit = roll < success;这样每个概率档位都是精确的，不存在二进制舍入。失败概率严格等于 1 除以 100000000000，也就是 1e-11。
这里有一个更常见的工程建议：不要无脑把分母设得特别大。如果分母超过 long 的表示范围，后续的累加、保底计数、日志输出都会受影响。实际游戏项目里，万分比、百万分比通常已经足够。更重要的是策划能看懂、日志能打印、玩家能展示。精度越高，并不代表体验越好。
一点经验：看到 99.999999999% 这类数字，先别急着写代码。先判断它到底是一个展示文案，还是一个需要精确计算的概率节点。如果是后者，优先考虑整数方案。
2. 随机数并不是“每次重新 new 一个”就行
2.1 伪随机数发生器与种子
很多人在写代码时习惯new Random()，但游戏服务端并发高，如果每个请求都新建随机对象，不仅性能不好，还可能出现重复序列。更隐蔽的问题是：PRNG 是确定性的，同一个种子会产生完全相同的序列。
这本身不是错误。但如果你在生产环境用固定种子跑随机，又让客户端或日志暴露出可预测信息，玩家就有机会算出后续结果。服务端的随机数来源必须足够多样，至少不能被轻易猜到。当然，也不是每个随机事件都需要 Cryptographic Random，那样性能代价太高。要结合业务场景选型。
以 Java 为例，ThreadLocalRandom比new Random()更适合并发场景；C# 的System.Random不是线程安全的，要多线程环境时需要自己加锁或使用独立的实例。很多概率不对、重复奖励的问题，根源不是概率公式错了，而是随机数对象用错了。
2.2 客户端负责表现，服务端负责裁决
很多人低估了把概率判定放在客户端的问题。只要判定逻辑写在前端，玩家可以通过修改内存、重放请求、篡改本地数据来影响结果。正确的分层是：
- 客户端只上报“发起了一次操作”。
- 服务端生成随机数、执行判定、更新资产。
- 客户端拿到结果后播放表现。
服务端判定时，还需要处理两个工程问题：幂等和防重放。比如抽卡、开箱、强化这类接口，必须有唯一的操作 ID。服务端记录第一次结果，重复请求不能产生新结果，否则并发重试会导致“抽多次、扣一次”或“扣多次、结果一次”。
随机事件接口上线前，先做幂等测试。用一个请求 ID 连续发 10 次，看返回结果是不是同一条；再模拟断网重试，看会不会出现重复扣资产。
3. 当玩家足够多，失败就是数学上的必然
3.1 1e-11 的失败率，挡不住 10^11 次尝试
99.999999999% 的失败率是 1e-11。单看一次尝试，失败概率几乎为 0。但游戏是群体性的，一个热门玩法每天可能有千万甚至亿级随机判定。
假设每天 1 亿次判定，一年就是约 365 亿次，数量级接近 1e11。用泊松分布粗略估算，期望失败次数约为 0.365，一年内出现至少一次失败的概率大约是 30%。不需要特殊运气，只要玩家基数足够大，极端事件一定会出现。
这带来的直接结论是：代码里越是接近 100%，越需要准备好失败路径。否则当那个“极小概率”的失败真的发生时，玩家会以为游戏出了 bug，客服会收到大量反馈，而你的日志可能什么都查不到。
99.999999999% 在数学上不是“绝对不会失败”，而是在足够大的基数面前，“失败”一定会以某种形式出现。
3.2 概率显示与玩家预期管理
很多游戏不会把概率精确到小数点后十一位，而是显示成“极高”“中高”“较低”。这不仅是美术和文案问题，也是工程风险控制。
一旦玩家看到 99.999999999%，就会用“几乎必然”的预期来体验。任何一次失败都会被放大，并且极其难解释：明明写着 99.999999999%，为什么我失败了？
如果一定要提供高概率增益，可以设置一个较低的绝对失败率，同时在界面用“极高”并附上说明；或者直接在数值层用保底机制把尾部风险裁掉。让玩家面对一个极端数字，不如让玩家得到一个稳定可靠的体验。
4. 与其堆 9，不如引入保底和状态化概率
4.1 自然随机数会产生“不自然”的体验
哪怕单次概率是 99%，连续出现 10 次失败的概率也极低，但大量玩家面前，极端序列一定会出现。玩家的大脑会记住失败，忽略成功。这种体验问题很难靠提高基础概率解决，因为只要不是 100%，极端序列就存在。
常见的解法是引入状态化概率：不把每次事件当作独立随机，而是跟踪玩家的失败次数。连续失败 N 次后，直接把下一次结果置为成功。这就是“保底”。
保底机制从数学上截断了分布的尾部。长期平均概率会略高于基础概率，但玩家体感和系统稳定性都会好很多。玩家不会在连续失败时崩溃，也不会因为极端随机产生“这游戏针对我”的感觉。
4.2 工程上，保底状态需要持久化和并发控制
保底计数器不能只存在内存里。玩家掉线、合服、多节点请求都会导致状态丢失。常见做法是把计数器放在玩家数据或缓存中，并配合事务或乐观锁更新。
在分布式环境下，随机事件逻辑通常按“先锁玩家，再判断失败次数，再写结果”的顺序执行，避免并发时同一个玩家触发多次保底。
roll(playerId) { lock(playerId) failCount = load(playerId).failCount if (failCount >= pityLimit) { forceSuccess = true failCount = 0 } else { result = randomHit(rate) if (result) { failCount = 0 } else { failCount = failCount + 1 } } save(playerId, failCount) unlock(playerId) }这是一个简化模型。真实生产环境还要处理超时、分布式锁、降级和日志。保底不是一行if就能写完的，它本身就是一个小的状态机。
5. 概率系统上线前后，如何验证与排查
5.1 先在本地跑蒙特卡洛，再看线上分布
概率系统上线前，不要只测“能不能成功”。建议写一个模拟器，跑大量次数统计频率。
比如期望概率是 30%，样本 100 万次，落在 29.9% 到 30.1% 是正常范围。如果偏差超过 1%，就要回头查代码。这里可以做一个基础检查表：
| 检查项 | 常见做法 | 判断标准 |
|---|---|---|
| 概率实现 | 整数随机 | 期望频率与配置差异 < 0.1%~0.5% |
| 随机源 | 线程安全 PRNG | 高并发下不阻塞、不重复 |
| 保底状态 | 持久化存储 | 重启后计数器不丢失 |
| 接口幂等 | 请求 ID 去重 | 重复请求结果一致 |
| 线上监控 | 滚动频率统计 | 统计偏差超过阈值告警 |
这个表不需要全做到，但如果你的系统准备长期运行，至少前四项是底线。
5.2 一个可复用的排查链路
如果线上反馈“概率不对”，不要直接改概率表。按下面的顺序排查：
- 先核对配置：策划表是不是经过版本管理？线上加载的配置和仓库里是否一致？很多“概率不对”其实是配置发布顺序错了。
- 再查随机源：每个线程、进程是否使用独立随机实例？有没有在平台上设置固定种子？
- 再看数值精度：是否用了浮点比较？分母是否溢出？是不是用了 float 导致 99.999999999% 被舍入成 100%？
- 再看保底状态：玩家计数器有没有被重置？跨服、合服、数据迁移后是否丢失？
- 最后看统计：拉取最近 24 小时日志，统计所有随机结果的频率，计算置信区间。如果代码正确，即使出现极端序列，统计上也不会偏差太远。
这个排查链路几乎适用于所有随机系统。先判断是哪一层坏了，再决定改哪里，而不是怀疑随机数本身。
6. 技术人自己的“99.999999999%”不在标题里
6.1 把概率思维移用到系统可用性
99.999999999% 其实也常出现在高可用系统里，表示 11 个 9。按一年 31536000 秒计算，对应停机时间约为 0.0003 秒。这个数字大多数时候是技术夸张，真实生产环境能把 99.99% 做好已经非常不容易，因为一年只能停机约 52 分钟。
类比到游戏概率，一个极端的可用性目标和一个极端的概率数值，本质上都在控制“尾部风险”。它们都不是靠一行配置实现的，而是靠冗余、监控、演练、故障恢复和大量日志积累出来的。
如果你在真实项目里看到“99.999999999%”，第一反应应该是：这个数字从哪里来？谁来验证？失败路径预设好了吗？而不是直接写进需求文档。
6.2 不要把概率写满，把系统做稳
回到开头那个标题。4nim0sity 的“宰鱼了”是娱乐表达，没人会去考证那个 99.999999999% 是否真实。但如果是我们写的代码，就必须知道它为什么不是 100%，也要知道它在什么情况下会失败。
技术人的浪漫，不是把数字填到无限接近 1，而是看到 99.999999999% 时，脑子里自动弹出精度问题、随机源问题、幂等问题和保底问题。下次做概率系统，可以先问自己一句：这个概率如果连续跑 1 亿次，会不会出现一条我还没准备好应对的失败路径？
想清楚这个问题，再写随机数判断。
