企业官网建设流程全解析

简介：微信开发砸金蛋是一份基于微信平台的互动小游戏源码包，面向正在学习微信开发或需要快速搭建活动页面的开发者，围绕砸金蛋抽奖场景整合了公众号JS-SDK接入、前端页面渲染、后端数据处理等知识点。压缩包共6个文件，以HTML页面、PHP脚本和4张PNG素材为主，总大小仅91KB：HTML负责游戏界面与交互，PHP承担奖品分发、数据读写与简单校验，PNG图片则为金蛋及界面装饰素材，结构精简，便于直接部署调试，也适合个人二次开发。游戏源码覆盖随机中奖、动画反馈与结果回传的完整链路，可看到前端调用与后端接口的配合方式，同时涉及公众平台下的分享与用户交互思路，以及防止重复提交等基础安全做法。目前已有218人学习下载，包体小巧、无冗余依赖，适合初学者对照源码理解砸金蛋的完整实现，也可在其基础上改成其他抽奖玩法。

1. 砸金蛋看着是前端动画，倒下的其实都是后端

一套完整的微信砸金蛋，用户路径很短：进页面、点蛋壳、看结果、填收货信息。但活动翻车从来不是这四个点击，而是藏在链路里的细节——并发一上来奖品超发、分享出去的链接在安卓上拿不到授权、iOS 和安卓取到的页面地址不一致导致分享卡片签名失败、模板消息发不出去。砸金蛋本质是概率型抽奖，牵涉微信授权、分享、消息触达三块能力，属于典型的「前端半小时、后端一个星期」的营销互动。这不是玄学，是每次大促前都有人踩的坑。我按自己做活动页的惯例把这套链路拆开：先定技术边界，再把前端动画、后端概率与防刷、微信接口三个坑位过一遍，最后给一份上线前的验证清单。

2. 先定技术边界：H5 还是小程序，决定后面省不省心

砸金蛋是典型短生命周期活动，需求方常提「下周上线、跑两周就撤」，这时候技术选型会被投放入口卡死。做选择之前，先确认活动落在哪里：公众号菜单栏、图文里的阅读原文、线下物料扫码，还是小程序里的会员中心。入口不一样，后面的授权、分享、发布节奏全都不一样。

2.1 投放入口决定第一版：公众号菜单、图文与二维码怎么选

我在询阶段会先问一句：用户从哪儿点进来。这个问题的答案基本决定了第一版做 H5 还是小程序，而不是先争论技术栈。

只要活动需要从公众号图文、菜单栏或线下物料导量，我一般直接选 H5。它不用等审核，奖池配置可以随时在后端调整，投放两天后发现问题也能热修复。小程序版本适合放在会员中心的积分商城里，用户路径长、复访频次高，砸金蛋只是整个体系里的一个模块，这时候才值得付出审核成本。

选型的另一个隐藏变量是分享。H5 可以用 JS-SDK 自定义分享标题和图片，砸金蛋这种带裂变属性的活动很依赖这个能力；小程序分享卡片虽然稳定，但卡片上的文案和图片受平台限制，活动氛围弱不少。对于「分享得次数」的玩法，H5 的操作空间明显更大。

2.2 最小可运行的活动脚手架：目录结构与奖池配置

确定 H5 后，我习惯把工程拆成 frontend 和 service 两部分，前端只管渲染和交互，后端管授权、开奖、库存、风控。一个能跑通最小闭环的项目结构长这样：

activity-egg/ ├── frontend/ │ ├── index.html # 活动页单页 │ ├── css/style.css # 金蛋动画与弹窗样式 │ └── js/app.js # 状态机与接口调用 └── service/ ├── config/ │ ├── app.js # 服务端口、回调域名等 │ └── prize.json # 奖池配置 ├── routes/ │ ├── activity.js # 开奖、次数、领奖接口 │ └── wechat.js # 授权、签名、模板消息接口 ├── redis/ │ ├── draw.lua # 原子扣库存脚本 │ └── client.js # Redis 连接封装 └── server.js # 服务入口

奖池配置是活动的中枢，前后端都围着它转。我常用下面这样一份 JSON 管整个活动的奖：

{ "activityId": "spring-egg-2024", "levels": [ { "key": "p1", "name": "一等奖", "weight": 1, "stock": 5, "limit": 1 }, { "key": "p2", "name": "二等奖", "weight": 5, "stock": 50, "limit": 1 }, { "key": "p3", "name": "三等奖", "weight": 40, "stock": 500, "limit": 3 }, { "key": "p4", "name": "谢谢参与", "weight": 954, "stock": -1, "limit": 0 } ], "dailyLimit": 3, "shareReward": 1 }

