简介：这是一套面向潮玩盲盒电商创业者的移动端商城系统源码，基于ThinkPHP框架开发，覆盖盲盒抽奖、一番赏、抽盒机等核心玩法，可同时适配H5、公众号与APP多端场景，适合具备PHP基础、希望快速搭建盲盒商城的开发者或运营团队使用。压缩包共约2000个文件，以1353个js脚本、213个html页面、137个css样式及98个json配置为主，另含8个sql数据库脚本与少量md说明文档，整体约215.93MB，前后台资源与依赖库划分清晰。部署环境为Linux7.6搭配Nginx1.18、PHP7.2与MySQL5.6，需安装fileinfo、sg11、redis等扩展，源码上传后配置运行目录、伪静态与SSL即可完成初始化，数据库连接在.env文件中调整，后台与前台入口均已预留。目前已有338人学习下载，读者可借此获得一套可直接二次开发的盲盒商城骨架，快速理解抽奖逻辑、支付接入与多端适配的实现思路。
1. 盲盒抽奖移动端系统：从一番赏到抽盒机，一套源码要解决哪些真问题
做潮玩电商的团队最近半年问得最多的一类需求，就是「盲盒抽奖移动端」怎么落地。表面看是抽奖玩法，实际拆开是一套完整的商城系统：商品池管理、概率引擎、订单与库存、支付回调、多端适配（APP、公众号 H5、小程序）、以及一番赏这种「赏品分层 + 抽完即止」的特殊玩法。标题里提到的盲盒星球、泡泡玛特、抽盒机、一番赏，本质是同一类业务的不同表现形态——用户花固定金额，换取随机商品，平台靠概率设计和库存周转赚钱。
这套系统适合谁？一是想快速搭一套潮玩盲盒商城的独立开发者或小团队，二是已有商城想加抽盒机模块的产品负责人，三是做公众号 H5 裂变活动的运营技术。它解决的核心问题不是「怎么随机」，而是「怎么让随机可控、可审计、可退款、可对账」。概率写死在代码里、库存扣减和订单不同步、支付回调重复触发——这三个坑几乎每个新手都会踩一遍。下面按「先立住原理、再动手复现、最后讲边界」的顺序，把一套可落地的盲盒抽奖移动端系统拆开讲。
2. 概率引擎与赏品分层：抽盒机的核心逻辑怎么设计
2.1 为什么不能用 Math.random 直接抽
新手最容易犯的错，是在抽奖接口里写一句Math.random()然后按区间判断。单机测试没问题，一上并发就翻车：同一秒内多个请求可能抽到同一个「隐藏款」，因为库存扣减和概率判定是两步操作，中间没有原子性保证。更麻烦的是，概率写死在代码里，运营想调一个款的出货率就得改代码重新发版，这在潮玩这种「款款不同、期期不同」的业务里完全不可接受。
正确做法是把概率配置化。每个盲盒系列对应一张「赏品配置表」，记录每个款式（或每个赏级）的权重、库存、是否隐藏款、是否保底。抽奖时先读配置，再用加权随机算法选款，最后用数据库行锁或 Redis 原子操作扣库存。这样运营在后台改权重就能实时生效，不需要动代码。
一番赏的「赏」分层更特殊：通常分 A 赏、B 赏……Last 赏，每层数量固定，抽完即止。这意味着概率不是固定的，而是随剩余库存动态变化的。比如 A 赏剩 1 个、总剩余 100 个，那当前抽中 A 赏的概率就是 1/100。这种「动态概率」必须每次抽奖前实时计算，不能缓存。
2.2 加权随机与动态概率的实现
下面是一个可复用的加权随机选款函数，支持固定权重和动态库存两种模式。用 Python 写，逻辑清晰，换成任何后端语言都一样。
import random def weighted_choice(items): """ items: [{'id': 'A', 'weight': 5, 'stock': 2}, ...] 返回被选中的 item，权重越高越容易中 如果 stock 为 0 则跳过 """ available = [it for it in items if it['stock'] > 0] if not available: return None # 全部抽完，触发兜底逻辑 total = sum(it['weight'] for it in available) r = random.uniform(0, total) upto = 0 for it in available: upto += it['weight'] if r <= upto: return it return available[-1] # 浮点误差兜底 def dynamic_choice(items): """ 一番赏模式：概率 = 当前库存 / 总剩余库存 items: [{'id': 'A', 'stock': 1}, {'id': 'B', 'stock': 99}] """ total_stock = sum(it['stock'] for it in items) if total_stock == 0: return None r = random.randint(1, total_stock) upto = 0 for it in items: upto += it['stock'] if r <= upto: return it return items[-1]weighted_choice适合固定概率的常规盲盒，dynamic_choice适合一番赏这种「抽一个少一个」的场景。两个函数都先过滤掉库存为 0 的项，避免抽到已售罄的款。注意random.uniform的浮点误差，最后要有一个兜底返回，否则极端情况下会返回 None 导致接口报错。
参数上，weight建议用整数，比如 1 到 1000，避免小数精度问题。如果运营想设置「隐藏款概率 0.5%」，就把它设成权重 5，其他款总权重 995。动态模式下不需要权重，库存本身就是概率。
2.3 库存扣减的原子性怎么保证
概率选完款只是第一步，扣库存才是真正容易出事的地方。常见做法有两种：数据库乐观锁和 Redis 原子扣减。
数据库方案用UPDATE ... WHERE stock > 0加 affected rows 判断：
UPDATE blind_box_item SET stock = stock - 1 WHERE id = ? AND stock > 0; -- 检查 affected rows 是否为 1，为 0 说明被抢完了Redis 方案用DECR或 Lua 脚本保证原子性：
-- KEYS[1] = item_stock_key -- 返回剩余库存，-1 表示库存不足 local stock = tonumber(redis.call('GET', KEYS[1]) or '0') if stock <= 0 then return -1 end redis.call('DECR', KEYS[1]) return stock - 1我一般会两者结合：Redis 做第一层拦截，扛住并发；数据库做最终一致性，异步落库。这样即使 Redis 挂了，数据库也不会超卖。注意 Redis 和数据库之间要有对账机制，否则长期运行会出现「Redis 有库存但数据库没了」的玄学问题。
提示：库存扣减和订单创建必须在同一个事务或同一个补偿链路里。先扣库存再创建订单，如果创建订单失败要回滚库存；先创建订单再扣库存，如果扣库存失败要关单。两种顺序都有坑，关键是失败路径要写全。
3. 多端适配与支付回调：APP、公众号 H5 怎么共用一套后端
3.1 一套接口适配三端的取舍
标题里提到 APP、公众号 H5、一番赏盲盒源码，实际落地时最纠结的是：要不要为每个端写一套接口？我的经验是不要。三端共用一套 RESTful 接口，差异只在登录态和支付参数上。
登录态方面，APP 用 token，公众号 H5 用微信网页授权拿到的 openid 换 session，小程序用 code 换 openid。后端统一成一个user_id，上层业务不关心端类型。支付方面，APP 走原生支付，H5 走 JSAPI，小程序走小程序支付，但订单创建、回调处理、发货逻辑完全一样。
具体做法是在请求头里带一个X-Client-Type，后端根据这个字段决定返回的支付参数格式。比如创建订单接口返回：
{ "order_id": "202501011234", "pay_params": { "type": "jsapi", "appId": "wx...", "timeStamp": "...", "nonceStr": "...", "package": "...", "signType": "RSA", "paySign": "..." } }APP 端拿到type: app的参数走原生 SDK，H5 拿到type: jsapi的参数调WeixinJSBridge。这样后端只有一套订单逻辑，前端各端自己处理支付调用。
3.2 支付回调的幂等处理
支付回调是盲盒系统最容易出事故的地方。微信和支付宝都会重复推送回调，如果每次回调都去改订单状态、扣库存、发奖品，就会重复发货。血泪经验：回调接口第一件事是查订单状态，如果已经是「已支付」就直接返回成功，不做任何业务操作。
def handle_pay_callback(order_id, transaction_id): order = db.query("SELECT status FROM orders WHERE id = %s", order_id) if order.status == 'paid': return {'code': 'SUCCESS', 'msg': 'already processed'} # 用数据库唯一索引或分布式锁保证只有一个请求能进来 with db.transaction(): db.execute( "UPDATE orders SET status = 'paid', transaction_id = %s " "WHERE id = %s AND status = 'pending'", transaction_id, order_id ) if db.affected_rows() == 0: return {'code': 'SUCCESS', 'msg': 'concurrent processed'} # 执行抽奖逻辑、扣库存、生成奖品记录 execute_lottery(order_id) return {'code': 'SUCCESS', 'msg': 'ok'}关键点是UPDATE ... WHERE status = 'pending'这个条件更新，配合 affected rows 判断，天然防并发。即使两个回调同时到达，也只有一个能改成功。另一个直接返回成功，不重复发货。
3.3 一番赏的「抽完即止」怎么和订单联动
一番赏有个特殊规则：某个赏被抽完后，整个系列可能触发「Last 赏」或者直接结束。这要求抽奖接口在扣库存后立即检查剩余总量，如果为 0 就锁定系列，后续请求直接返回「已售罄」。
实现上可以在 Redis 里维护一个系列剩余计数器，每次抽奖后DECR，减到 0 时设置一个series_closed标记。抽奖接口先检查这个标记，已关闭就直接拒绝。同时异步通知运营后台，触发补货或下架。
def draw(series_id, user_id): if redis.get(f'series_closed:{series_id}'): return {'error': '该系列已抽完'} item = dynamic_choice(get_items(series_id)) if not item: redis.set(f'series_closed:{series_id}', 1) return {'error': '该系列已抽完'} remaining = redis.decr(f'series_stock:{series_id}') if remaining <= 0: redis.set(f'series_closed:{series_id}', 1) # 继续创建订单、扣 item 库存...注意series_stock和单个 item 的库存要同步初始化，避免一个减了另一个没减导致数据不一致。我一般会在后台加一个「库存校准」按钮，运营发现数据对不上时手动触发重算。
4. 避坑与排查：盲盒抽奖系统上线后最容易翻车的 5 个点
4.1 概率配置改了但线上没生效
现象：运营在后台把某款权重从 10 改成 1，保存成功，但用户抽奖结果没变化。
原因：概率配置被缓存在本地内存或 Redis 里，后台保存只写了数据库，没有刷新缓存。或者代码里用了@lru_cache之类的进程内缓存，多实例部署时每个实例缓存不一致。
解决：配置变更后主动删除 Redis 缓存 key，或者用发布订阅通知所有实例刷新。进程内缓存要设短过期时间，比如 30 秒，不能永久缓存。更稳妥的做法是每次抽奖都从 Redis 读配置，Redis 没有再回源数据库。
4.2 支付成功但订单一直显示待支付
现象：用户明明付了钱，订单状态还是 pending，客服后台也查不到支付记录。
原因：支付回调地址配错，或者回调接口抛异常返回了非 SUCCESS，导致支付平台重试几次后放弃。也可能是回调走了内网地址，外网支付平台访问不到。
解决：回调接口一定要打日志，记录原始请求体和返回内容。先用支付平台提供的沙箱工具手动触发一次回调，确认接口能通。回调处理逻辑要尽量简单，复杂业务异步化，避免超时导致支付平台认为失败。
4.3 并发抽奖出现超卖
现象：某个限量款库存设了 10 个，结果卖出去 12 个。
原因：概率选款和库存扣减之间有时间窗口，两个请求同时选中同一款，都读到库存 1，都扣减成功。或者用了 Redis 但没做原子操作，先 GET 再 DECR。
解决：库存扣减必须用原子操作。数据库用UPDATE ... WHERE stock > 0加 affected rows 判断，Redis 用 DECR 或 Lua 脚本。不要先查再改。如果用了消息队列异步落库，要保证消息不丢且消费幂等。
4.4 一番赏剩余数量显示不对
现象：前端显示的剩余抽数比实际多，用户抽到最后发现没货了。
原因：剩余数量是前端定时轮询或 WebSocket 推送的，有延迟。或者后端计算剩余数量时用了缓存，缓存没及时更新。
解决：剩余数量这种强一致性要求高的数据，不要缓存，每次从数据库或 Redis 实时读。前端可以做乐观更新，但要以服务端返回为准。抽奖接口返回时带上最新剩余数量，前端直接覆盖本地值。
4.5 退款后奖品没回收
现象：用户申请退款成功，但之前抽到的奖品还在账户里，可以继续兑换或转卖。
原因：退款逻辑只改了订单状态，没有处理关联的奖品记录。或者奖品已经发货，无法回收。
解决：退款接口要检查订单关联的奖品状态。未发货的奖品直接作废，已发货的走退货流程。设计上建议奖品和订单强关联，退款时级联更新。如果业务允许「退款不退货」，那要在退款规则里写清楚，避免纠纷。
5. 从能跑到好用：盲盒抽奖系统的压测与概率验证技巧
一套盲盒系统上线前，我最看重的不是功能多全，而是两件事：压测能不能扛住瞬时并发，概率分布是不是真的符合配置。这两件事没做，上线就是赌运气。
压测方面，用 JMeter 或 wrk 模拟 500 并发同时抽奖，重点观察三个指标：接口 P99 延迟、库存扣减是否准确、有没有重复订单。我一般会写一个简单的压测脚本，跑完后直接查数据库对账：
# 用 wrk 压测抽奖接口，持续 30 秒，500 并发 wrk -t 10 -c 500 -d 30s --latency \ -s post.lua \ http://localhost:8080/api/lottery/drawpost.lua里带上用户 token 和系列 ID，每次请求随机换用户，模拟真实场景。跑完后执行对账 SQL：
-- 检查库存扣减总数是否等于订单总数 SELECT (SELECT SUM(initial_stock - stock) FROM blind_box_item WHERE series_id = 1) AS deducted, (SELECT COUNT(*) FROM orders WHERE series_id = 1 AND status = 'paid') AS paid_orders; -- 两个数字应该相等，不等就是有超卖或漏扣概率验证方面，写一个批量抽奖脚本，跑 10 万次，统计每个款式的实际出货比例，和配置权重对比。偏差超过 5% 就要查原因，通常是随机算法有偏或者库存过滤逻辑有问题。
from collections import Counter results = Counter() for _ in range(100000): item = weighted_choice(get_items(series_id)) results[item['id']] += 1 for item_id, count in results.items(): actual = count / 100000 expected = get_weight(item_id) / total_weight print(f"{item_id}: 实际 {actual:.4f}, 预期 {expected:.4f}, 偏差 {abs(actual-expected):.4f}")这个脚本跑一次大概几分钟，但能提前发现很多玄学问题。比如有一次我发现某个隐藏款的实际出货率是配置的 3 倍，查了半天才发现是权重配置里有个负数，导致加权计算时把其他款的概率挤掉了。这种问题不跑批量验证根本发现不了。
最后一个习惯：所有抽奖记录必须落库，包含用户 ID、系列 ID、款式 ID、抽奖时间、消耗金额、订单号。这不仅是审计需要，更是出问题时唯一的后悔药。用户投诉「我明明抽到了隐藏款」，你查记录就能自证。运营说「这个款怎么出这么多」，你拉数据就能分析。没有记录，一切都是黑匣子。
希望帮到你。
本文还有配套的精品资源，点击获取
