简介这是一套面向潮玩盲盒创业者和开发者的移动端盲盒商城系统源码覆盖盲盒星球、泡泡玛特抽盒机、一番赏等主流玩法可快速搭建H5、公众号及APP多端商城。资源包共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等扩展后台入口与前台H5路径在描述中均有说明支付商户可在平台设置中配置。目前已有338人学习下载适合具备一定PHP与ThinkPHP基础、希望低成本切入潮玩电商的开发者参考可借此研究盲盒抽奖、订单支付与多端适配的实现思路。1. 盲盒抽奖移动端到底在做什么从盲盒星球泡泡玛特抽盒机说起很多人第一次接触「盲盒抽奖移动端」这个词是在盲盒星球、泡泡玛特抽盒机这类产品里用户点开一个盒子付完款页面播放一段开盒动画然后弹出「隐藏款」「重复款」的结果。站在用户视角这是运气游戏站在开发者视角它其实是一套完整的商城系统——商品管理、库存扣减、订单支付、概率配置、抽奖记录、发货履约一个都不能少。标题里提到的盲盒手机站源码、潮玩盲盒系统商城、APP、公众号 H5、一番赏盲盒源码说的就是同一套业务在不同端上的落地形态。这篇文章面向的是想自己搭一套潮玩盲盒系统商城的从业者可能是接私活的独立开发者也可能是想给现有商城加抽奖模块的团队。我会把「盲盒抽奖移动端」拆成能复现的路径——数据模型怎么设计、概率怎么配、H5 和公众号怎么接、移动端性能怎么优化、哪些坑我踩过。读完你应该能判断这套方向值不值得投入以及第一步该写哪张表。2. 潮玩盲盒系统商城的核心数据模型与概率配置盲盒系统的复杂度不在页面而在「一次抽奖背后要动几张表」。如果数据模型一开始没设计好后面加一番赏、加端、加活动全是血泪经验。这一章先把地基打牢再讲概率这个最容易被做手脚也最容易被做错的地方。2.1 盲盒、系列、款式、库存四张表怎么拆常见做法是把盲盒拆成四层系列Series→ 盲盒Box→ 款式Style→ 库存Stock。系列是营销单位比如「某潮玩第一弹」盲盒是售卖单位用户买的是「一个盒子」款式是结果单位开出来是哪个库存则要区分「整盒库存」和「单款库存」因为隐藏款往往限量。-- 系列表营销维度 CREATE TABLE series ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL COMMENT 系列名如 第一弹, cover VARCHAR(255) COMMENT 封面图, status TINYINT DEFAULT 1 COMMENT 1上架 0下架 ); -- 盲盒表售卖单位 CREATE TABLE box ( id INT PRIMARY KEY AUTO_INCREMENT, series_id INT NOT NULL, name VARCHAR(64) NOT NULL, price DECIMAL(10,2) NOT NULL COMMENT 单价单位元, total_stock INT NOT NULL DEFAULT 0 COMMENT 整盒可售数量, sold INT NOT NULL DEFAULT 0 ); -- 款式表结果单位含概率权重 CREATE TABLE style ( id INT PRIMARY KEY AUTO_INCREMENT, box_id INT NOT NULL, name VARCHAR(64) NOT NULL, is_hidden TINYINT DEFAULT 0 COMMENT 是否隐藏款, weight INT NOT NULL DEFAULT 1 COMMENT 概率权重非百分比, stock INT NOT NULL DEFAULT 0 COMMENT 该款剩余库存 ); -- 抽奖记录表审计与防重 CREATE TABLE draw_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, box_id INT NOT NULL, style_id INT NOT NULL, order_no VARCHAR(64) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order (order_no) );逻辑说明style.weight用权重而不是百分比是为了避免「所有款概率加起来必须等于 100」这种硬约束——运营随时加一个隐藏款权重给 1其他款不用动。draw_record上的order_no唯一索引是关键它保证同一笔订单只能开一次盒这是防重复抽奖的最后一道防线。参数说明weight建议用整数隐藏款给 1普通款给 50200具体看运营想营造的稀缺感。total_stock和style.stock要分开维护整盒卖完不代表单款卖完反过来也一样。2.2 概率抽奖的两种实现与一番赏的差异概率抽奖有两种主流实现权重随机和库存池随机。权重随机是每次抽都按weight算理论上可以无限出隐藏款库存池随机是预先按比例把款式塞进一个池子抽一个少一个抽完即止。一番赏属于后者——它的「Last 赏」机制要求最后一个奖品有特殊归属所以必须用池子。import random def draw_by_weight(styles): 权重随机styles 为 [(style_id, weight), ...] total sum(w for _, w in styles) r random.randint(1, total) upto 0 for sid, w in styles: upto w if r upto: return sid return styles[-1][0] def draw_by_pool(pool): 库存池随机pool 为预先打散的 style_id 列表 if not pool: raise Exception(奖池已空) idx random.randint(0, len(pool) - 1) return pool.pop(idx)逻辑说明draw_by_weight每次独立计算适合普通盲盒draw_by_pool从池子里弹出适合一番赏。注意pool.pop(idx)会改变池子所以池子必须存在 Redis 或数据库里不能每次请求重新生成否则概率就失控了。参数说明权重随机的weight总和越大单次计算越慢但一般款式不超过 50 个性能无压力。库存池随机的池子大小等于该盒总库存建议用 Redis List 存储LPOP天然原子能扛住并发。提示一番赏的 Last 赏要在池子剩最后一个时触发特殊逻辑别用随机直接判断len(pool) 1。3. 公众号 H5 与 APP 双端接入登录、支付、开盒动画盲盒抽奖移动端的流量大头在公众号 H5因为分享裂变方便APP 则承担复购和高客单价用户。两端共用一套后端但登录和支付链路完全不同这是最容易翻车的地方。3.1 公众号 H5 微信登录与授权回调公众号 H5 的登录走微信网页授权。常见做法是用户点开活动页 → 跳转微信授权 → 拿到code→ 后端换openid→ 建立会话。这里有个高频坑iOS 微信 H5 公众号重复刷新原因是授权回调地址带了变化的参数导致微信认为每次都是新页面。// 前端静默授权跳转scopesnsapi_base 不弹窗 function wxLogin() { const redirect encodeURIComponent(location.href.split(#)[0]); const url https://open.weixin.qq.com/connect/oauth2/authorize?appid${APPID} redirect_uri${redirect}response_typecodescopesnsapi_basestate1#wechat_redirect; location.replace(url); } // 回调页从 URL 取 code只取一次 const code new URLSearchParams(location.search).get(code); if (code !sessionStorage.getItem(wx_code_used)) { sessionStorage.setItem(wx_code_used, 1); fetch(/api/login, { method: POST, body: JSON.stringify({ code }) }); }逻辑说明scopesnsapi_base是静默授权用户无感知适合只拿openid的场景如果要拿昵称头像才用snsapi_userinfo。sessionStorage标记防止同一code被重复提交——微信的code只能用一次重复用会报错。参数说明redirect_uri必须是公众号后台配置的域名且要encodeURIComponent。state可以带业务参数但别带会变的时间戳否则就是重复刷新的元凶。3.2 APP 端支付与 H5 支付的差异处理APP 端支付走原生 SDKH5 走 JSAPI后端要统一订单号但分开签名。常见做法是后端提供/api/pay/sign接口根据platform参数返回不同签名。def create_pay(order, platform): if platform h5: # 公众号 JSAPI需要 openid return wechat_jsapi_sign(order, order.user.openid) elif platform app: # APP 支付返回 prepay_id 给客户端调起 return wechat_app_sign(order) else: raise ValueError(不支持的平台)逻辑说明两种支付的签名算法不同JSAPI 多一个openid参数APP 支付返回的字段结构也不一样。别想着用一套签名糊弄两端微信会直接拒绝。参数说明订单号out_trade_no要全局唯一建议用「业务前缀 时间戳 随机数」。金额单位是分别传元这是新手最常犯的错。3.3 开盒动画在移动端的性能优化开盒动画是盲盒的灵魂但也是最吃性能的地方。移动端性能优化在这里的核心是别用大图序列帧用 CSS 动画或 Lottie。序列帧动辄几十张 PNG低端机直接卡死。/* 用 CSS transform 做开盒走 GPU 合成层 */ .box-lid { transition: transform 0.6s cubic-bezier(0.34, 1.56, 0.64, 1); will-change: transform; } .box-lid.open { transform: translateY(-120px) rotate(-15deg); }逻辑说明transform和opacity是唯二不触发重排的属性动画必须只用这两个。will-change: transform提前告诉浏览器提升合成层但别滥用用多了内存暴涨。参数说明动画时长 0.6s 左右体感最好缓动函数用带一点回弹的cubic-bezier比线性自然。低端机可以降级为淡入淡出。注意开盒结果要在动画开始前就从后端拿到动画只是表演。别等动画播完再请求用户会以为卡了。4. 盲盒抽奖移动端避坑排查五个真实踩坑记录这一章全是翻车现场。盲盒系统的坑集中在并发、概率、端差异上下面五条是我和同行都遇到过的按「现象 → 原因 → 解决」写。4.1 并发抽奖导致超卖隐藏款现象活动上线瞬间隐藏款库存显示 10实际卖出去 30 多个。原因抽奖逻辑是「先查库存 → 判断 → 扣减」三步非原子并发下都查到有库存。解决用 Redis 原子操作或数据库行锁。-- 扣减时带条件影响行数为 0 说明没抢到 UPDATE style SET stock stock - 1 WHERE id ? AND stock 0;逻辑说明把判断和扣减合并成一条 SQL靠数据库的行锁保证原子性。返回的影响行数是 0 就说明库存没了直接回滚订单。参数说明高并发下这条 SQL 会成为热点可以先用 RedisDECR预扣再异步落库但要做好对账。4.2 概率配置被运营改出「必出隐藏」现象运营在后台把隐藏款权重从 1 改成 100结果隐藏款泛滥。原因后台没做权重上限校验也没做变更审计。解决权重加范围限制所有变更写日志。MAX_WEIGHT 200 def update_weight(style_id, weight, operator): if weight 1 or weight MAX_WEIGHT: raise ValueError(权重超出范围) log_change(style_id, weight, operator) # 审计日志 db.update(style_id, weight)逻辑说明权重是业务红线必须有边界和留痕。operator记录是谁改的出问题能追溯。参数说明MAX_WEIGHT根据款式数量定一般不超过普通款的 2 倍否则概率失衡。4.3 iOS 微信 H5 授权后重复刷新现象iOS 上公众号 H5 授权回调后页面反复刷新安卓正常。原因iOS 微信对location.replace和 history 处理不同回调 URL 带code被反复触发。解决回调后立刻replaceState清掉 URL 参数。if (code) { history.replaceState(null, , location.pathname); // 清掉 code doLogin(code); }逻辑说明replaceState把带code的 URL 换成干净地址刷新时就不会再触发授权逻辑。参数说明location.pathname只保留路径查询参数全丢注意别把业务参数也丢了可以先存 sessionStorage。4.4 移动端音频无法播放现象开盒音效在部分移动端浏览器不响。原因移动端浏览器要求音频必须由用户手势触发自动播放被拦截。解决在用户点击「抽盒」按钮时预加载并播放。const audio new Audio(/static/open.mp3); document.getElementById(drawBtn).addEventListener(click, () { audio.play().catch(() {}); // 用户手势内播放 });逻辑说明把播放动作绑在点击事件里满足浏览器的用户手势要求。catch兜底防止报错中断流程。参数说明音频文件建议 50KB 以内格式用 mp3 兼容性最好。4.5 订单支付成功但抽奖记录没生成现象用户付了钱但没开出盒子客服炸锅。原因支付回调和抽奖逻辑没做幂等回调重试时抽奖失败。解决支付回调里只标记订单状态抽奖由独立任务消费。def on_pay_success(order_no): # 只更新状态幂等 affected db.execute( UPDATE orders SET statuspaid WHERE order_no? AND statuspending, order_no) if affected: mq.push(draw_task, {order_no: order_no}) # 异步抽奖逻辑说明支付回调和抽奖解耦回调只做状态流转抽奖走消息队列失败可重试。参数说明statuspending条件保证幂等重复回调不会重复推任务。5. 一番赏盲盒源码的进阶玩法与验证方法一番赏比普通盲盒多一层「赏位」概念每个奖品有固定赏位抽走即消失最后一个赏位有 Last 赏。做一番赏源码核心是把「池子」和「赏位」绑定并且让用户能看到实时剩余。进阶玩法是「包套」——用户一次性买下剩余所有赏位系统要能算出总价并锁定。验证方法很简单开一个测试活动用脚本模拟并发抽奖看池子是否精确抽空、Last 赏是否落在最后一个。def verify_pool(box_id, total): 验证奖池抽空后数量精确 pool redis.lrange(fpool:{box_id}, 0, -1) assert len(pool) total, f池子数量不对: {len(pool)} ! {total} # 模拟抽空 while redis.llen(fpool:{box_id}) 0: draw_by_pool_redis(box_id) assert redis.llen(fpool:{box_id}) 0 print(奖池验证通过)逻辑说明verify_pool先校验初始数量再模拟抽空最后确认归零。这是上线前必跑的脚本能提前发现池子生成逻辑的 bug。参数说明total要和后台配置的总库存一致测试环境用 100 个赏位跑生产前用真实数量再跑一次。验证项方法通过标准池子数量对比配置与 Redis完全一致抽空精度循环抽到空归零无残留Last 赏归属抽最后一个触发 Last 赏并发安全多线程抽无超卖我自己的习惯是任何概率相关的改动上线前必须跑一遍并发脚本别信「应该没问题」。盲盒系统的玄学就在概率上用户对公平的敏感度远超你的想象。希望帮到你。本文还有配套的精品资源点击获取
