简介这是一套基于ThinkPHP框架开发的潮玩盲盒商城系统源码面向希望快速搭建抽盒机、H5商城或公众号端盲盒平台的开发者和商家。系统覆盖盲盒展示、在线抽奖、一番赏等常见玩法内置支付商户设置可支撑活动上线后的日常运营。资源共2000个文件压缩包约215.93MB前端与后端分离包含大量JavaScript交互逻辑、HTML页面结构、CSS样式表、JSON配置、SQL初始化数据及少量Shell部署脚本目录结构清晰便于按模块检索和二次开发。该源码已有338人浏览学习适合具备PHP、Nginx部署经验的开发者用于项目重构、功能扩展或学习商城系统分层设计。获取后可得到完整的移动端商城前端、管理后台、数据库脚本及技术文档在此基础上可灵活调整抽奖规则、商品模型与用户侧交互大幅节省从零搭建的时间。1. 盲盒抽奖移动端商城先拆清楚它值不值得部署盲盒抽奖移动端商城这几年是一类需求稳定但容易被低估的源码项目表面看是“商城 抽奖”两个模板拼在一起真正跑起来才发现盒机、奖品池、支付回调这些模块的联动复杂度不亚于普通电商。这套源码同时覆盖 APP、公众号、H5 三端六个模块齐全属于“一套后端多处复用”的典型结构。我拿到资源后在本地完整跑了一遍重点确认三件事不写业务代码能不能走通“支付到开盒”的闭环随机抽奖是否发生在服务端库存与订单是不是同一套强一致体系。尤其是第三点直接决定盒子机玩法能不能撑得住活动流量。这篇拆解围绕这三件事展开适合准备做潮玩社区、盲盒小程序或线下抽盒机 H5 端的小团队。2. 盒机、奖品池与订单闭环业务模型先立住再谈部署2.1 盒机抽奖的核心链路从“浏览格子”到“开盒中签”盲盒商城和普通电商最大的差异在于“买的时候不知道买到什么”。抽盒机本质上是一个虚拟货架货架被划分成若干格子每个格子对应一个 SKU用户在付款之前只能看到“第几号格子、款式名、价格”看不到里面具体是哪一款支付成功之后服务端才执行抽奖把格子和奖品做最终绑定。这就是这类系统最核心的“奖品后置”设计。完整交易链路可以拆成三步第一步用户在前端选一个状态为“待售”的格子并提交订单后端把格子从“待售”改成“锁定”此时不分配具体 SKU第二步用户完成公众号或 H5 内的支付支付回调到达后端订单模块把订单状态改为“已支付”同时发布一个支付成功事件第三步事件监听器调用抽奖模块抽奖模块按权重从该盒机的奖品池里抽取 SKU把结果回写到格子表和订单明细状态变成“已开盒”。格子表是整个盒机模块的基石拆源码时我把两张核心表的精简结构整理了出来CREATE TABLE box_grid ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, machine_id bigint NOT NULL COMMENT 盒机ID, grid_code varchar(16) NOT NULL COMMENT 格子编号如 A01, sku_id bigint NOT NULL DEFAULT 0 COMMENT 抽中的SKU未开盒时是0, status tinyint NOT NULL DEFAULT 0 COMMENT 0待售 1锁定 2已开盒 3已取消, version int NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, PRIMARY KEY (id), KEY idx_machine_grid (machine_id, grid_code) ) ENGINEInnoDB COMMENT盒机格子表;CREATE TABLE prize_config ( id bigint NOT NULL AUTO_INCREMENT, machine_id bigint NOT NULL COMMENT 盒机ID, sku_id bigint NOT NULL COMMENT SKU ID, weight int NOT NULL DEFAULT 100 COMMENT 抽奖权重权重越大越容易中, is_hidden tinyint NOT NULL DEFAULT 0 COMMENT 是否隐藏款, PRIMARY KEY (id) ) ENGINEInnoDB COMMENT盒机奖品概率配置表;两张表有三个关键设计点。box_grid里的version字段是乐观锁用来解决两个用户同一毫秒点击同一个格子的并发问题prize_config用weight权重而不是百分数运营想调整某个款式的中奖率不需要重新算整套百分比只改权重值就行is_hidden标记把普通款和隐藏款区分开抽奖逻辑只对隐藏款做概率控制不单独维护隐藏款库存。抽奖核心代码在服务端的调用逻辑是这样的public DrawResult draw(Long machineId, Long gridId) { // 1. 乐观锁锁定格子影响行数为0说明已被别人锁定或已经开盒 int locked boxGridMapper.lockGrid(gridId); if (locked 0) { throw new BizException(grid already locked or opened); } // 2. 从缓存读取本盒机的奖品权重配置缓存失效时回源数据库 ListPrizeConfig configs prizeConfigService.listConfigs(machineId); int totalWeight configs.stream().mapToInt(PrizeConfig::getWeight).sum(); int randomValue ThreadLocalRandom.current().nextInt(totalWeight); // 3. 按权重命中一个SKU这里刻意不用Math.random()并发场景下伪随机分布容易偏移 PrizeConfig hit null; int cursor 0; for (PrizeConfig config : configs) { cursor config.getWeight(); if (randomValue cursor) { hit config; break; } } // 4. 回写格子、记录中奖明细、扣减奖品库存 // ...省略事务边界与事件发布代码 }这里有两个参数值得细看。weight总和决定概率分布假设总权重 1000、隐藏款权重设为 1隐藏款命中率就是千分之一ThreadLocalRandom在高并发短时抽奖场景下比Math.random()更合适JDK 文档明确建议并发场景优先选它。还有一个容易忽略的边界抽奖必须放在支付成功且订单落库之后不能放在用户点击按钮的普通请求里否则前端重放请求很可能在未支付的情况下触发抽奖。2.2 六大模块边界商城、盒机、订单、支付、会员、营销各管什么源码包把整个业务拆成了六个模块。我部署前先按模块职责做了一次边界梳理整理成下面这张表模块核心职责关键接口或入口最容易越界的点商城商品浏览、分类、购物车、结算/api/product/list、/api/cart/add把开盒抽奖塞进商品结算里盒机盒机列表、格子展示、抽奖/api/box/machine/list、/api/box/draw格子状态直接用订单状态代替订单订单创建、状态流转、取消退款/api/order/create、/api/order/status把抽奖结果写进订单创建阶段支付支付下单调起、回调验签、结果入库/api/pay/notify在回调里直接调抽奖接口会员会员等级、积分、成长值/api/member/info抽奖概率随会员等级动态修改营销优惠券、满减、端盒活动、一番赏/api/coupon/receive、/api/activity/end-box营销并发和抽奖并发共用一把锁这个边界划分不是拍脑袋它对应盒机业务的两条铁律。第一抽奖逻辑不能挂在订单模块里。开盒虽然总是发生在支付成功之后但它有独立的状态和重试逻辑一旦和订单混在同一个事务里任何一次网络超时都会让整个订单回滚用户付了钱却拿不到结果。第二支付模块只做通知接收和结果入库不参与业务规则。回调到达时往支付结果表写一条记录、更新订单状态再发布一个“支付成功”事件由事件监听器去触发抽奖和发货。这套事件驱动写法保证了支付回调不会因为抽奖超时而被迫重试。这套源码里还有一个“一番赏”玩法和普通盒机不太一样。普通盒机每个格子独立抽奖“一番赏”是一套固定奖品清单配固定格子数抽完即止最后一位抽取者能拿到“最终赏”。这个玩法的并发控制靠的是批次号原子更新而不是格子乐观锁营销模块里单独维护了一张lottery_batch表字段和box_grid几乎相同但多了批次状态。把这两种玩法分表而不是共用一张盒子表我认为是合理的因为“一番赏”的结束条件是批次清空普通盒机没有这个生命周期。六个模块共享同一个 MySQL 和 Redis 连接池单体应用内部通过 service 层互相调用不走微服务那套 RPC。这样做的直接收益是部署成本很低、排查问题链路短但代价是模块边界依赖人的自觉。后面避坑章节里提到的“端盒活动重复发奖”根源就是营销模块直接调了盒机模块的 mapper穿透了边界。2.3 技术选型为什么这个栈适合小团队快速上线这套系统的技术栈整体是“Java Spring Boot 2.x MyBatis Plus MySQL 8 Redis前端 Vue2 uni-app管理后台 Vue Element UI”。没有上微服务没有引入消息队列中间件服务端事务靠数据库本地事务异步任务用 Spring 自带线程池。选择这个组合的理由要放在业务场景里看。盲盒商城第一个版本通常只有一个核心诉求验证“多少人愿意为抽盒机付第一次钱”。这个阶段技术团队大概率只有两三个人要的是“一次部署、快速迭代、半夜不会被事务问题叫醒”。Spring Boot 单体把控制层、业务层、持久层全部收在一个进程里出现问题时调用链在日志里一眼能看到头MyBatis Plus 把格子表、订单表、配置表这种强规范表的 CRUD 重复代码省掉一大半Redis 在这里只干两件事存盒机概率配置缓存、存支付回调幂等键没有引入复杂缓存一致性场景。我也对比过用 Python FastAPI 或 PHP 重写这套业务的公司最后发现核心卡点不在语言而在生态。公众号、H5、支付三端都需要官方 SDK 和成熟的回调处理范例Java 的 Spring Boot 在这类“支付 状态机 异步事件”场景下有大量公开的踩坑记录搜索时很快能找到答案。这套源码默认栈比我预期保守但保守正是商城项目最需要的品质。3. 部署与联调三天内从压缩包到可跑通的商城3.1 环境准备JDK、MySQL、Redis 的最小配置清单按源码包的安装说明依赖是 JDK 8 及以上、MySQL 8 以上、Redis 5 以上。我部署时没图省事用一键脚本直接在 Ubuntu 上手动装了三件套目的是复现一台最低配服务器的真实运行环境。MySQL 有两个配置必须提前改一个是字符集另一个是时区。源码里数据库连接串默认带serverTimezoneAsia/Shanghai如果 MySQL 时区不是东八区支付回调里的时间字段插入时会整体偏移八个钟头。字符集必须显式指定utf8mb4我遇到过因为 MySQL 默认字符集是utf8mb3导致格子编号和商品名里的特殊字符在写入时直接变成问号。这两条配置改错后面联调时会非常隐蔽地翻车日志里看不出任何异常就是数据和回调时间对不上。Redis 不需要额外配置但要注意密码和端口。源码默认 Redis 没设密码部署到公网服务器时必须设置requirepass否则公网 Redis 默认端口会被扫描脚本爆破。这是比较靠前的血泪教训不是危言耸听。准备完成后建库、导入初始化数据mysql -uroot -p CREATE DATABASE box_mall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; exit mysql -uroot -p box_mall ./sql/init.sqlsql/init.sql在源码包的docs/sql目录下包含建表语句、基础菜单数据、盒机样例数据和一条默认公众号菜单配置。没有这些种子数据H5 首页打开后就是空的看不到盒机列表和 Demo 商品所以这一步不要跳过。提示第一次部署建议把微信支付参数和公众号参数全部留空先跑通本地接口再填真实密钥否则支付失败和业务错误会搅在一起排查成本翻倍。3.2 后端启动从数据库初始化到首个接口验证后端配置集中在application.yml部署时需要改四处数据源 URL、Redis 连接、支付参数、公众号参数。最小可跑配置如下server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/box_mall?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 password: your_redis_password database: 0这里机器地址里的characterEncodingutf8是连接层字符集和数据库建库时指定的utf8mb4是两层配置缺一不可。改好后直接打包启动mvn clean package -DskipTests java -jar target/box-mall-server.jar --spring.profiles.activeprod启动日志里看到Started Application in xxx seconds后先用最基础的接口验证服务是否活着curl http://localhost:8080/api/box/machine/list正常情况下返回 JSON 数组里面至少有一条machineId和machineName。如果返回 500看日志第一行报的是数据库连接错误还是 Redis 连接错误两种错在堆栈顶部就能区分开。这一步通过之后再往下联调前端不然前端一堆网络请求报错根本分不清是后端挂了还是跨域问题。3.3 前端H5公众号构建域名、路径与打包参数前端工程分两个目录app-h5是 H5 和公众号端app-admin是管理后台。H5 端基于 uni-app 框架技术栈是 Vue2 语法加小程序兼容层构建前要改两处接口基础路径和公众号支付参数。先打开app-h5/src/config.js找到baseUrl配置export default { // 本地联调指向本机后端部署时改成线上域名 baseUrl: http://localhost:8080, // 支付回调域名公众号网页授权和支付共用这个主域 payNotifyUrl: https://api.你的主域名.com/api/pay/notify, appId: wx66xxxxxxxxxxxxxxxx, }baseUrl在本地联调时可以直接用 IP 加端口但公众号里必须改成 H5 实际访问域名。构建命令分两套# 本地联调热更新 npm install npm run serve # 生产环境构建 npm run build:prodbuild:prod的输出目录是dist整个目录上传到 Nginx 的 web 根目录。Nginx 需要配两条规则所有/api/路径反向代理到后端 8080 端口其他路径直接指向dist静态文件。如果漏配/api代理H5 页面能打开但所有请求都是 404报错特征很典型。公众号访问路径有讲究微信网页授权回调地址必须和公众号后台配置的网页授权域名保持同一层级。我踩过这个坑公众号后台配的是https://yourdomain.com/源码里回调 URL 写的是https://yourdomain.com/h5/微信直接报redirect_uri 参数错误。解决方法是把公众号回调地址配成https://yourdomain.com/h5/同时将 H5 的baseUrl改成/api相对路径让前端所有请求走同域代理从根上避开跨域。4. 避坑实录支付回调、库存并发、授权回环、端盒重复发奖的四个坑4.1 支付回调丢单——上线第一周收到的用户投诉全在这现象用户在公众号里支付成功后订单仍然是待支付状态自动发货和开盒事件都没有触发。后台日志里能看到支付平台多次发起回调但业务侧始终没有反应。原因后端验签通过后又做了一层“金额严格相等”校验。回调报文里的金额单位是“分”订单表里存的是“元”代码直接拿两者比较结果永远不相等于是被当成非法通知丢弃。这个问题在跨端复制代码时特别容易传播不少开源项目的示例代码都带着这个毛病。解决把订单状态作为判断主键金额校验降级为告警逻辑。回调进来先查订单号如果订单已经是“已支付”状态就直接返回成功否则验签通过后更新订单状态、触发开盒事件。金额不一致时只记录 warning 日志不要阻断主流程。支付回调的幂等性一定要靠订单号而不是靠金额这是支付类项目的通行写法。4.2 格子锁不够硬——抢盒活动一上就并发翻车现象活动场次开放瞬间大量用户同时点同一个格子后端出现“同一个格子被两次抽奖成功”的错误订单表里同一个格子出现两条明细。原因格子锁用的是“查询状态为待售 → 程序判断可售 → 更新状态为锁定”三步逻辑。第一步和第三步之间存在时间窗两个并发请求都能读到“待售”状态于是双双进入锁定流程。解决改成一条 SQL 原子更新用影响行数判断是否抢到Update(UPDATE box_grid SET status 1, version version 1 WHERE id #{gridId} AND status 0) int lockGrid(Long gridId);关键点在WHERE status 0。这条 SQL 把“判断状态”和“更新状态”合并成一个原子操作同一时刻同一个格子只可能有一个请求的影响行数为 1其他请求全部返回 0。改成这种写法后抢盒活动再也没出现过重复开盒。注意这里不能再回退到“先查后改”的写法哪怕加事务也救不了因为 MySQL 默认隔离级别下两个查询都能读到旧状态。4.3 公众号授权回环跳转——打开菜单就像鬼打墙现象在公众号菜单里点进 H5页面先跳去微信授权登录回跳后又回到菜单首页反复循环永远进不去真正的商城页面。原因公众号网页授权和 H5 页面用的是两套域名或域名层级不一致。公众号后台配置的是yourdomain.com但源码里 H5 回调地址带了www.yourdomain.com微信授权回跳时域名不匹配被判定为非法请求。另一个隐蔽原因是授权回调后登录态判断依赖 Redis 里的 session但没有和微信公众号的 openId 做关联登录态丢失后只能重走授权。解决第一把公众号后台网页授权域名配置成当前 H5 实际访问域名带不带www要全局统一第二检查源码里获取用户信息接口返回后是否把openId写入 session 并同步更新用户表。顺手把授权失败时的回退路径从首页改成/login页面至少能暴露真实错误而不是循环刷新。这个问题的排查经验是先看公众号后台配置再看 H5 的回调拼参最后看 session 存储顺序不能乱。4.4 端盒活动重复发奖——异步任务缺了一个幂等键现象运营配置了一次“端盒必得隐藏款”的促销用户购买一整套格子后订单详情里部分格子重复发放了两次奖品库存被扣两次。原因端盒活动的开奖逻辑在 service 层循环调用单盒开奖接口整个过程放在异步线程池里。网络抖动导致前端或回调重试时整个批次被重新执行了一遍而单盒开奖接口没有按批次做幂等控制。解决开盒接口增加幂等参数以“订单号 格子编号”作为唯一键在 Redis 中用setIfAbsent设置过期标记已存在的直接返回上次结果String idempotentKey orderId : gridId; Boolean first redisTemplate.opsForValue().setIfAbsent( idempotentKey, 1, Duration.ofSeconds(30)); if (Boolean.FALSE.equals(first)) { return queryAlreadyOpenedResult(orderId, gridId); }参数说明超时时间 30 秒是整个开盒事件的保护期正常开盒是毫秒级返回30 秒足够覆盖极端慢的事务幂等键范围是“订单 格子”而不是“用户 格子”这样同一个用户换个订单买同一个格子不会被误判成重复开盒。这个问题的教训是深刻的凡是循环调用带副作用接口的逻辑必须给每一个子调用加上幂等键而不是只锁外层方法。5. 进阶用支付沙箱把“回调 → 开盒 → 库存核对”跑成自动化支付回调是整套盲盒商城最难的本地验证环节生产环境里用户付了款你不可能让用户在测试流程里反复试错。用沙箱环境把回调链路完整模拟一遍是最省事的验证手段而且不写业务代码就能覆盖支付回调、格子锁定、奖项回写、库存扣减四个关键点。沙箱的模拟思路很简单后端拿到沙箱参数后正常发起下单、正常对接收到的支付通知但通知来源从真实支付服务器换成你本地模拟脚本。源码包里没有现成的模拟工具我在项目根目录放了一个scripts/mock_pay_callback.py核心就一件事向回调接口发送一笔构造好的支付成功通知。调用方式如下python3 scripts/mock_pay_callback.py \ --order-no20241012001 \ --amount59.0 \ --notify-urlhttp://localhost:8080/api/pay/notify每次验证我都会把四步完整跑一遍先在 H5 端下单并记录订单号再运行脚本模拟支付回调等待两到三秒后查询订单状态和开盒结果最后查数据库确认格子状态、奖品明细、库存表三处数据对得上。脚本有两个参数需要按项目实际情况调--notify-url必须和后端配置的支付回调地址保持一致--amount单位是元后端回调验签逻辑里换算成分时会决定签名校验是否通过。沙箱环境通常没有真实签名但有些沙箱平台不校验签名脚本里要预留一个开关生产环境做真实回调自测时把开关打开强制走一遍完整验签流程。建议把“跑沙箱模拟回调”当成每次部署前的一个固定动作而不是出了问题才想起来做。从那以后我只要是拿到带支付逻辑的项目源码第一件事就是搭沙箱、改配置、跑一遍模拟回调。整套流程通常控制在十五分钟以内却能提前看出支付回调丢单、格子锁失效、幂等键缺失、库存扣减对不上这五六个最头疼的问题。希望帮到你。本文还有配套的精品资源点击获取