weight 表示权重，不是绝对百分比，sum 之后按区间随机；stock 为 -1 表示不限库存，一般留给「谢谢参与」；limit 限制单个用户整个活动周期内中某一档奖的次数。这样配置的好处是运营改奖时不用动前端，后端只改 JSON 就完成上下架。

提示：奖池配置只放在后端，前端只拿 activityId，不要把奖品列表和概率下发到页面。前端拿不到概率，后端的权重调整也不会被缓存污染。

2.3 接口怎么分：把授权和开奖拆成两个服务

活动服务只做开奖闭环，微信能力单独走一条通道。我见过不少项目把授权、签名、开奖揉在一个 service 里，改活动时担心动了授权的逻辑，改授权时又怕碰了奖池，联调阶段两头堵。

拆开之后，接口边界很清晰：

// POST /api/egg/draw // 请求体 { "activityId": "spring-egg-2024" } // 成功响应 { "code": 0, "data": { "prizeKey": "p2", "prizeName": "二等奖", "type": "coupon" } } // 失败响应：次数用完 / 奖品已抢光 / 风控拦截 { "code": 1001, "msg": "今日砸蛋次数已用完" }

开奖接口本身不感知用户是怎么登录的，后端中间件从会话里取 openid 注入请求上下文。联调阶段不方便走微信授权，我习惯加一个 mock 开关：非生产环境优先读x-user-id请求头，没有才走 openid 逻辑。

这样做的好处是前端不用搭微信环境就能把砸蛋流程跑通，后端也能用脚本模拟大量不同用户压测开奖接口。等到真机验收时再把 mock 头去掉，走一遍真实授权链。这个习惯帮我省掉了大量「等微信回调」的时间。

3. 前端交互：金蛋动画、开奖弹窗与状态机

前端的核心不是把金蛋画得多像，而是三件事：点击反馈要爽、状态不能乱、网络异常要能收回来。砸金蛋的交互其实只有一次点击，但这次点击背后是异步请求，前端最容易被「用户连点三下」打出重复开奖请求。

3.1 六个金蛋的布局与命中动画：CSS 关键帧怎么调

活动页最常见的布局是一排三颗、两排六颗金蛋，用户从六颗里选。HTML 结构保持简单，金蛋用 CSS 画，不依赖图片素材：

