3个坑毁掉抽奖小程序，手写实现避坑指南

官方文档几千行，翻到眼花还没摸透核心逻辑，这是做抽奖小程序时最头疼的事。别被那些花里胡哨的UI组件库带偏，核心抽奖逻辑必须手写实现。

为什么？因为官方示例往往为了简化，忽略了高并发下的库存超卖、随机数均匀性、以及前端防作弊这三大致命坑。我在三个不同项目里都踩过，每次修复都耗费大量时间。今天就把这三个坑的底层逻辑、错误代码和正确写法彻底讲透，帮你一次性搞定。

坑一：并发超卖，库存瞬间变负数

现象：活动刚开始，后台显示奖品库存还有10个，但前端用户已经抽走了15个。库存直接变成-5，财务对账时发现对不上，客服接到一堆投诉。

根本原因：典型的“检查-执行”竞态条件。前端请求到达后端，后端先查库存（大于0），再执行扣减。在两个请求几乎同时到达时，都通过了“大于0”的检查，都执行了扣减，导致超卖。

错误写法：

# 错误：非原子操作
def draw_prize_wrong(prize_id):# 1. 查询库存stock = db.query(f"SELECT stock FROM prizes WHERE id = {prize_id}")# 2. 检查库存if stock > 0:# 3. 扣减库存db.execute(f"UPDATE prizes SET stock = stock - 1 WHERE id = {prize_id}")return "中奖"else:return "未中奖"

正确写法：

# 正确：原子操作 + 数据库行锁
def draw_pright(prize_id):# 1. 原子性扣减，WHERE条件确保只有库存>0时才更新affected_rows = db.execute(f"UPDATE prizes SET stock = stock - 1 WHERE id = {prize_id} AND stock > 0")# 2. 根据影响行数判断是否中奖if affected_rows == 1:return "中奖"else:return "未中奖"

复现与修复：

用JMeter模拟50个并发请求，奖品库存设为10。错误写法下，最终库存为-40，中奖记录50条。正确写法下，库存为0，中奖记录恰好10条。

规避建议：

1. 永远不要在应用层做“检查-执行”，把逻辑下沉到数据库层。
2. 使用UPDATE ... WHERE stock > 0的原子操作，依赖数据库的行锁机制。
3. 如果QPS极高，考虑引入Redis的DECR命令，但要注意Redis与MySQL的最终一致性，建议用Lua脚本保证原子性。

坑二：随机数不均匀，用户感觉被“针对”

现象：运营发现，连续10次抽奖，有8次都中了同一个低价值奖品。用户截图发朋友圈，质疑“抽奖不公平”，甚至有人用脚本验证，发现随机数分布严重偏斜。

根本原因：误用了Math.random()或random()函数。JavaScript的Math.random()是伪随机，种子固定，分布虽看似均匀，但在高并发下可能产生可预测序列。Python的random()也是伪随机，如果种子未初始化，多次运行结果相同。更严重的是，前端直接用Math.random()生成随机数，用户可轻易篡改。

错误写法：

// 错误：前端生成随机数，可被篡改
function drawPrizeWrong() {const random = Math.random();let prize;if (random < 0.01) prize = "iPhone";else if (random < 0.1) prize = "优惠券";else prize = "谢谢参与";return prize;
}

# 错误：后端使用未初始化的随机数
import randomdef draw_prize_wrong_backend():# 未设置种子，多次运行结果相同random_num = random.random()if random_num < 0.01:return "iPhone"else:return "谢谢参与"

正确写法：

# 正确：后端使用系统熵源 + 库存加权
import secretsdef draw_prize_right(prizes_config):# prizes_config: [(prize_id, weight, stock), ...]# 1. 过滤掉库存为0的奖品available_prizes = [(p_id, w) for p_id, w, s in prizes_config if s > 0]if not available_prizes:return None# 2. 使用secrets模块（密码学安全随机数）total_weight = sum(w for _, w in available_prizes)random_value = secrets.randbelow(total_weight)# 3. 根据权重区间确定中奖奖品cumulative = 0for p_id, w in available_prizes:cumulative += wif random_value < cumulative:return p_id

复现与修复：

用Python脚本模拟10万次抽奖，统计各奖品出现频率。错误写法下，某个奖品出现频率比理论值偏高3%。正确写法下，偏差小于0.1%，符合卡方检验。

规避建议：

