抽奖概率引擎的核心，不是让页面“随机转一下”，而是把奖项配置、库存约束和一次抽奖请求转化为可重复审计的决策过程。前端动画只负责展示结果；真正的判奖应由服务端完成，否则用户可能通过改动请求绕过规则，或在并发时造成奖品超发。
常见实现是加权随机。为每个奖项配置权重 (w_i)，再将权重映射为选择区间：生成一个落在总权重范围内的随机值，根据它落入的累计区间确定奖项。若各奖项权重之和为 (W)，且所有奖项均可参与，则奖项 (i) 的理论概率为 (w_i/W)。实际产品还应明确“未中奖”是否作为一个结果参与抽取；否则奖项概率之和如何解释，容易与用户理解不一致。
库存会改变可抽取集合，但处理方式必须预先定义。奖品耗尽后，可以将其移出候选集合并重新分配剩余概率，也可以把对应概率转为未中奖。两种规则的用户体验和实际中奖率不同，不能只在后台写一个“库存为零自动调整”，却不说明概率如何变化。若概率随库存动态调整，还应记录每次抽奖所依据的规则版本和库存状态，便于核对结果。
并发下，概率正确并不等于发奖正确。多个请求可能同时读到同一份剩余库存，因此判定中奖后，还要以原子方式确认并扣减库存；若库存已被其他请求占用，则按事先设定的规则重新处理，而不能直接发出超额奖品。请求重试也应避免重复抽奖或重复发奖。
防刷与概率计算是相邻但不同的模块：账号次数限制、异常请求识别决定请求是否有资格进入抽奖，概率引擎决定合格请求获得什么结果。上线前应分别检查概率配置边界、奖品耗尽后的规则、并发扣库存和重复请求处理。把这些规则写清楚，才算实现了可控、可解释的概率引擎。