<div class="egg-grid"> <div class="egg-item">.egg-grid { display: flex; flex-wrap: wrap; justify-content: center; gap: 12px; padding: 24px; } .egg-item { width: 96px; height: 128px; position: relative; cursor: pointer; } .egg-body { width: 96px; height: 128px; background: radial-gradient(circle at 30% 20%, #f6d365, #fda085 70%); border-radius: 50% 50% 46% 54% / 62% 62% 38% 38%; transition: transform 0.1s; } .egg-item.hit .egg-body { animation: egg-hit 0.3s ease-in-out; } .egg-item.done .egg-body { animation: egg-crack 0.4s forwards; } @keyframes egg-hit { 0% { transform: rotate(0); } 40% { transform: rotate(-8deg); } 70% { transform: rotate(6deg); } 100% { transform: rotate(0); } } @keyframes egg-crack { 0% { opacity: 1; transform: scale(1); } 60% { opacity: 0.6; transform: scale(1.12) rotate(6deg); } 100% { opacity: 0; transform: scale(0.4); } }

hit 动画要短促，0.3 秒正好，太长会让用户觉得卡；crack 动画 0.4 秒并加forwards，让蛋壳停在消失状态，避免动画结束后回弹。安卓 webview 对 transform 和 opacity 的渲染比较稳，我刻意避开filter: blur()这类耗性能的属性，原因是大促页面同时跑多个动画时，安卓低端机容易掉帧。

3.2 开奖状态机：待砸、砸中、已领奖三态流转

金蛋必须有自己的状态，否则连点三下会发出三次开奖请求。我维护一个最小状态机，每个金蛋只允许从「待砸」进入「请求中」，请求完成后进入「已砸」：

const EGG_STATE = { READY: 'ready', PENDING: 'pending', DONE: 'done' }; async function crackEgg(index) { const item = document.querySelector(`.egg-item[data-index="${index}"]`); if (!item || item.dataset.state === EGG_STATE.PENDING || item.dataset.state === EGG_STATE.DONE) { return; } item.dataset.state = EGG_STATE.PENDING; item.classList.add('hit'); const controller = new AbortController(); const timer = setTimeout(() => controller.abort(), 5000); try { const res = await fetch('/api/egg/draw', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ activityId: 'spring-egg-2024' }), signal: controller.signal }); const data = await res.json(); if (data.code !== 0) { throw new Error(data.msg || '开奖失败'); } item.dataset.state = EGG_STATE.DONE; item.classList.remove('hit'); item.classList.add('done'); openResultModal(data.data); } catch (e) { // 请求失败或超时，回滚为待砸状态，让用户重试 item.dataset.state = EGG_STATE.READY; item.classList.remove('hit'); showToast(e.message || '网络异常，请重试'); } finally { clearTimeout(timer); } }

请求超时设 5 秒，超过就 abort。这里的关键点是失败回滚：很多活动页做砸蛋，网络抖动一下，蛋壳已经裂开但奖品没弹出来，用户再砸同一颗蛋被状态卡死。我在失败分支里把状态回滚成 ready，同时移除 hit 类，让动画回到未砸状态，用户重试成本几乎为零。

开奖结果的展示不放在金蛋上，而是统一走弹窗。弹窗里展示奖品名、兑奖方式，以及一个「继续砸蛋」按钮。弹窗要保证和状态机联动：只有进入 DONE 的金蛋才允许触发弹窗，避免用户拿上一个蛋的结果去冒充下一个蛋的状态。

3.3 分享加一次机会：回调不触发时怎么兜底

砸金蛋的裂变玩法里，「分享给好友后再得一次」是最常见的任务。分享能力依赖 JS-SDK 的主动分享配置：

wx.config({ debug: false, appId: appId, timestamp: signResult.timestamp, nonceStr: signResult.nonceStr, signature: signResult.signature, jsApiList: ['updateAppMessageShareData', 'updateTimelineShareData'] }); wx.ready(() => { wx.updateAppMessageShareData({ title: '快来砸金蛋，戳一下就有奖', desc: '我已经试过了，就差你', link: location.href.split('#')[0], imgUrl: shareCover, success: () => { // 这里不要直接给用户加次数 } }); });

这个 success 回调只在分享面板成功调起时触发，不代表用户真的把链接发出去或好友点开了。如果在这里加次数，用户打开面板什么都不做也能白拿机会。常见做法是把分享者的 openid 拼到分享链接的from参数上，被分享者真正打开页面时，后端给from对应的用户补一次机会。这样分享有效性由被分享者的一次有效访问来印证，而不是依赖微信面板的回调时机。前端只负责在页面上提示「转发给好友即可再砸一次」。

4. 后端开奖：概率控制、库存扣减与并发防刷

后端决定这个活动能不能活着撑过大促。砸金蛋的后端问题集中在三个词：概率、库存、防刷。其中库存超发是事故级别的问题，真发了超出库存的实物奖，损失无法追回。

4.1 用权重表代替百分比：概率配置与随机落点

概率配置不用固定百分比，因为运营会频繁调奖。权重表的逻辑是先求总权重，再按随机值落区间：

import random def pick_level(levels): # levels: [{"key": "p1", "weight": 1}, ...] total = sum(level["weight"] for level in levels) r = random.randint(1, total) cursor = 0 for level in levels: cursor += level["weight"] if r <= cursor: return level["key"] return levels[-1]["key"]

权重表的好处是：下架一个奖品时，不需要重新计算其他奖品的百分比，直接把它从候选列表里过滤掉即可；新增奖品也不会破坏已有档位的命中区间。库存用完的档位在选型时排除掉，剩下的候选重新参与权重计算。

随机数用random.randint(1, total)保证每个整数区间连续，避免random()浮点转整时的边界误差。实际生产里我会把 random 放到应用层，算完 prizeKey 后再走 Lua 脚本扣库存。原因在下一节展开。

4.2 Redis + Lua 原子扣库存：一把锁防止奖品超发

开奖逻辑分成两步：先按权重选中奖品，再扣减该奖品的库存并登记中奖用户。这两步不能拆开做，否则并发下会出现两个请求同时通过库存检查、最后超发。Redis 的 Lua 脚本能把「检查次数、扣库存、登记中奖」合并成一次原子执行：

-- KEYS[1]: 用户今日剩余次数 key -- KEYS[2]: 奖品库存 key -- KEYS[3]: 中奖用户集合 key -- ARGV[1]: openid -- ARGV[2]: 奖品 key -- ARGV[3]: dailyLimit local used = tonumber(redis.call('GET', KEYS[1]) or '0') if used >= tonumber(ARGV[3]) then return 0 -- 次数用完 end local stock = tonumber(redis.call('GET', KEYS[2]) or '0') if stock <= 0 then return -1 -- 库存不足 end redis.call('INCR', KEYS[1]) redis.call('DECR', KEYS[2]) redis.call('SADD', KEYS[3], ARGV[1] .. ':' .. ARGV[2]) redis.call('EXPIRE', KEYS[1], 86400) return 1 -- 成功

Node 侧调用：

const result = await redisClient.eval(` -- 上面整段 Lua `, { keys: [ `egg:${activityId}:used:${openid}:${day}`, `egg:${activityId}:stock:${prizeKey}`, `egg:${activityId}:winners:${prizeKey}` ], arguments: [openid, prizeKey, dailyLimit] }); if (result === 0) { /* 提示次数用完 */ } if (result === -1) { /* 提示已抢光 */ }

注意：Lua 脚本里不要做权重随机。权重随机放在应用层算好 prizeKey 再传入脚本，这样库存 key 的粒度清晰，单个奖品一个 key，查库存、补库存、调整剩余量都方便。如果脚本内部读奖池做随机，脚本和配置的耦合会变重，排查时也不好定位。

库存用DECR而不是先GET再SET，因为后者两步之间有竞态。为什么不用分布式锁？因为单 Redis 实例下 Lua 脚本天然串行执行，已经覆盖了这个场景；加分布式锁反而引入锁过期、释放失败等新问题。唯一要确认的是 Redis 版本支持 EVAL，这一点主流云服务商都满足。

4.3 防刷三板斧：频控、任务发次数、风控审核

砸蛋次数不能是无限的，否则权重表再严谨也会被脚本刷穿。我见过最朴素也最有效的设计是把次数做成「任务发放制」：签到给 2 次、关注公众号给 1 次、分享有效回流给 1 次。后端只认「可用次数」这个计数器，前端没有任何渠道凭空加次数。

def grant_times(openid, delta=1): key = f"egg:times:{openid}" cur = redis.incrby(key, delta) if cur == 1: redis.expire(key, 86400) return cur def consume_times(openid): key = f"egg:times:{openid}" if int(redis.get(key) or 0) <= 0: return False redis.decr(key) return True

次数之外再加一道请求频控，防止单用户短时间重复刷接口：

def rate_limit(openid, ip): key = f"egg:rl:{openid}:{int(time.time()) // 60}" cur = redis.incr(key) if cur == 1: redis.expire(key, 60) return cur <= 10 # 每分钟最多 10 次请求

最后一条防线是风控审核。实物大奖的中奖记录不要直接进入已发放状态，而是先落到「待审核」队列，运营确认用户没有批量注册、同一收货地址重复领奖后再发货。我在中奖记录里加了状态字段：claimed表示已中奖待审核，review_passed表示审核通过，shipped表示已发货。这样即便某个微信号是刷来的，奖品也卡在人工审核环节，不会造成实际损失。

5. 微信能力对接避坑：授权、分享与消息触达

微信侧的三块能力是砸金蛋最常翻车的地方。授权拿不到 openid、分享签名失败、模板消息发不出去，这三个问题我做活动页时几乎每期都遇到，属于血泪经验。

5.1 静默授权拿不到 openid：入口跳转哪里容易漏

现象：活动页在公众号菜单里打开正常，转发到群里后，用户点链接进来，后端日志里 openid 为空，开奖接口直接拒绝。

原因：静默授权只对配置了网页授权回调域名的公众号生效，且页面 URL 必须与该域名匹配。分享出去的链接如果没经过授权跳转，直接用页面原 URL 打开，后端就收不到 code。还有一类情况是页面同时被非微信浏览器打开，OAuth 流程根本不成立。

解决：页面入口统一做一个授权转发判断。URL 上没有 code 参数时，先拼 OAuth 授权地址跳转一次，拿到 code 后再交给后端换 openid：

if (!getQuery('code')) { const redirect = encodeURIComponent(location.href.split('#')[0]); const oauthUrl = 'https://open.weixin.qq.com/connect/oauth2/authorize' + '?appid=' + appId + '&redirect_uri=' + redirect + '&response_type=code' + '&scope=snsapi_base' + '&state=' + stateParam + '#wechat_redirect'; location.replace(oauthUrl); }

scope用snsapi_base，因为砸金蛋只需要 openid，不需要用户头像昵称；用snsapi_userinfo会多弹一次授权确认框，活动页转化率明显下降。state参数必须带并回传校验，防止授权回调被篡改。

5.2 JSSDK 签名失败：iOS 和安卓取到的 URL 不一样

现象：同一个页面，iOS 上分享卡片能正常调起，安卓上报invalid signature。后端签名接口单独测试是好的。

原因：JSSDK 签名要求使用当前页面完整 URL，但要去掉 hash。iOS 和安卓 webview 对location.href的返回不一致，尤其当 URL 里带着#wechat_redirect时，部分机型会把 hash 带进签名串。签名用的 URL 和后端wx.config里 timestamp、nonceStr 对应的 URL 对不上，就必然报错。

解决：统一取location.href.split('#')[0]作为签名 URL，并且在后端缓存 jsapi_ticket。ticket 有效期两小时，每次请求都重新拉会让签名接口变慢，也容易被微信限频。我在 wechat 服务里做了内存缓存，快过期时异步刷新，签名接口只负责拼参数、不回源。

值得注意的一个细节是签名请求要由后端拿到真实页面 URL，不能由前端传一个拼好的 URL 过来；前端传参不可信，签名结果会被伪造。

5.3 模板消息发不出去：48 小时窗口与 openid 错位

现象：用户砸中实物奖后，调用模板消息接口下发中奖通知，部分用户收不到。日志里错误信息指向 openid 无效，或者提示用户与公众号没有互动。

原因：模板消息依赖用户与公众号之间的会话窗口。用户只是在网页里砸蛋、没有主动给公众号发过消息，窗口可能已经关闭；更常见的情况是用户复制链接在电脑浏览器里打开并完成砸蛋，openid 对应关系根本不存在。用户取关后也会立刻失效。

解决：中奖通知不要做定时批量补发，在用户完成砸蛋的请求里同步触发消息下发，此时窗口最接近打开状态。发货通知这类强确认消息，我换成客服消息体系，用户进入公众号后 48 小时内可下发；再不行就退回短信。不要把消息触达的成功率赌在模板消息上，活动规则里提前写明「中奖后请留意公众号消息」，同时备好短信通道。

5.4 一人多号重复领奖：收货信息维度去重

现象：活动结束后核对实物奖，发现有同一手机号、同一收货地址出现两次以上，明显是同一个自然人用多个微信号分别砸蛋。

原因：openid 维度的限领规则天然挡不住多账号。用户注册成本低，一个手机号能同时持有两三个微信号，活动期间又不做实名，openid 查重形同虚设。

解决：我把限领规则从「openid 维度」升级成「openid + 手机号 + 收货地址」三重校验。填收货信息时查数据库：同一手机号在本活动周期内已中奖过实物，直接拦截。再叠加 4.3 的人工审核队列，高危奖品一律人工核对地址相似度。技术防刷只能提高成本，没法完全杜绝，最终效果靠审核兜底。

6. 上线前把概率和并发当黑盒测一遍

活动上线前，我会把整个开奖链路当成黑匣子，只从外部打流量。这一段是验证脚本而不是压测平台教程，足够帮你抓出 90% 的发布事故。

第一轮跑并发冒烟。造一个测试奖池，一等奖必中、库存 100，然后并发打 200 个请求，断言接口返回的中奖数量不超过库存：

import asyncio import aiohttp async def hit(session, i): async with session.post( "http://127.0.0.1:8080/api/egg/draw", json={"activityId": "test-egg"}, headers={"x-user-id": f"mock-{i}"} ) as resp: return await resp.json() async def main(): async with aiohttp.ClientSession() as session: tasks = [hit(session, i) for i in range(200)] results = await asyncio.gather(*tasks, return_exceptions=True) ok = [r for r in results if isinstance(r, dict) and r.get("code") == 0] print(f"total={len(results)} ok={len(ok)}") asyncio.run(main())

跑完去 Redis 里核对egg:test-egg:stock:p1的值和 winners 集合数量，两者应该严格对应。如果 ok 数量大于库存，说明 Lua 脚本没生效，立即停发。

第二轮跑概率回归。把测试奖池的权重放大到万次级别可观察的差异，循环 1 万次开奖，统计各档位命中占比，和权重计算的期望占比对比，允许 1% 到 2% 的偏差。偏差更大说明随机落点或库存过滤逻辑有问题。

我自己的习惯是每次上线前按「先必中冒烟、再并发冒烟、最后概率回归」跑完一轮才把链接发出去内测。有一回活动改奖池时只改了 JSON，忘记奖品 key 与 Lua 脚本里的库存 key 保持同步，线上出现「库存显示没了还能砸出中奖」的异常，靠这轮脚本在测试环境提前抓了出来，避免了实物奖超发的直接损失。多花二十分钟做验证，比事后补发货赔笑脸划算得多。希望帮到你。

本文还有配套的精品资源，点击获取