BluffKing 的奖到底怎么开？会不会看人下菜？

号码由服务器生成，同一期所有人共用

TOTO 从 1 到 49 中选 6 个号码。开奖时，服务器使用操作系统提供的随机源 OsRng，抽取 7 个互不重复的号码：前 6 个作为中奖号码，第 7 个作为特别号。中奖号码排序后展示，结果保存到这一期的数据库记录。

你和朋友参与同一期，不会各自得到一套量身定制的结果。刷新页面、换设备或者晚一点进入，读取的仍然是已经保存的号码。

会不会看我买了什么，再决定让我输？

当前开奖函数接收的是游戏类型，不接收玩家身份和投注内容。账号、会员等级、金豆余额、选择的号码和过去输赢，都不是这个函数的输入。调用它的开奖流程也没有先计算“哪组号码赔得最少”，再挑选结果。

购买记录用于扣款和结算。服务器先生成本期结果，之后结算程序才读取玩家的票，计算奖金。根据这条代码路径，没有发现按身份、投注内容或历史输赢调整 TOTO 开奖结果的逻辑，也没有新手优惠概率、会员中奖加成或连输保底。

屏幕上的摇球，是结果展示动画

服务器先生成并保存号码，前端收到结果后，再逐个显示落球、音效和命中提示。屏幕中的球不会通过物理碰撞决定开奖号码。

因此，点击“跳过”只会更快显示结果，不会重新开奖。手机快慢、网络延迟和点击时机，也不会改变已经保存的号码。动画播放到一半时，结果已经确定，只是还没有全部展示。

每 5 分钟一期，开奖前 5 秒封盘

当前 TOTO 按固定时间表每 5 分钟一期，开奖前 5 秒停止接受当期新购买。服务器会检查期号、期次状态和时间，超过截止时间就拒绝购买；这不只是页面按钮变灰。

后台任务检查到期的期次，再执行开奖。多个后台实例通过数据库行锁协调，正常流程不会为已经成功保存结果的期次再次开奖。计划时间并非毫秒级保证：服务延迟或故障可能让实际开奖晚于计划。

奖金按照固定规则计算

每注基础成本为 10 金豆。单注、1 倍投注的派彩如下，金豆不是现金奖金：

这是固定派彩，不会因为当期多了几个中奖者，就让大家平分后缩水。表格是结算入账金额；计算净收益还要减去购买成本。

复式遵循同一套规则：选 7 个号码组成 7 注，选 8 个组成 28 注，选 9 个组成 84 注。系统计算其中每个 6 号码组合对应的奖金，加总后再乘投注倍数。

买更多不同组合，会增加覆盖范围；同一组号码买多倍，只会放大命中后的派彩，不会让它更容易开出来。

没有针对玩家，大奖为什么还是难中？

49 选 6 一共有 13,983,816 种组合。在均匀随机抽样的前提下，一注命中全部 6 个中奖号码的概率是约 1398 万分之一。这是第一奖组的概率，不是中任意奖项的概率。

随机不会主动照顾一个人的体验。连续没中，不代表下一期就该中了；某个号码很久没出现，也不会因此获得额外机会。冷热号和遗漏记录可以回看历史，当前开奖算法不会读取这些统计来决定下一期。

代码没有针对玩家，不等于玩家能独立证明一切

操作系统随机源、统一结果和固定派彩，是当前实现的机制。但玩家能否独立证明每期开奖没有受到干预，是另一个问题。

目前查阅的开奖实现，没有提供面向玩家的完整密码学验证流程，例如开奖前公布随机种子的承诺值、开奖后公开验证材料，让玩家独立复算并核对。

玩家可以核对自己的票、开奖结果和派彩，却无法仅凭落球动画或历史记录，证明服务器程序和数据库从未被改动。当前系统仍然需要玩家信任服务器按既定代码执行。

当前 TOTO 开奖路径没有发现看人下菜、根据投注避奖或控制个人输赢的逻辑；但目前也没有提供让玩家独立验证整个开奖过程的完整证明。公平机制做到哪里，就说明到哪里。玩家有理由知道已经具备的保障，以及它们的边界。

实现依据

本文核对了 server/src/lottery/rules.rs 的抽样与派彩、draw_loop.rs 的开奖与结算、mod.rs 的期次规则、store.rs 的购买校验，以及 client-game/src/components/games/lottery/useLotteryReveal.ts 的展示动画。各玩法机制不同，本文的 TOTO 结论不自动适用于其他游戏。

完整玩法见 TOTO 选号介绍。