简介：一套微信口红机H5在线游戏源码，专为H5游戏运营者、独立开发者与中小团队站长设计，无需接入公众号即可完整部署，适用于门店活动、品牌推广、粉丝互动等场景。压缩包共4955个文件、约183MB，以jpg（1593个）、png（718个）图片素材、php（1265个）后端业务逻辑、html（574个）静态页面、js（288个）前端交互、css（131个）样式为核心，同时配套svg图标、gif动图、ttf/woff字体、mp3音效等资源，目录按功能模块划分，主题界面、接口、数据库与配置文件均可快速定位。包含数据库导入文件、后台管理入口及默认管理员账号，可自行调整活动奖品、抽奖概率和界面文案，还可替换图片素材与音效，快速生成不同主题版本。部署教程明确说明SG11扩展安装、数据库连接与缓存清理步骤，能帮助新手规避环境配置类典型报错。已有124人学习下载，适合需要快速搭建可运营H5游戏并进行二次开发的读者。
1. 微信口红机H5在线游戏源码：一个链接就能开局的抽奖生意
朋友圈里常见的口红机，很多时候不是线下那台机器，而是一个直接甩进微信群和朋友圈的H5链接：点进来是一排整整齐齐的口红格子，用户选中、支付或完成分享任务，后端按权重抽奖，中了填地址等发货，“谢谢参与”则发一张优惠券。做这样一套微信口红机H5在线游戏源码，难点不在前端动效，而在“无需公众号也能跑”的部署路径——公众号网页授权和JS-SDK只有认证服务号能用，但纯H5放在自己的域名上，同样能在微信内置浏览器里正常打开、正常玩。支付和分享的弯绕明白，这条路就通。本文适合美妆商家、做活动运营的产品，以及买源码后想二次开发的个人开发者，按步骤走，慢则一天跑通。
2. 口红机H5的三层骨架：为什么概率必须控制在服务端
先给一个反直觉的结论：你在手机上看到的口红机页面，前后端加起来往往不到一千行代码，真正决定这个项目能不能长跑的，是服务端那套概率、库存和订单的状态机。很多买来的源码喜欢把“剩余库存”“中奖结果”直接写在浏览器里，用户用一遍就能抓到接口返回值，甚至把中奖函数从控制台里调出来自己玩，这种盘子上线第二天就得关。所以我每次评估一套口红机H5源码，不是先看页面炫不炫，而是先找“抽奖判定”到底在哪一层。
2.1 前端交互层：口红格子、动效和中奖飞屏
前端这层负责的事不多：渲染一排口红格子、受理用户点击、把结果用动效演出来。常见做法是一套移动端HTML页面加一个轻量交互层，用不用Vue、uni-app都行——uni-app的H5产物也能用，只是要记得把接口域名放到公共配置文件里，避免换测试服时要重新打包。这就和常被问的“uniapp封装H5如何指向2个域名”是同一类问题：域名别写死在源码里，配置化才是正经做法。
口红格子的布局就是宫格，随便几张图片加CSS就能排出来：
<div class="board" id="board"> <div class="cell">import random def draw_by_weight(pool): """pool 形如 [{"prize_id":"P1","weight":5}, {"prize_id":"P2","weight":50}]""" total = sum(item["weight"] for item in pool) r = random.uniform(0, total) for item in pool: r -= item["weight"] if r <= 0: return item["prize_id"] return pool[-1]["prize_id"]参数说明：weight是相对权重不是绝对概率，把特等奖权重设为1、谢谢参与权重设为100，“中大奖”的直觉比例大概是1/101，但运营常说的“中奖率”是含小奖的，所以奖品表里要把“谢谢参与”也当作一档奖品单独列出来，否则统计口径会打架。random.uniform(0, total)之后用递减法逐个命中，比一次性生成权重数组再随机选择省内存，也方便日后动态调整权重列表。边界情况要注意：如果total为0，函数会抛除零异常，奖品池初始化时要兜一层if not pool or total <= 0: return "none"。
第二套是带保底的动态加权。纯随机抽奖在样本量小的时候会出现“连抽五次全中”或者“大奖从没出现过”的极端分布，用户会直接质疑概率造假。常见的做法是给每个用户累计“祝福值”：
def draw_with_blessing(pool, play_record): blessing = play_record["blessing"] need = play_record["need_blessing"] if blessing >= need: # 保底命中，直接返回大奖并清零祝福值 play_record["blessing"] = 0 return "BIG_PRIZE" prize_id = draw_by_weight(pool) if prize_id == "BIG_PRIZE": play_record["blessing"] = 0 else: play_record["blessing"] = blessing + 1 return prize_id逻辑说明：need_blessing就是保底门槛，常见做法是大奖价值越高门槛越高，比如“连续50次未中大奖，第51次必中”。这样做不是为了讨好用户，而是为了把运营风险控制在可预估范围：如果没有保底，大奖的发货成本在概率毛刺里会突然超标，财务没法做预算。参数调优的原则是：保底阈值乘上大奖成本，要低于单用户预期毛利。比如大奖是一支市价300元的口红，单次抽奖客单价10元，保底阈值至少应设在60次以上，否则每个用户在保底线前都能等到大奖，成本就被打穿了。
3.2 前端点击到出结果：H5交互代码怎么写
前一章贴了前端格子的监听代码，这里补全一个更完整的前端抽奖流程。进入页面时先向后端请求/api/bootstrap，拿到本轮gameToken和当日剩余次数；点击格子后把gameToken随请求带给后端，后端消费这个token并返回抽奖结果。
async function bootstrap() { const res = await fetch('/api/bootstrap', { method: 'POST' }); const data = await res.json(); localStorage.setItem('gameToken', data.token); renderBoard(data.prizes); renderLeftTimes(data.leftTimes); } async function doDraw(cellIndex) { const token = localStorage.getItem('gameToken'); const res = await fetch('/api/lottery', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ cell: cellIndex, token }) }); const data = await res.json(); if (data.code !== 0) { showToast(data.msg); // 常见返回：次数不足、token已使用 return; } if (data.prize) { showWinFlyScreen(data.prize); requestAddress(data.prize); // 中奖后拉出填地址抽屉 } else { showLoseTip(data.coupon); } }参数说明：gameToken是一次性令牌，抽奖成功后应立即作废，再次携带同一个token请求时，后端要回一个“令牌已使用”的提示而不是再抽一次。这一条能同时挡掉两类问题：用户手滑连点导致的重复抽奖，以及恶意脚本刷接口。leftTimes是进入页面时的剩余次数，它不是实时扣减的，抽完后由响应里的最新剩余次数回填，避免前端自己算着算着和服务器不一致。中奖后requestAddress内部会跳转到独立地址页，不要把地址表单直接嵌在宫格页的fixed弹层里。
这里要提醒一个常见的反模式：有些源码为了图省事，把“抽奖结果”直接放在请求参数里，也就是把结果参数由客户端传上来，服务端只做透传。这种接口拿到线上，用户抓包改一个result=win就全场通吃了。后端必须自己随机，客户端传的cell只能用于记录用户点了第几格，绝不能携带任何奖品信息或布尔结果。
3.3 支付回调与对账：凑齐“无需公众号”的最后一环
如果你选择了现金抽奖模式，微信支付回调就是整个源码里最容易出错的一段。回调的作用是：用户付完钱后，微信服务端会向你的回调地址POST一条通知，告诉你这笔订单已经支付成功。这里的原则不是“接口收到通知就改状态”，而是“验签通过且订单状态未被处理过，才改状态”。
# 伪代码结构，具体字段以微信支付官方文档为准 def pay_callback(request): # 1. 校验请求来源与签名 if not verify_signature(request): return "FAIL" # 2. 解析订单号与支付结果 order_no = request.get("out_trade_no") pay_state = request.get("trade_state") # SUCCESS 才算支付成功 if pay_state != "SUCCESS": return "SUCCESS" # 非成功状态也回执，避免重复推送 # 3. 幂等更新订单状态 updated = update_order_if_created(order_no, status="paid") return "SUCCESS" if updated else "SUCCESS" # 已处理过也回 SUCCESS逻辑说明：verify_signature这一行是命门，用商户号、证书序列号和回调报文算出的签名做比对，验不过的通知一律当作没收到。update_order_if_created是用条件更新来实现幂等：第一笔通知把订单从created改成paid；微信因网络重试推来的第二笔通知，条件更新影响行数为0，函数依然返回SUCCESS，但不会重复发货。为什么重复通知也要回SUCCESS？因为微信支付会持续重试回调直到你明确返回成功，如果因为“订单已处理”就回FAIL，微信会一直推，反而把你的日志刷爆。
没有公众号时这条链路怎么走通？页面在前端只是打开一个支付收银台或二维码，后端通过商户接口生成code_url，并不需要用户openid，这是“无需公众号做支付”的常见可行路径。但这里有一个前置条件：你必须拥有一个微信支付商户号，并且把回调域名配到商户平台。没有商户号的话，就按第2章说的方案走免费抽奖模式，不引入资金流，也就没有回调这回事。想清楚你做哪种，再决定要不要把支付模块的代码放进部署清单。
4. 适配微信内置浏览器的关键关卡：从禁播音频到卡片分享
一个页面在普通浏览器里跑得好好的，一进微信就出现各种奇怪行为，这几乎是每个做微信H5的人都经历过的玄学时刻。口红机这种强交互页面尤其不能忽略微信WebView的“小性子”，这章把最容易踩的几个关卡逐个理清。
4.1 识别微信环境：UA判断和右上角引导
第一件事是判断用户是不是在微信里打开的。常见的做法是用UA特征MicroMessenger来做环境识别：
function isWeChat() { return /MicroMessenger/i.test(navigator.userAgent); } if (isWeChat()) { // 在微信里：显示“右上角分享给好友”的引导气泡 showShareGuide(); } else { // 在普通浏览器：直接提示复制链接去微信打开 showBrowserTip(); }逻辑说明：微信UA里固定带MicroMessenger字样，版本号会跟着微信版本走，所以用正则匹配特征值比匹配版本号可靠。这段代码放在页面入口处，主要是为了做两件差异化的事情：微信内引导用户点右上角“...”转发给朋友，微信外提示复制链接去微信打开。需要注意，电脑微信也带MicroMessenger，但它的内核版本通常更旧，某些CSS动画可能在电脑微信里掉帧，验证时不能只看手机微信。
区分环境不只是为了显示引导，更重要的是决定拿不拿用户身份。如果后面有付费抽奖，微信内环境配合公众号授权可以快速拿到openid，无公众号时则拿不到；普通浏览器拿到的用户标识和微信里可能不是同一个人，统计口径要分开。我通常会给isWeChat()加一个开关，允许后端通过配置强制切换“微信模式/浏览器模式”，方便自己后期在电脑上调试。
4.2 解锁微信端怪癖：自动播放、长按存图、输入框上移
微信内置浏览器有三个经典怪癖，口红机一个都躲不开。
第一个是自动播放被禁止。H5页面想放背景音乐或者点击格子播放音效，直接调用audio.play()在微信里大概率被拒绝，因为WebView在没有用户手势之前不允许播放。解决方法是让第一个触摸事件去解锁音频：
const bgm = document.getElementById('bgm'); document.addEventListener('touchstart', function unlockAudio() { bgm.play().catch(() => {}); document.removeEventListener('touchstart', unlockAudio); }, { passive: true }); document.addEventListener('click', function unlockAudioClick() { bgm.play().catch(() => {}); document.removeEventListener('click', unlockAudioClick); });参数说明：passive: true告诉浏览器监听器不需要调用preventDefault，触摸滚动时不会被破坏；play().catch(() => {})是因为用户首次触摸可能发生在异步准备好之前，播放失败不能把错误抛到控制台吓到自己。解锁后可以销毁监听器，避免每次触摸都触发一次play()调用。
第二个是长按图片会弹出微信的“保存图片”菜单。口红机的奖品图和格子图都很适合长按保存，但用户长按后页面可能出现菜单抖动，体验很差。在图片区域禁用contextmenu和selectstart是常见做法：
document.querySelectorAll('.cell img').forEach(img => { img.addEventListener('contextmenu', e => e.preventDefault()); }); img.addEventListener('touchstart', () => {}, { passive: true });注意不要全局禁用长按，因为中奖后用户需要长按复制收货地址，全局禁用会把复制功能也废掉。只针对纯装饰性的图片禁用就好了。
第三个是iOS键盘把布局顶飞。填收货地址的页面里，点击输入框弹出键盘时，微信WebView的视口高度会变化，position: fixed的底部按钮经常被顶到屏幕外或盖在键盘下面。常见规避是把底部按钮从fixed改成页面正常流，输入框聚焦后按钮被键盘推上去，而不是钉在某个绝对坐标。如果按钮必须吸底，可以监听visualViewport的resize，把按钮的位置跟随视口高度重新计算。口红机这种页面上，我强烈建议地址提交做成独立页面，而不是弹层，这样键盘问题最简单。
4.3 流量承接：抽奖只是入口，企业微信客服才是出口
很多运营把口红机当成“抽奖小游戏”来投放，抽完就结束，这是一种浪费。口红机更合理的定位是“流量钩子”：用户冲着口红来，抽中或没抽中都需要一个出口去承接后续运营，常见出口就是企业微信客服。
H5接入企业微信客服的常见做法是：在抽奖结果页和中奖确认页做一个“联系客服”的入口，点击后打开一个由企业微信后台生成的客服链接，或直接展示客服成员的二维码。这里有一个容易忽略的细节：要把活动来源参数随链接带进客服侧，比如source=wx_lipstick_01，这样客服后台能看到用户是从哪个活动来的，话术可以提前分组。没有认证公众号也没有关系，企业微信客服链接本身是独立H5，不需要依附服务号授权。
同时，每一局抽奖的record_no最好不要只在后端日志里躺平，中奖用户发起客服咨询时，让用户把“单号页”的链接发过来，客服点开就能看到这单是中了什么、发货到哪一步。这需要前端在结果页渲染一个只读的单号视图，后端给一个带签名的一次性查询链接。这个功能不大，但能把“用户中奖了找不到人”和“客服不知道用户中了什么”两个售后黑洞都堵上。一个口红机项目能走多远，往往取决于这些细节是否在第一次上线前就安排好。
5. 口红机H5落地避坑清单：从丢单、重复支付到页面刷新
买来的源码十有八九不会在文档里写清楚“哪里会炸”，我把实际跑项目中反复踩过的五个坑按现象、原因、解决整理出来，可以直接当成上线前的检查清单用。
5.1 现象：用户中了大奖，后台却查不到这笔单
用户截图说“我抽中了”，后台翻遍流水表找不到记录，第一反应是怀疑用户造假，但查了接口日志会发现请求根本没到达抽奖逻辑。
原因多半有两个：一是前端在点击格子的瞬间就做了展示，页面卡顿导致请求没发出；二是后端先返回了中奖结果，但写库失败后异常被吞掉了，接口给用户的是“成功”，库里却没有数据。
解决：后端抽奖接口必须把“写play_record成功”作为返回成功的前提，代码顺序是“扣库存→写流水→提交事务→返回结果”。如果写库抛异常，前面无论扣了多少库存都要回滚，绝不能让用户看到中奖结果但库里没有单。额外再加一层兜底审计：抽奖接口的入参、出参、耗时都打一条日志，字段里带上record_no和token，线上排查时用日志说话。
5.2 现象：支付成功后游戏又卡在“支付中”
用户确实付了钱，页面也跳转了，但抽奖接口却说“订单未支付”，用户心态直接爆炸。
原因：前端跳转后拿“支付成功”的页面展示，但服务端订单状态只认微信回调；回调没到，订单就还停在created。回调没到的常见原因是回调地址配置成了http://，或者回调域名没加到微信支付商户平台白名单，微信无法访问。
解决：把订单状态判断全部放在服务端，前端展示只读后端的查询结果。支付完成后，前端不要立刻展示“支付成功”，而是轮询/api/queryOrder，后端在收到微信回调并更新订单为paid后才返回“可以抽奖”。轮询间隔取2秒，连续10次没变再提示“正在确认支付结果”，这能挡住大部分询问。检查清单里加一项：上线前用微信支付的测试沙盒或小额单试跑一次回调，确认回调URL不需要登录即可访问。
5.3 现象：iOS微信里页面反复加载刷新
口红机页面在iOS微信里点进格子后白屏、闪一下又回到入口，刷新一次又好了，过一会儿又发作。这个问题在iPhone上尤其常见，和“iOS微信H5公众号重复刷新”说的是同一类现象。
原因：一是页面用history.replaceState改写URL后，iOS Safari对会话调度比较激进，把WebView回收了；二是入口页每次加载都去后端换新的gameToken，用户一刷新令牌就变，后端看到旧令牌失效又强制跳回入口，形成循环。
解决：gameToken不要每次刷新都换，进入页面时生成一次，存入sessionStorage，后端设置较长有效期（如24小时），抽奖时消费；页面里不要用replaceState频繁改变历史记录，路由切换用hash即可。还有一个干净的做法是让入口页只负责静默跳转，真正的游戏页用独立URL承载，这样WebView被回收后重新加载也能按URL直接回到游戏页。
5.4 现象：安卓手机键盘把按钮顶到屏幕外
中奖后填地址的页面，在安卓微信里点输入框，键盘弹起来把底部“提交”按钮顶走，点不到按钮只能先收键盘。
原因：低版本安卓WebView对visualViewport支持不完整，页面高度在键盘弹出时没同步缩小，position: fixed的按钮停留在被键盘截断的区域。
解决：地址页不要用吸底按钮，改成表单末尾的普通按钮；页面根容器去掉height: 100vh的写法，改让内容自然撑高。键盘弹出时用visualViewport的resize事件把需要可见的控件滚进视口：
const vv = window.visualViewport; if (vv) { vv.addEventListener('resize', () => { document.getElementById('submitBtn').scrollIntoView({ block: 'nearest' }); }); }这个监听只加在地址页，游戏页不需要加，避免抽奖动画被意外滚动干扰。
5.5 现象：分享出去的卡片没有标题和缩略图
用户把口红机链接转发到群里，卡片要么只有光秃秃的URL，要么标题是一串默认域名。这个现象在“H5微信卡片分享”里被问得最多。
原因：微信在生成分享卡片时，会优先读取页面头部里的<title>、description和og:image；如果没有设置，就退化成截取URL。认证公众号能通过JS-SDK强行指定分享卡片内容，但“无需公众号”的模式下调用不了JS-SDK，只能把页面头信息做对。
解决：在服务端按请求路径动态输出这些meta，特别是缩略图地址要填一个带绝对域名的图片URL，图片尺寸一般建议在300×300以上。分享出去的卡片不只是面子问题，它直接决定口红机在群里的点击率。建议每次部署后，先拿自己的微信转发一次，看卡片效果是否符合预期再放量。
6. 把口红机做成运营工具：动态权重、抽取验证和复盘习惯
最后一章不讲新功能，讲一个让口红机从“一次性活动页”变成“长期运营工具”的习惯：把概率和文案都做成可配置，而不是藏在代码里。
6.1 上线前的蒙特卡洛抽验
权重抽奖算法写完，第一件事不是联调页面，而是跑十万次模拟，验证真实概率符合业务预期。代码很简单：
from collections import Counter def simulate(pool, times=100000): counter = Counter() for _ in range(times): prize_id = draw_by_weight(pool) counter[prize_id] += 1 for prize_id, cnt in counter.most_common(): print(f"{prize_id}: {cnt / times * 100:.2f}%")参数说明：pool用线上同一份奖品表，模拟次数越多，结果越接近权重值的数学期望；保底逻辑要单独写测试用例，断言“连续N次未中、第N+1次必中”。如果模拟出来大奖概率比预想的低，回去查权重表，不要在代码里写“如果随机数小于0.0001就中奖”这种特判，否则运营想调参数就得改代码，迟早翻车。
6.2 把概率挪进配置里
我自己做这类H5最深的教训，是把大奖概率写死在源码里。上线第一天运营说“中奖率太高了预算超了”，这边要改代码、重新打包、重新部署，折腾半小时；改成数据库权重配置后，运营自己在后台把weight从5改成2，一分钟生效，不用碰代码。抽奖文案、按钮颜色、保底阈值，凡是运营可能隔三差五想调的，都放配置，不要把运营的日常需求变成开发的发版任务。
验证也要形成习惯：每周看一眼play_record的分时中奖数，出现连续一小时中奖率高于预设值，先查是不是刷子用脚本撞接口，再看保底逻辑是否被异常触发。概率游戏一旦让用户觉得“后台在暗箱操作”，口碑就坏了；反过来，公开概率、限量保底、中奖可兑付，用户反而会把你的链接转给更多朋友。这套复盘习惯不复杂，但能让口红机H5从“接一个丢一个”变成可以长期运营的流量入口。希望帮到你。
本文还有配套的精品资源，点击获取