1. 随机数必须后端生成，前端只负责展示，杜绝篡改。
2. 使用secrets模块或crypto库，而非random或Math.random()。
3. 采用加权随机而非简单概率，根据奖品库存动态调整权重，避免高库存奖品被抽干后低库存奖品概率骤变。
4. 定期做随机性检测，用卡方检验验证分布均匀性。

坑三：前端防作弊失效，脚本批量刷奖

现象：活动上线1小时，后台中奖记录暴涨10倍，全是同一IP或同一设备ID。运营紧急下线活动，损失惨重。事后分析，发现攻击者用Selenium模拟点击，绕过前端限制。

根本原因：前端验证形同虚设。常见错误包括：

1. 只在前端限制点击频率，后端无校验。
2. 使用setInterval或setTimeout限制，但攻击者可修改时间函数。
3. 未校验用户身份，同一用户可多次中奖。
4. 未记录IP、设备指纹、行为轨迹，无法识别异常。

错误写法：

// 错误：前端限制点击，可被绕过
let isDrawing = false;function drawPrizeWrong() {if (isDrawing) return;isDrawing = true;// 发送请求fetch('/api/draw').then(res => res.json()).then(data => {showResult(data);isDrawing = false;});
}

正确写法：

// 正确：前端记录行为轨迹 + 后端多因子校验
function drawPrizeRight() {// 1. 记录行为轨迹：点击时间、坐标、设备信息const trace = {click_time: Date.now(),x: event.clientX,y: event.clientY,device_id: getDeviceFingerprint(),user_agent: navigator.userAgent};// 2. 发送请求，携带轨迹信息fetch('/api/draw', {method: 'POST',headers: { 'Content-Type': 'application/json' },body: JSON.stringify(trace)}).then(res => res.json()).then(data => {showResult(data);});
}

# 后端：多因子校验
def draw_prize_right_backend(trace, user_id):# 1. 检查用户是否已中奖if db.query(f"SELECT COUNT(*) FROM wins WHERE user_id = {user_id}"):return "已中奖"# 2. 检查IP和设备频率ip = trace['ip']device_id = trace['device_id']if redis.get(f"ip_limit:{ip}") > 10:return "请求过于频繁"if redis.get(f"device_limit:{device_id}") > 5:return "设备异常"# 3. 检查行为轨迹合理性（如点击间隔）last_click_time = redis.get(f"last_click:{user_id}")if last_click_time and (trace['click_time'] - last_click_time) < 1000:return "点击过快"# 4. 执行抽奖逻辑prize_id = draw_prize_right(prizes_config)if prize_id:db.execute(f"INSERT INTO wins (user_id, prize_id, trace) VALUES ({user_id}, {prize_id}, '{trace}')")redis.setex(f"ip_limit:{ip}", 60, redis.get(f"ip_limit:{ip}") + 1)redis.setex(f"device_limit:{device_id}", 60, redis.get(f"device_limit:{device_id}") + 1)redis.setex(f"last_click:{user_id}", 60, trace['click_time'])return prize_id

复现与修复：

用Selenium脚本模拟100个用户，每个用户快速点击10次。错误写法下，1000次请求全部成功。正确写法下，仅前10次成功，后续被IP和设备频率限制拦截。

规避建议：

1. 前端只负责收集行为数据，后端负责所有校验，包括用户身份、频率、行为轨迹。
2. 使用设备指纹而非单纯IP，因为NAT环境下IP可能相同。
3. 引入滑动验证码或无感风控，对可疑请求增加验证步骤。
4. 记录完整审计日志，便于事后追溯和风控模型训练。

避坑总结与实战建议

这三个坑，本质都是把信任放错了地方。超卖坑，信任了应用层的检查；随机数坑，信任了前端的生成；防作弊坑，信任了前端的限制。

核心原则：

1. 所有关键逻辑必须在后端实现，前端只是展示层。
2. 原子性操作下沉到数据库或缓存层，避免竞态条件。
3. 多因子校验+行为轨迹，构建立体风控体系。
4. 定期压力测试，用JMeter或k6模拟高并发场景，提前暴露问题。

参考官方源码仓库中的并发控制模块，你会发现他们也是用数据库行锁和原子操作解决超卖问题，用系统熵源生成随机数，用多因子校验防作弊。这些不是花架子，是踩过无数坑后的最佳实践。

做抽奖小程序，别追求“功能齐全”，要追求“逻辑严密”。一个超卖bug，可能让品牌信誉崩塌；一个随机数漏洞，可能让用户流失殆尽。

你更常用哪种写法处理并发抽奖？是用数据库行锁还是Redis原子操作？评论区交流，分享你的实战经验。