简介思创抽奖小程序源码V2.1.0是专为抽奖活动设计的微信小程序开源项目适合想学习微信小程序开发、广告变现或抽奖玩法的初中级开发者。它创新性地把广告浏览与用户参与抽奖结合起来提供完整业务闭环。资源共486个文件、压缩包仅4.68MB主要包含微信小程序前端代码js、wxml、wxss、json以及php后端接口和html管理页面覆盖从界面布局、业务逻辑、数据交互到后台管理等多个技术环节。目前已吸引127人学习浏览。通过这份源码可深入学习广告SDK的接入与生命周期管理、抽奖流程与概率控制、用户及奖品数据存储等关键知识点同时项目结构清晰、文件类型多样便于直接部署和二次开发也能作为课程设计或毕业设计的参考原型。1. 思创抽奖小程序 V2.1.0 源码开源先解决随机与扣库存这两个信任问题思创抽奖小程序 V2.1.0 开源之后很多人下载源码第一件事是找转盘动画但真正在线上跑过抽奖业务的人会先找两个文件随机函数和库存扣减。抽奖小程序的核心不是好看、炫技的动效而是抽奖结果能不能被解释、奖品的总成本是否可控。V2.1.0 这版把奖品配置、中奖记录、抽奖页面放在一个完整的小程序项目里适合直接拿来做企业年会抽奖、门店营销、粉丝福利这类场景。这篇内容从源码目录怎么读开始逐步拆到概率配置、动态设置标题、接口化改造和并发验证按一条能复现的路径展开而不是停在“源码能跑”这个层面。适合已经会写基础小程序的开发者也适合刚拿到一套开源项目但不知道从哪里下手的读者。2. 从思创抽奖小程序 V2.1.0 的目录开始读谁在管奖品、谁在管随机拿到一份开源小程序源码第一个动作不应该是直接运行而是打开目录看文件分布。对思创抽奖小程序 V2.1.0 这类以微信小程序为基础的开源项目目录结构基本会遵循微信官方约定也就是 pages、utils、components 三个顶层目录。pages 放页面、utils 放工具函数、components 放可复用组件。先定位这三个目录再决定从哪个文件开始改造比一上来就逐行读代码高效得多。下面是一份常见的抽奖小程序源码目录划分V2.1.0 这类版本通常会以类似方式组织思创抽奖小程序/ ├── app.js # 小程序入口全局逻辑 ├── app.json # 页面路由、窗口配置 ├── app.wxss # 全局样式 ├── pages/ │ ├── index/ # 抽奖主页面 │ ├── records/ # 中奖记录页 │ └── admin/ # 后台配置入口二开时可删除 ├── components/ │ ├── lucky-roll/ # 转盘或九宫格组件 │ └── result-modal/ # 中奖结果弹窗 └── utils/ ├── lottery.js # 概率计算、随机索引 ├── request.js # wx.request 封装 └── format.js # 时间、金额格式化这套目录里最需要优先读的是utils/lottery.js。它的代码量通常只有几十行但决定了整个抽奖结果分布。pages/index页面会调用这个工具函数拿到奖品再交给components/lucky-roll去做动画展示。如果后续要把抽奖从纯前端改成服务端验证也只需要替换lottery.js里的实现页面和组件不需要大改。这样一个设计好的边界可以帮二开省下大量时间。2.1 pages、utils、components 三块的关键职责好用的抽奖源码会严格区分“展示”和“计算”。pages/index负责触发抽奖和展示结果components/result-modal负责弹窗utils/lottery.js负责随机结果。三者之间的调用关系应该是单向的页面调用组件页面调用工具函数组件不反向修改奖品配置。下表是 V2.1.0 这类源码中每个目录的核心职责与二开时最常改的位置目录/文件关键职责二开时最常改的位置pages/index点击抽奖、调用随机逻辑、接收结果转盘奖品位展示pages/records中奖记录列表分页、状态筛选components/lucky-roll转盘/九宫格动画奖品位数量、动画时长components/result-modal结果弹窗分享引导、中奖文案utils/lottery.js概率映射与随机索引换成服务端侧抽奖结果utils/request.js封装 wx.request增加统一鉴权和错误处理如果二开诉求是“换奖品名”只需要改配置数据不要动components/lucky-roll里的绘制逻辑。如果诉求是“Web 端和小程序一起抽奖”则需要把utils/lottery.js中的算法迁到服务端小程序端只保留结果展示。提前按这个思路拆分后面每个改动都更可控。2.2 中奖概率不是均匀随机是带权重的抽样不少人第一次读抽奖源码时去找Math.random()以为抽奖就是一个随机数。实际上抽奖小程序里更通用的是权重数组。每个奖品配置一个weight字段权重总和可以不是 100也可以是 10000。系统生成一个 0 到总权重之间的随机数再按照权重区间映射到具体奖品。这样运营调整概率时只需要改配置不需要改代码。下面是一个经典的最小权重抽奖函数也是思创抽奖小程序 V2.1.0 二次开发时最常见的替代方案// utils/lottery.js function randomPrize(prizeList) { const total prizeList.reduce((sum, p) sum p.weight, 0); let rand Math.random() * total; for (let i 0; i prizeList.length; i) { rand - prizeList[i].weight; if (rand 0) { return prizeList[i]; } } return prizeList[prizeList.length - 1]; } module.exports { randomPrize };这个函数先累加所有weight得到总权重再生成一个[0, total)区间的随机数然后用循环逐个减去每个奖品的权重。第一次让rand 0时对应的奖品就是中奖结果。参数说明上prizeList必须是数组每一项至少包含id和weight两个字段weight建议使用正整数避免浮点累计误差。最后一行return prizeList[prizeList.length - 1]是兜底理论上循环不可能走完还不返回但保留它可以确保边界异常时仍然有结果。容易踩的坑是写if (rand 0)。一旦写成小于等于权重区间会和前一个奖品重叠导致第一个奖品概率被抬高。对高价值奖品来说这种细微差异在中奖率报表里会变得很明显所以实现时要严格使用 0。用Math.random()生成的随机数是双精度浮点区间边界判断必须和“半开半闭区间”保持一致否则越界概率无法通过测试脚本发现。2.3 一等奖库存只有 1 件时奖品配置表要这样设计奖品配置表决定抽奖成本。运营改一次配置最不想做的就是重新提交一次小程序审核所以配置不能硬编码在页面里。推荐的最小结构是奖品 id、名称、库存、权重、图片、是否启用。V2.1.0 这类版本如果只有简单的本地配置二开时也要先把这份字段结构补全。下面是一份可直接用于本地 Mock 的 JSON 配置{ prizes: [ { id: 1, name: 谢谢参与, stock: 99999, weight: 7000, enabled: true }, { id: 2, name: 6.6元红包, stock: 100, weight: 2000, enabled: true }, { id: 3, name: 每日盲盒, stock: 20, weight: 900, enabled: true }, { id: 4, name: 戴森吸尘器, stock: 1, weight: 100, enabled: true } ] }这里总权重是 10000方便理解成百分比。weight只是相对大小不必强求总和固定stock表示当前可用库存。需要注意stock和weight是两套维度库存为 0 不代表不能被抽中抽中后如果发现没库存需要重新抽取或返回失败。线上实现时抽奖前一定要过滤掉stock 0的奖品否则中奖记录会里会出现“提示中奖但无货可发”的问题。enabled字段用于运营临时上下架比直接把库存改成 0 更明确。有了权重抽样函数和奖品配置表一个最基本的抽奖流程就能跑通。但从源码到上线还有一段距离下一章要解决的是如何把 V2.1.0 在开发者工具里稳定跑起来。3. 微信开发者工具跑通思创抽奖小程序 V2.1.0导入、配置与请求封装3.1 导入源码时的三个易错点把思创抽奖小程序 V2.1.0 的源码下载后用微信开发者工具导入时最容易出问题的不是代码报错而是 AppID 和基础库版本。打开开发者工具选择“小程序”项目下的“导入”然后选中包含project.config.json的源码根目录。第一次导入后开发者工具会提示项目里的 AppID 不属于当前账号这是正常的因为开源作者通常会在源码里保留自己的测试 AppID。个人开发者没有企业 AppID 时可以在导入界面选择“测试号”但要注意测试号对部分能力有限制比如wx.login换 session_key 时需要真机调试。如果想完整跑通 V2.1.0 里的用户身份流程建议先到微信公众平台注册一个个人小程序把得到的 AppID 填入project.config.json的appid字段。另一个容易忽略的是基础库版本若源码里用到wx.setNavigationBarTitle之类较老的 API基础库设置过高或过低一般问题不大但若用到云函数则必须打开“增强编译”。3.2 project.config.json 与 app.json 的最小配置说明project.config.json控制的是开发者工具行为app.json控制的是小程序运行行为。典型问题是首次导入后白屏大概率是app.json里的pages第一项不是首页路径。微信小程序以pages数组的第一项作为冷启动页面如果首页路径写错控制台不会报清晰错误只提示找不到页面。下表列出三个影响最大的配置项配置项位置作用常见坑appidproject.config.json开发者鉴权未替换时接口登录失败pages[0]app.json初始页面路径写错时启动白屏navigationBarTitleTextapp.json 的 window顶部导航标题写死之后无法运营动态配置修改app.json时要注意 JSON 文件不允许注释。V2.1.0 如果自带sitemap.json配置路径也要在项目里真实存在否则工具会在控制台给出警告。页面级配置可以覆盖全局配置比如pages/index/index.json里写自己的navigationBarTitleText它会比app.json里的全局标题优先级更高。这个机制为后文要做的动态设置标题留好了落点。3.3 让开发环境不卡域名校验并且把 wx.request 封装好调试阶段最常见的请求报错是url not in domain list。微信开发者工具默认校验合法域名但本地开发面对的是http://127.0.0.1或内网 IP无法通过校验。点击开发者工具右上角“详情”选择“本地设置”勾选“不校验合法域名、TLS 版本以及 HTTPS 证书”即可在开发阶段绕过限制。这个选项只对当前开发者工具生效真机预览和上线后仍然会拦截。为了后续二开不踩重复封装的坑可以直接把 V2.1.0 里的wx.request统一替换为 Promise 版本// utils/request.js function request(url, method, data) { return new Promise((resolve, reject) { wx.request({ url: url, method: method, data: data, header: { content-type: application/json }, success: (res) { if (res.statusCode 200 res.statusCode 300) { resolve(res.data); } else { reject(new Error(request failed: res.statusCode)); } }, fail: reject }); }); } module.exports { request };这段封装把wx.request包装成 Promiseurl是请求地址method支持GET、POSTdata会以 JSON 格式发送。success里先判断 HTTP 状态码再返回res.data。需要注意的是小程序接口返回 200 不代表业务成功业务状态码通常放在res.data.code中调用侧还需要二次判断。开发阶段先保证能收到数据再把统一错误处理加进request函数。跑通本地编译后下一步才是真正做业务层面的二次开发。下一章的六个改动点是按“从静态演示变成可运营小程序”的目标排出来的。4. 二次开发思创抽奖小程序 V2.1.0 最值得动的六个模块4.1 把写死的奖品配置改成接口下发并且保留本地缓存演示版思创抽奖小程序 V2.1.0 通常会把奖品配置直接写在utils/lottery.js或者页面data里。一旦运营要调整“谢谢参与”的权重就必须重新发布小程序这在线上是不可接受的。第二版二开最优先做的事是把奖品配置迁到服务端接口让运营通过后台改配置小程序端只负责拉取和展示。一个比较稳妥的加载方式是先用本地缓存渲染再请求接口更新。这样接口故障时页面不会白屏用户仍然能看到上一次的奖品配置。示例代码// pages/index/index.js Page({ onLoad() { const cached wx.getStorageSync(prizes_cache); if (cached) { this.setData({ prizes: cached }); } this.loadPrizes(); }, async loadPrizes() { const res await request(/api/prizes, GET); if (res.code 0) { this.setData({ prizes: res.data }); wx.setStorageSync(prizes_cache, res.data); } } });这里loadPrizes请求服务端接口res.data需要设计成和 2.3 节一样的奖品数组结构字段名保持id、name、stock、weight、enabled。接口应该是只读的不能在下发配置的同时扣减库存否则用户反复刷新页面会造成库存异常。本地缓存用wx.setStorageSync写入容量小但性能足够一次写入通常不会超过 100KB。4.2 库存扣减与并发控制的三种方案比较抽奖接口收到中奖结果后要立刻扣减奖品库存。最怕的是多个用户同时中同一件奖品前端判断stock 0后一起请求结果超卖。库存扣减必须放在后端事务里前端没有能力解决并发问题。常见的三种方案如下方案实现方式适用场景数据库条件更新UPDATE ... SET stockstock-1 WHERE id? AND stock0小型活动请求量不高Redis 原子自减DECR prize:stock:1成功后再落库中大规模抽奖云数据库事务使用_.inc(-1)和where stock 0小程序云开发免运维这里以 Redis 方案为例抽奖接口在返回中奖结果前先执行原子扣减扣减失败就说明奖品已经被抢完不再继续发放。Node.js 中使用ioredis时核心命令如下const stock await redis.decr(prize:stock:${prizeId}); if (stock 0) { await redis.incr(prize:stock:${prizeId}); return { code: 1002, msg: 奖品已售罄 }; }decr命令会把库存减 1 并返回当前值如果返回负数说明已经超卖执行一次incr回补。原子性由 Redis 单线程命令模型保证不会出现两个请求同时读到库存 1 的情况。需要注意这里只是把库存扣掉中奖记录要等后续业务落库成功后再提交如果落库失败同样要回补库存。实际项目里还要考虑 Redis 宕机时的降级通常做法是把数据库条件更新作为兜底方案。4.3 中奖记录落库幂等键防止重复抽奖每次抽奖都应该生成一条参与记录否则用户抽中奖品后无法对账。记录表需要至少包含用户 openid、活动 id、奖品 id、抽奖时间、是否中奖、唯一请求号。其中唯一请求号是防重复提交的关键前端在进入抽奖页时生成一个uuid后端收到相同request_no时直接返回上次结果不重复扣库存。MySQL 建表语句可以这样设计CREATE TABLE lottery_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_openid VARCHAR(64) NOT NULL, activity_id VARCHAR(32) NOT NULL, prize_id INT NOT NULL, is_win TINYINT NOT NULL DEFAULT 0, request_no VARCHAR(64) NOT NULL, created_at DATETIME NOT NULL, UNIQUE KEY uk_request_no (request_no) );uk_request_no是幂等键在数据库层面保证同一个请求号只能插入一次。user_openid和activity_id上建议建立联合索引运营后台最常做的查询就是“某个活动的中奖名单”。这里的is_win只能由后端在完成抽奖逻辑后写入不能信任前端传来的中奖标记。用户可以在开发者工具里改写请求参数如果接口直接使用前端传的prize_id那中奖结果就可以被伪造。4.4 小程序动态设置标题在 onShow 里修改导航栏“小程序动态设置标题”是一个非常常见的二开需求。思创抽奖小程序 V2.1.0 的应用场景可能是同一套页面承载多场活动比如国庆抽奖、年货节抽奖。这时候顶部标题应该随活动 id 变化而不是在app.json里写死。推荐在页面的onShow回调里调用wx.setNavigationBarTitlePage({ onShow() { wx.setNavigationBarTitle({ title: 思创抽奖·${this.data.activityName} }); } });使用onShow而不是onLoad是因为用户从分享卡片进入页面时onLoad只执行一次而支付成功或活动切换后页面重新展示会再次触发onShow。标题拼接时要注意最长字数限制小程序导航栏标题会被系统截断通常建议不超过 10 个字。还要检查app.json里这个页面的navigationStyle是否为默认的default。如果已经设置成custom标题是自绘的wx.setNavigationBarTitle不会生效需要在自定义组件里单独改文案。4.5 防刷与频控限制每天抽奖次数躲在弹窗后面的逻辑不能信抽奖接口对应真金白银所以防刷不能只靠前端禁用按钮、关闭弹窗。用户完全可以通过抓包绕过小程序直接请求后端接口。真正的频控要在服务端按用户维度做计数最简单的维度是 openid 活动 id每一天、每一周、每一场活动分别限制次数。一段基于 Redis 的最小频控伪代码def lottery(openid, activity_id): key flottery:{activity_id}:{openid} times redis.get(key) if times and int(times) MAX_TIMES_PER_DAY: return {code: 1001, msg: 今日次数已用完} pipe redis.pipeline() pipe.incr(key) pipe.expire(key, 86400) pipe.execute() return do_lottery(openid, activity_id)这里用redis.pipeline()把incr和expire放进同一个事务流水线避免只增加计数不设置过期时间。MAX_TIMES_PER_DAY应该是活动配置而不是硬编码默认可以设置 5 次第一版先跑出真实中奖率和调用量后再调整。除了频控还要对“连续 N 次抽到高价值奖品”做风控大多时候需要把算法和随机权重绑定比如抽到一等奖后把该用户中奖权重临时降级。4.6 给开源项目做贡献提交前先跑一次 diff如果二开中修复了边界问题比如权重区间重叠、库存超卖、动态标题失效可以把代码回馈给思创抽奖小程序 V2.1.0 的开源仓库。参与开源项目首先要读仓库里的 README 和贡献指南了解提交粒度。通常流程是先在平台上 fork 项目再在本地创建分支修改后提交并推送到 fork 仓库最后发起 Pull Request。发起 Pull Request 前执行git diff确认改动只涉及源文件和文档不要把业务环境的appid、接口密钥、内网地址带进去。如果项目有npm run lint或构建脚本要在本地跑通后再提交。开源文档贡献最容易被拒绝的就是格式混乱和大文件误提交一个只解决单个问题的小 Pull Request 比一个又改功能又改代码风格的大改动更容易被合并。5. 上线前用 Mock 与并发脚本验证思创抽奖小程序 V2.1.0 不失控5.1 用一千次蒙特卡洛模拟验证权重区间是否偏移思创抽奖小程序 V2.1.0 里前端的utils/lottery.js是纯函数非常适合用随机模拟测试。在 Node.js 中直接调用该函数跑一百万次统计每个奖品的命中次数和权重占比对比。如果偏差超过 1%说明随机算法或区间边界有问题。一个可直接运行的验证脚本// test/lottery.test.js const { randomPrize } require(../utils/lottery); const prizes [ { id: 1, name: 谢谢参与, weight: 7000 }, { id: 2, name: 6.6元红包, weight: 2000 }, { id: 3, name: 盲盒, weight: 900 }, { id: 4, name: 戴森, weight: 100 } ]; const counts {}; const total 1000000; for (let i 0; i total; i) { const hit randomPrize(prizes); counts[hit.id] (counts[hit.id] || 0) 1; } console.log(counts);运行后输出每个 id 的绝对次数再和理论值total * weight / 10000对比。这个脚本能发现 0造成的边界重叠也能发现奖品数组顺序变化后最后一次的兜底逻辑是否被错误触发。建议把这个测试放在package.json的npm test里后续任何人改动lottery.js都可以直接验证。5.2 用并发脚本模拟库存扣减验证不会超卖库存扣减的验证不能靠手工点小程序要用并发请求压后端。一个最直接的方法是让脚本同时发送 100 个请求抽同一件库存仅为 1 的奖品然后检查数据库中prize_id对应的中奖记录总数。如果记录数大于 1说明库存扣减和结果落库之间存在竞态条件。压测命令可以用ab或者 Node.js 脚本。这里用 Node.js 内置模块发起并发请求node -e Promise.all(Array.from({length: 100}, () fetch(https://api.example.com/api/lottery, {method:POST}) )).then(async res { const results await Promise.all(res.map(r r.json())); console.log(中奖数量:, results.filter(r r.data r.data.prize_id 4).length); }); 这里的并发数不是 1000 也不是 10000而是先设置成略高于热点奖品的库存量。第一轮验证只关心“奖品 id 为 4 的中奖记录数是否等于 1”如果不等于 1需要检查后端接口里是否先插记录后扣库存。观察日志时还要看 Redis 中prize:stock:4最后是否为负数如果是负数回补逻辑没有生效。5.3 最后看一份日志确认兜底分支没被触发验证的最后一步不是看单元测试覆盖而是打开服务端接口日志搜索lottery.js中的兜底返回。正常情况下权重数组里的每一项都会被随机命中兜底分支return prizeList[prizeList.length - 1]永远不应该执行。如果日志里频繁出现最后一项通常说明权重数组里出现了weight 0的奖品且排序在最后导致减值后rand始终没有小于 0。此时应该在前端过滤掉weight 0的奖品而不是依赖兜底分支。上线第一周每天看一次中奖率报表再按实际发放成本反向调整weight配置抽奖小程序才算是真正可控。本文还有配套的精品资源点击获取
思创抽奖小程序V2.1.0源码实战：随机算法与库存扣减机制解析
简介思创抽奖小程序源码V2.1.0是专为抽奖活动设计的微信小程序开源项目适合想学习微信小程序开发、广告变现或抽奖玩法的初中级开发者。它创新性地把广告浏览与用户参与抽奖结合起来提供完整业务闭环。资源共486个文件、压缩包仅4.68MB主要包含微信小程序前端代码js、wxml、wxss、json以及php后端接口和html管理页面覆盖从界面布局、业务逻辑、数据交互到后台管理等多个技术环节。目前已吸引127人学习浏览。通过这份源码可深入学习广告SDK的接入与生命周期管理、抽奖流程与概率控制、用户及奖品数据存储等关键知识点同时项目结构清晰、文件类型多样便于直接部署和二次开发也能作为课程设计或毕业设计的参考原型。1. 思创抽奖小程序 V2.1.0 源码开源先解决随机与扣库存这两个信任问题思创抽奖小程序 V2.1.0 开源之后很多人下载源码第一件事是找转盘动画但真正在线上跑过抽奖业务的人会先找两个文件随机函数和库存扣减。抽奖小程序的核心不是好看、炫技的动效而是抽奖结果能不能被解释、奖品的总成本是否可控。V2.1.0 这版把奖品配置、中奖记录、抽奖页面放在一个完整的小程序项目里适合直接拿来做企业年会抽奖、门店营销、粉丝福利这类场景。这篇内容从源码目录怎么读开始逐步拆到概率配置、动态设置标题、接口化改造和并发验证按一条能复现的路径展开而不是停在“源码能跑”这个层面。适合已经会写基础小程序的开发者也适合刚拿到一套开源项目但不知道从哪里下手的读者。2. 从思创抽奖小程序 V2.1.0 的目录开始读谁在管奖品、谁在管随机拿到一份开源小程序源码第一个动作不应该是直接运行而是打开目录看文件分布。对思创抽奖小程序 V2.1.0 这类以微信小程序为基础的开源项目目录结构基本会遵循微信官方约定也就是 pages、utils、components 三个顶层目录。pages 放页面、utils 放工具函数、components 放可复用组件。先定位这三个目录再决定从哪个文件开始改造比一上来就逐行读代码高效得多。下面是一份常见的抽奖小程序源码目录划分V2.1.0 这类版本通常会以类似方式组织思创抽奖小程序/ ├── app.js # 小程序入口全局逻辑 ├── app.json # 页面路由、窗口配置 ├── app.wxss # 全局样式 ├── pages/ │ ├── index/ # 抽奖主页面 │ ├── records/ # 中奖记录页 │ └── admin/ # 后台配置入口二开时可删除 ├── components/ │ ├── lucky-roll/ # 转盘或九宫格组件 │ └── result-modal/ # 中奖结果弹窗 └── utils/ ├── lottery.js # 概率计算、随机索引 ├── request.js # wx.request 封装 └── format.js # 时间、金额格式化这套目录里最需要优先读的是utils/lottery.js。它的代码量通常只有几十行但决定了整个抽奖结果分布。pages/index页面会调用这个工具函数拿到奖品再交给components/lucky-roll去做动画展示。如果后续要把抽奖从纯前端改成服务端验证也只需要替换lottery.js里的实现页面和组件不需要大改。这样一个设计好的边界可以帮二开省下大量时间。2.1 pages、utils、components 三块的关键职责好用的抽奖源码会严格区分“展示”和“计算”。pages/index负责触发抽奖和展示结果components/result-modal负责弹窗utils/lottery.js负责随机结果。三者之间的调用关系应该是单向的页面调用组件页面调用工具函数组件不反向修改奖品配置。下表是 V2.1.0 这类源码中每个目录的核心职责与二开时最常改的位置目录/文件关键职责二开时最常改的位置pages/index点击抽奖、调用随机逻辑、接收结果转盘奖品位展示pages/records中奖记录列表分页、状态筛选components/lucky-roll转盘/九宫格动画奖品位数量、动画时长components/result-modal结果弹窗分享引导、中奖文案utils/lottery.js概率映射与随机索引换成服务端侧抽奖结果utils/request.js封装 wx.request增加统一鉴权和错误处理如果二开诉求是“换奖品名”只需要改配置数据不要动components/lucky-roll里的绘制逻辑。如果诉求是“Web 端和小程序一起抽奖”则需要把utils/lottery.js中的算法迁到服务端小程序端只保留结果展示。提前按这个思路拆分后面每个改动都更可控。2.2 中奖概率不是均匀随机是带权重的抽样不少人第一次读抽奖源码时去找Math.random()以为抽奖就是一个随机数。实际上抽奖小程序里更通用的是权重数组。每个奖品配置一个weight字段权重总和可以不是 100也可以是 10000。系统生成一个 0 到总权重之间的随机数再按照权重区间映射到具体奖品。这样运营调整概率时只需要改配置不需要改代码。下面是一个经典的最小权重抽奖函数也是思创抽奖小程序 V2.1.0 二次开发时最常见的替代方案// utils/lottery.js function randomPrize(prizeList) { const total prizeList.reduce((sum, p) sum p.weight, 0); let rand Math.random() * total; for (let i 0; i prizeList.length; i) { rand - prizeList[i].weight; if (rand 0) { return prizeList[i]; } } return prizeList[prizeList.length - 1]; } module.exports { randomPrize };这个函数先累加所有weight得到总权重再生成一个[0, total)区间的随机数然后用循环逐个减去每个奖品的权重。第一次让rand 0时对应的奖品就是中奖结果。参数说明上prizeList必须是数组每一项至少包含id和weight两个字段weight建议使用正整数避免浮点累计误差。最后一行return prizeList[prizeList.length - 1]是兜底理论上循环不可能走完还不返回但保留它可以确保边界异常时仍然有结果。容易踩的坑是写if (rand 0)。一旦写成小于等于权重区间会和前一个奖品重叠导致第一个奖品概率被抬高。对高价值奖品来说这种细微差异在中奖率报表里会变得很明显所以实现时要严格使用 0。用Math.random()生成的随机数是双精度浮点区间边界判断必须和“半开半闭区间”保持一致否则越界概率无法通过测试脚本发现。2.3 一等奖库存只有 1 件时奖品配置表要这样设计奖品配置表决定抽奖成本。运营改一次配置最不想做的就是重新提交一次小程序审核所以配置不能硬编码在页面里。推荐的最小结构是奖品 id、名称、库存、权重、图片、是否启用。V2.1.0 这类版本如果只有简单的本地配置二开时也要先把这份字段结构补全。下面是一份可直接用于本地 Mock 的 JSON 配置{ prizes: [ { id: 1, name: 谢谢参与, stock: 99999, weight: 7000, enabled: true }, { id: 2, name: 6.6元红包, stock: 100, weight: 2000, enabled: true }, { id: 3, name: 每日盲盒, stock: 20, weight: 900, enabled: true }, { id: 4, name: 戴森吸尘器, stock: 1, weight: 100, enabled: true } ] }这里总权重是 10000方便理解成百分比。weight只是相对大小不必强求总和固定stock表示当前可用库存。需要注意stock和weight是两套维度库存为 0 不代表不能被抽中抽中后如果发现没库存需要重新抽取或返回失败。线上实现时抽奖前一定要过滤掉stock 0的奖品否则中奖记录会里会出现“提示中奖但无货可发”的问题。enabled字段用于运营临时上下架比直接把库存改成 0 更明确。有了权重抽样函数和奖品配置表一个最基本的抽奖流程就能跑通。但从源码到上线还有一段距离下一章要解决的是如何把 V2.1.0 在开发者工具里稳定跑起来。3. 微信开发者工具跑通思创抽奖小程序 V2.1.0导入、配置与请求封装3.1 导入源码时的三个易错点把思创抽奖小程序 V2.1.0 的源码下载后用微信开发者工具导入时最容易出问题的不是代码报错而是 AppID 和基础库版本。打开开发者工具选择“小程序”项目下的“导入”然后选中包含project.config.json的源码根目录。第一次导入后开发者工具会提示项目里的 AppID 不属于当前账号这是正常的因为开源作者通常会在源码里保留自己的测试 AppID。个人开发者没有企业 AppID 时可以在导入界面选择“测试号”但要注意测试号对部分能力有限制比如wx.login换 session_key 时需要真机调试。如果想完整跑通 V2.1.0 里的用户身份流程建议先到微信公众平台注册一个个人小程序把得到的 AppID 填入project.config.json的appid字段。另一个容易忽略的是基础库版本若源码里用到wx.setNavigationBarTitle之类较老的 API基础库设置过高或过低一般问题不大但若用到云函数则必须打开“增强编译”。3.2 project.config.json 与 app.json 的最小配置说明project.config.json控制的是开发者工具行为app.json控制的是小程序运行行为。典型问题是首次导入后白屏大概率是app.json里的pages第一项不是首页路径。微信小程序以pages数组的第一项作为冷启动页面如果首页路径写错控制台不会报清晰错误只提示找不到页面。下表列出三个影响最大的配置项配置项位置作用常见坑appidproject.config.json开发者鉴权未替换时接口登录失败pages[0]app.json初始页面路径写错时启动白屏navigationBarTitleTextapp.json 的 window顶部导航标题写死之后无法运营动态配置修改app.json时要注意 JSON 文件不允许注释。V2.1.0 如果自带sitemap.json配置路径也要在项目里真实存在否则工具会在控制台给出警告。页面级配置可以覆盖全局配置比如pages/index/index.json里写自己的navigationBarTitleText它会比app.json里的全局标题优先级更高。这个机制为后文要做的动态设置标题留好了落点。3.3 让开发环境不卡域名校验并且把 wx.request 封装好调试阶段最常见的请求报错是url not in domain list。微信开发者工具默认校验合法域名但本地开发面对的是http://127.0.0.1或内网 IP无法通过校验。点击开发者工具右上角“详情”选择“本地设置”勾选“不校验合法域名、TLS 版本以及 HTTPS 证书”即可在开发阶段绕过限制。这个选项只对当前开发者工具生效真机预览和上线后仍然会拦截。为了后续二开不踩重复封装的坑可以直接把 V2.1.0 里的wx.request统一替换为 Promise 版本// utils/request.js function request(url, method, data) { return new Promise((resolve, reject) { wx.request({ url: url, method: method, data: data, header: { content-type: application/json }, success: (res) { if (res.statusCode 200 res.statusCode 300) { resolve(res.data); } else { reject(new Error(request failed: res.statusCode)); } }, fail: reject }); }); } module.exports { request };这段封装把wx.request包装成 Promiseurl是请求地址method支持GET、POSTdata会以 JSON 格式发送。success里先判断 HTTP 状态码再返回res.data。需要注意的是小程序接口返回 200 不代表业务成功业务状态码通常放在res.data.code中调用侧还需要二次判断。开发阶段先保证能收到数据再把统一错误处理加进request函数。跑通本地编译后下一步才是真正做业务层面的二次开发。下一章的六个改动点是按“从静态演示变成可运营小程序”的目标排出来的。4. 二次开发思创抽奖小程序 V2.1.0 最值得动的六个模块4.1 把写死的奖品配置改成接口下发并且保留本地缓存演示版思创抽奖小程序 V2.1.0 通常会把奖品配置直接写在utils/lottery.js或者页面data里。一旦运营要调整“谢谢参与”的权重就必须重新发布小程序这在线上是不可接受的。第二版二开最优先做的事是把奖品配置迁到服务端接口让运营通过后台改配置小程序端只负责拉取和展示。一个比较稳妥的加载方式是先用本地缓存渲染再请求接口更新。这样接口故障时页面不会白屏用户仍然能看到上一次的奖品配置。示例代码// pages/index/index.js Page({ onLoad() { const cached wx.getStorageSync(prizes_cache); if (cached) { this.setData({ prizes: cached }); } this.loadPrizes(); }, async loadPrizes() { const res await request(/api/prizes, GET); if (res.code 0) { this.setData({ prizes: res.data }); wx.setStorageSync(prizes_cache, res.data); } } });这里loadPrizes请求服务端接口res.data需要设计成和 2.3 节一样的奖品数组结构字段名保持id、name、stock、weight、enabled。接口应该是只读的不能在下发配置的同时扣减库存否则用户反复刷新页面会造成库存异常。本地缓存用wx.setStorageSync写入容量小但性能足够一次写入通常不会超过 100KB。4.2 库存扣减与并发控制的三种方案比较抽奖接口收到中奖结果后要立刻扣减奖品库存。最怕的是多个用户同时中同一件奖品前端判断stock 0后一起请求结果超卖。库存扣减必须放在后端事务里前端没有能力解决并发问题。常见的三种方案如下方案实现方式适用场景数据库条件更新UPDATE ... SET stockstock-1 WHERE id? AND stock0小型活动请求量不高Redis 原子自减DECR prize:stock:1成功后再落库中大规模抽奖云数据库事务使用_.inc(-1)和where stock 0小程序云开发免运维这里以 Redis 方案为例抽奖接口在返回中奖结果前先执行原子扣减扣减失败就说明奖品已经被抢完不再继续发放。Node.js 中使用ioredis时核心命令如下const stock await redis.decr(prize:stock:${prizeId}); if (stock 0) { await redis.incr(prize:stock:${prizeId}); return { code: 1002, msg: 奖品已售罄 }; }decr命令会把库存减 1 并返回当前值如果返回负数说明已经超卖执行一次incr回补。原子性由 Redis 单线程命令模型保证不会出现两个请求同时读到库存 1 的情况。需要注意这里只是把库存扣掉中奖记录要等后续业务落库成功后再提交如果落库失败同样要回补库存。实际项目里还要考虑 Redis 宕机时的降级通常做法是把数据库条件更新作为兜底方案。4.3 中奖记录落库幂等键防止重复抽奖每次抽奖都应该生成一条参与记录否则用户抽中奖品后无法对账。记录表需要至少包含用户 openid、活动 id、奖品 id、抽奖时间、是否中奖、唯一请求号。其中唯一请求号是防重复提交的关键前端在进入抽奖页时生成一个uuid后端收到相同request_no时直接返回上次结果不重复扣库存。MySQL 建表语句可以这样设计CREATE TABLE lottery_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_openid VARCHAR(64) NOT NULL, activity_id VARCHAR(32) NOT NULL, prize_id INT NOT NULL, is_win TINYINT NOT NULL DEFAULT 0, request_no VARCHAR(64) NOT NULL, created_at DATETIME NOT NULL, UNIQUE KEY uk_request_no (request_no) );uk_request_no是幂等键在数据库层面保证同一个请求号只能插入一次。user_openid和activity_id上建议建立联合索引运营后台最常做的查询就是“某个活动的中奖名单”。这里的is_win只能由后端在完成抽奖逻辑后写入不能信任前端传来的中奖标记。用户可以在开发者工具里改写请求参数如果接口直接使用前端传的prize_id那中奖结果就可以被伪造。4.4 小程序动态设置标题在 onShow 里修改导航栏“小程序动态设置标题”是一个非常常见的二开需求。思创抽奖小程序 V2.1.0 的应用场景可能是同一套页面承载多场活动比如国庆抽奖、年货节抽奖。这时候顶部标题应该随活动 id 变化而不是在app.json里写死。推荐在页面的onShow回调里调用wx.setNavigationBarTitlePage({ onShow() { wx.setNavigationBarTitle({ title: 思创抽奖·${this.data.activityName} }); } });使用onShow而不是onLoad是因为用户从分享卡片进入页面时onLoad只执行一次而支付成功或活动切换后页面重新展示会再次触发onShow。标题拼接时要注意最长字数限制小程序导航栏标题会被系统截断通常建议不超过 10 个字。还要检查app.json里这个页面的navigationStyle是否为默认的default。如果已经设置成custom标题是自绘的wx.setNavigationBarTitle不会生效需要在自定义组件里单独改文案。4.5 防刷与频控限制每天抽奖次数躲在弹窗后面的逻辑不能信抽奖接口对应真金白银所以防刷不能只靠前端禁用按钮、关闭弹窗。用户完全可以通过抓包绕过小程序直接请求后端接口。真正的频控要在服务端按用户维度做计数最简单的维度是 openid 活动 id每一天、每一周、每一场活动分别限制次数。一段基于 Redis 的最小频控伪代码def lottery(openid, activity_id): key flottery:{activity_id}:{openid} times redis.get(key) if times and int(times) MAX_TIMES_PER_DAY: return {code: 1001, msg: 今日次数已用完} pipe redis.pipeline() pipe.incr(key) pipe.expire(key, 86400) pipe.execute() return do_lottery(openid, activity_id)这里用redis.pipeline()把incr和expire放进同一个事务流水线避免只增加计数不设置过期时间。MAX_TIMES_PER_DAY应该是活动配置而不是硬编码默认可以设置 5 次第一版先跑出真实中奖率和调用量后再调整。除了频控还要对“连续 N 次抽到高价值奖品”做风控大多时候需要把算法和随机权重绑定比如抽到一等奖后把该用户中奖权重临时降级。4.6 给开源项目做贡献提交前先跑一次 diff如果二开中修复了边界问题比如权重区间重叠、库存超卖、动态标题失效可以把代码回馈给思创抽奖小程序 V2.1.0 的开源仓库。参与开源项目首先要读仓库里的 README 和贡献指南了解提交粒度。通常流程是先在平台上 fork 项目再在本地创建分支修改后提交并推送到 fork 仓库最后发起 Pull Request。发起 Pull Request 前执行git diff确认改动只涉及源文件和文档不要把业务环境的appid、接口密钥、内网地址带进去。如果项目有npm run lint或构建脚本要在本地跑通后再提交。开源文档贡献最容易被拒绝的就是格式混乱和大文件误提交一个只解决单个问题的小 Pull Request 比一个又改功能又改代码风格的大改动更容易被合并。5. 上线前用 Mock 与并发脚本验证思创抽奖小程序 V2.1.0 不失控5.1 用一千次蒙特卡洛模拟验证权重区间是否偏移思创抽奖小程序 V2.1.0 里前端的utils/lottery.js是纯函数非常适合用随机模拟测试。在 Node.js 中直接调用该函数跑一百万次统计每个奖品的命中次数和权重占比对比。如果偏差超过 1%说明随机算法或区间边界有问题。一个可直接运行的验证脚本// test/lottery.test.js const { randomPrize } require(../utils/lottery); const prizes [ { id: 1, name: 谢谢参与, weight: 7000 }, { id: 2, name: 6.6元红包, weight: 2000 }, { id: 3, name: 盲盒, weight: 900 }, { id: 4, name: 戴森, weight: 100 } ]; const counts {}; const total 1000000; for (let i 0; i total; i) { const hit randomPrize(prizes); counts[hit.id] (counts[hit.id] || 0) 1; } console.log(counts);运行后输出每个 id 的绝对次数再和理论值total * weight / 10000对比。这个脚本能发现 0造成的边界重叠也能发现奖品数组顺序变化后最后一次的兜底逻辑是否被错误触发。建议把这个测试放在package.json的npm test里后续任何人改动lottery.js都可以直接验证。5.2 用并发脚本模拟库存扣减验证不会超卖库存扣减的验证不能靠手工点小程序要用并发请求压后端。一个最直接的方法是让脚本同时发送 100 个请求抽同一件库存仅为 1 的奖品然后检查数据库中prize_id对应的中奖记录总数。如果记录数大于 1说明库存扣减和结果落库之间存在竞态条件。压测命令可以用ab或者 Node.js 脚本。这里用 Node.js 内置模块发起并发请求node -e Promise.all(Array.from({length: 100}, () fetch(https://api.example.com/api/lottery, {method:POST}) )).then(async res { const results await Promise.all(res.map(r r.json())); console.log(中奖数量:, results.filter(r r.data r.data.prize_id 4).length); }); 这里的并发数不是 1000 也不是 10000而是先设置成略高于热点奖品的库存量。第一轮验证只关心“奖品 id 为 4 的中奖记录数是否等于 1”如果不等于 1需要检查后端接口里是否先插记录后扣库存。观察日志时还要看 Redis 中prize:stock:4最后是否为负数如果是负数回补逻辑没有生效。5.3 最后看一份日志确认兜底分支没被触发验证的最后一步不是看单元测试覆盖而是打开服务端接口日志搜索lottery.js中的兜底返回。正常情况下权重数组里的每一项都会被随机命中兜底分支return prizeList[prizeList.length - 1]永远不应该执行。如果日志里频繁出现最后一项通常说明权重数组里出现了weight 0的奖品且排序在最后导致减值后rand始终没有小于 0。此时应该在前端过滤掉weight 0的奖品而不是依赖兜底分支。上线第一周每天看一次中奖率报表再按实际发放成本反向调整weight配置抽奖小程序才算是真正可控。本文还有配套的精品资源点击获取
