简介这份资源是一套可直接运行的「抛硬币」微信小程序源码主要面向想快速上手小程序开发、或希望了解流量主变现方式的开发者。小程序提供随机正反面结果适合日常决策、趣味互动等场景结构简洁无需配置合法域名用微信开发者工具即可打开运行。压缩包共24个文件以.js逻辑脚本、.json配置、.wxml页面结构、.wxss样式及.png图标为主涵盖app.js、project.config.json和pages目录下的功能页面源码完整、目录清晰便于直接阅读改造。已有64人学习适合初学者参考。资源亮点在于可将其作为模板改造成抽签、转盘等轻量小游戏借助微信流量主计划接入广告也能帮助理解小程序的审核发布与商业变现流程并根据用户反馈持续迭代优化。1. 抛硬币小游戏最小的产品形态最容易被低估的运营门槛把抛硬币做进微信小程序看起来是个几十行代码的玩具正面反面各一张图点一下出结果。但真正把它推到“能运营”的状态需要处理的是另外三件事随机数是否可信、广告位是否自然、以及过审时怎么向平台证明这不是赌博。很多开发者复制一份源码上传第二天就被打回原因通常是页面里出现了“下注”“翻倍”这类字眼或者高频诱导点击广告。这个标题里真正值钱的不是“抛硬币”本身而是“完美运营”四个字。它要求代码层面有稳定的随机逻辑、有节制的广告触发频率内容层面完全合规。适合谁读准备上架一款休闲类小游戏小程序、想靠流量主产生稳定收益、但不想踩审核暗坑的开发者。2. 为什么用 uni-app 搭抛硬币小游戏以及最小页面骨架2.1 技术栈选择原生微信小程序 vs uni-app单做微信端原生小程序语言完全够用.wxml、.wxss、.js 三件套跑一个抛硬币逻辑非常轻。但标题里的“源码”通常意味着要分发、要二次开发可能还要同步发布到支付宝或抖音小程序。这类场景下我一般会用 uni-app一套 Vue 语法编译到多个端后续接 HBuilderX 跑微信开发者工具也顺畅。两者在实现抛硬币上的核心差异是动画写法。原生小程序用一个view加 CSS3 transform 就能完成翻转uni-app 同样支持但组件层的生命周期和 onLoad 参数需要适应 Vue 的写法。另外uni-app 对 npm 包的支持比原生小程序激进如果要接第三方统计或广告聚合 SDK生态更完整。提示只做微信端、不想引入编译链就选原生。要跨端分发选 uni-app。不要为了“看起来高级”硬上框架。2.2 用 view 模拟硬币翻转的动画骨架抛硬币的视觉核心就一步正面到反面的翻转。不需要 Canvas也不需要 Lottie。用 CSS 的rotateY配合transition就能做出 3D 翻转效果。以下是一段自带正反面状态的 uni-app 页面骨架template view classcoin-wrap taphandleTap view classcoin :class{ flipped: isFlipped } view classcoin-face front{{ result }}/view view classcoin-face back{{ result 正面 ? 反面 : 正面 }}/view /view /view /template.coin { width: 220rpx; height: 220rpx; transform-style: preserve-3d; transition: transform 0.6s ease-in-out; } .coin.flipped { transform: rotateY(180deg); } .coin-face { position: absolute; width: 100%; height: 100%; border-radius: 50%; display: flex; align-items: center; justify-content: center; backface-visibility: hidden; } .coin-face.back { transform: rotateY(180deg); }逻辑说明flipped类控制硬币翻转 180 度backface-visibility: hidden保证翻转过程中背面不穿透。front是当前显示面back预存另一面。真正决定result值的随机逻辑放在点击事件里动画只负责表现不参与结果计算。参数说明transform: rotateY(180deg)是正反切换的关键要做出连续抛掷效果需要在切换前先移除flipped类、等待几毫秒再重新加上。常见做法是this.setData({ isFlipped: false }); setTimeout(() { const nextResult Math.random() 0.5 ? 正面 : 反面; this.setData({ result: nextResult, isFlipped: true }); }, 50);2.3 页面参数与交互防抖硬币翻转的动画时间在 0.6 秒左右如果用户在这期间连续点击会触发多次动画叠加出现“硬币横跳”的观感。更重要的是随机逻辑如果被连续执行用户在视觉上会认为“上次还没停这次结果又不准”直接破坏信任感。所以必须在点击入口做防抖。methods: { handleTap() { if (this.isRolling) return; this.isRolling true; this.setData({ isFlipped: false }); setTimeout(() { const nextResult Math.random() 0.5 ? 正面 : 反面; this.setData({ result: nextResult, isFlipped: true }); this.isRolling false; }, 50); } }这里的isRolling是实例属性而不是 data 字段因为它在同一事件循环内就会被重置不需要驱动视图更新。放在 data 里反而会触发多余的 setData 渲染消耗。这个细节对小程序性能有实际影响尤其是低端安卓机频繁 setData 会造成明显的掉帧。另外一个容易被忽略的参数是页面onHide时的状态清理。用户抛到一半切后台回来时动画可能停留在中间态。比较稳妥的做法是在onShow里重置isFlipped和result保证每次回到页面都从干净状态开始。提示微信小程序长按拖拽滚动的场景里滚动容器和点击事件容易冲突。抛硬币页面如果有历史记录列表建议把列表和硬币区域放在两个独立的 scroll-view 中避免 tap 与 scroll 的默认事件互相干扰。3. 随机数与公平性Math.random 能用但不能只有 Math.random3.1 伪随机在小程序端的边界很多开发者直接写Math.random() 0.5就当完成了抛硬币。从娱乐产品的角度这没有任何问题但如果后续想接“排行榜”“连胜记录”这类功能或者被用户质疑“是不是控制了结果”就需要对随机数的公平性做额外说明。Math.random在 JavaScript 引擎中基于伪随机数生成器它的种子依赖系统时间或熵池分布均匀性足够满足二选一的场景。但伪随机有一个特点同一套算法加同一套种子结果序列是可复现的。在小程序端用户每次冷启动都会重新取种子实际使用中不会遇到可预测问题但严谨的玩法应当记录每个回合的“随机种子 结果”以备审计。3.2 结果与动画分离的架构抛硬币产品的核心规则只有一条动画展示必须严格等于随机结果。不要在动画结束的瞬间才生成结果否则用户会认为“你看到我点停了才决定结果”。正确做法是点击时立即生成结果然后让动画去匹配它const nextResult Math.random() 0.5 ? 正面 : 反面; this.setData({ result: nextResult, isFlipped: false }); setTimeout(() { this.setData({ isFlipped: true }); }, 50);代码逻辑第一次 setData 只更新result不触发翻转第二次 setData 才让硬币转到对应面。这样即使用户指尖刚落下结果已经在数据层确定了动画只是延迟表演。这个模式与 H5 抽奖转盘的实现思想一致中奖结果先定滚轮旋转只是装饰。3.3 随机分布的自测脚本长期运营的小程序随机分布如果偏移用户完全能感知到。比如抛了 1000 次只出 430 次正面大家嘴上不说心里会记一笔。App 端可以在代码里埋点统计小程序的轻量做法是直接在开发者工具的控制台跑分布验证。在页面 onReady 里临时挂一个批量测试函数function testRandomDistribution(times 10000) { let headCount 0; for (let i 0; i times; i) { if (Math.random() 0.5) headCount; } console.log(正面占比${(headCount / times * 100).toFixed(2)}%); }正常结果应该在 49% 到 51% 之间。如果连续多次测试都偏差超过 2%要么是随机算法有问题要么是页面里叠加了其他修改Math.random的依赖。后者在引入第三方统计 SDK 时偶尔出现建议测试时先关闭所有插件。注意任何形式的“概率控制”都不要碰。比如让前几次必出正面来提升用户体验这类逻辑一旦被用户录屏反馈轻则下架重则封号。抛开合规风险控制概率会直接推翻用户对“完美运营”四个字的信任这是此类小游戏的生命线。4. 流量主接入Banner、激励视频和插屏广告的配置与取舍4.1 广告位设计什么时候弹出广告什么时候让用户主动看微信小程序流量主的核心收入来自三类广告Banner、插屏、激励视频。它们的 eCPM 差异明显Banner 最低激励视频最高插屏居中且波动大。抛硬币这种高频短会话小游戏广告频率设计比广告代码本身更影响收益与留存。常见做法是底部常驻 Banner不打断操作每 5 次抛掷后弹出一次插屏激励视频放在“看视频获得一次双面结果统计”或“去除记录页广告”这种用户主动触发的位置。但要注意新开通流量主的早期插屏广告的填充率不稳定会出现“无广告可展示”的现象所以代码里必须做好填充失败的回退。广告类型常见 eCPM 区间适合场景触发频率建议Banner较低页面底部常驻全程展示不做频控插屏波动较大每 N 次操作后5-10 次操作展示一次激励视频较高用户主动点击完全由用户触发4.2 Banner 与插屏广告的代码接入小程序平台的 Banner 组件是声明式写法直接在页面模板里嵌入ad标签即可。unit-id 是开通流量主后在后台生成的广告位 ID。关闭自动展示时可以在错误回调中动态隐藏 Banner 区域避免“广告拉取失败导致白块”的视觉问题。ad v-ifshowBanner unit-idadunit-xxxxxxxxxxxxxxxx ad-typebanner loadonAdLoaded erroronAdError /adonAdError(err) { this.showBanner false; console.warn(Banner 拉取失败已隐藏, err); }这里的v-if是 uni-app 的控制方式原生小程序对应wx:if。隐藏后不必设置自动重试因为下次进入页面时会重新挂载广告组件平台会自动重新拉取。不要手动做高频重试否则会触发广告频控限制导致单元 ID 被平台临时禁用。插屏广告用原生接口调用代码侧必须处理“加载完成才能展示”的状态let interstitialAd null; function initInterstitialAd() { if (wx.createInterstitialAd) { interstitialAd wx.createInterstitialAd({ adUnitId: adunit-xxxxxxxxxxxxxxxx }); } } function maybeShowInterstitial(count) { if (count % 5 ! 0) return; if (interstitialAd) { interstitialAd.show().catch(() { interstitialAd.load().then(() interstitialAd.show()); }); } }逻辑说明wx.createInterstitialAd在低版本基础库上不存在所以先做能力判断。插屏广告的坑在于它需要有缓存才能展示第一次创建后立刻调用show()大概率失败。上方代码的 catch 分支做了一个补救加载完成后再次展示这是官方推荐的标准流程。4.3 激励视频广告的参数与回调激励视频是三类广告中收益最高的也是审核最敏感的区域。它的核心特征是“用户必须完整看完视频才能获得奖励”。如果展示中途关闭就不能发奖励。以下是一个完整的激励视频接入示例function showRewardedVideo(onReward) { const videoAd wx.createRewardedVideoAd({ adUnitId: adunit-xxxxxxxxxxxxxxxx }); videoAd.onClose((res) { if (res res.isEnded) { onReward(); } else { wx.showToast({ title: 看完视频才能获得奖励, icon: none }); } }); videoAd.show().catch(() { videoAd.load().then(() videoAd.show()).catch(() { wx.showToast({ title: 广告暂时加载失败, icon: none }); }); }); }res.isEnded是微信平台给出的唯一可信标识表示用户是否完整看完了视频。这里绝对不能用“点击了广告”作为发奖依据也不能用onError回调发奖否则轻则激励视频能力被收回重则流量主资格被取消。奖励内容建议轻量化比如一次“双面统计”的展示、或清除一次误触记录不要和任何实物、现金挂钩。注意激励视频按钮不要做“自动弹出”。平台规则要求激励视频必须由用户主动触发页面加载后自动弹出激励视频是常见的拒绝理由。所有广告点击都应发生在用户明确意图之后。5. 让源码能过审、能存活的运营细节5.1 审核拒绝的常见原因与规避流量主申请通过后每次更新提交审核平台都会重点检查广告触发场景。抛硬币类目最容易踩的坑是“诱导点击”比如在硬币背面写上“点击翻倍”或者在结果页用误触设计引导用户点到广告。这些设计一旦被截图申诉基本一拒一个准。正确的姿态是“广告存在但闭嘴”。Banner 固定在页面底部文案与游戏无关激励视频按钮明确写出“看视频解锁统计”描述客观不夸大插屏的频率控制在每 5 次操作以上。运营后台的广告数据如果出现单日点击率异常飙升要主动检查是不是页面布局有遮挡或用户误触。另外小游戏类目抄袭的问题也需要注意。如果源码是购买的模板页面里其他开发者的水印、Logo 要清干净。平台对“同一套源码批量上架”的识别度比想象中高同一主体下多个类似小程序会被要求说明差异化。5.2 无广告状态下保持流畅新小程序在未达到流量主开通条件前页面里不能出现任何广告组件。很多开发者提前写好了ad标签用v-if控制显示但这依然违反了平台规则——代码包中不得包含广告代码。审核会扫描代码包而不是只看运行时表现。处理办法是把广告代码和业务代码分开。用条件注释或环境变量控制const isAdEnabled false; // 开发期置 false开通后置 true如果使用 uni-app可以借助自定义条件编译平台或环境变量来剥离代码块。审核前用开发者工具上传前再做一次代码搜索排查adunit-字符串是否残留。我一般会用全局搜索确认代码包里没有任何ad-unit-id字样再点提交。5.3 留存设计记录、统计与多次抛掷“完美运营”的另一个维度是用户明天还来。抛硬币产品本身娱乐属性弱需要给用户一个回来的理由。最简单的留存钩子是本日统计今天抛了多少次、正面多少次、最多连胜几次。这类轻数据能天然制造“再抛一次试试”的心理驱动。数据存在本地 storage 就够了不需要后端。以下是一段按天维度累计的存储逻辑function recordFlip(result) { const today new Date().toISOString().slice(0, 10); const key flip_${today}; const data wx.getStorageSync(key) || { total: 0, head: 0 }; data.total 1; if (result 正面) data.head 1; wx.setStorageSync(key, data); }存储键按日期生成天然自动过期不需要额外清理逻辑。toISOString使用的是 UTC 日期对国内用户来说晚上 8 点到 12 点之间的记录可能落到“前一天”的桶里。要按本地日期统计建议自行拼接年、月、日或者使用dayjs这类工具库处理时区。6. 上线前的验证技巧用小脚本检查随机分布与广告行为6.1 随机数分布验收在提交审核前我一般在开发者工具的 Console 里跑 10000 次批量随机验证正面占比落在 49%~51% 区间。跑法是用setData无关的独立函数。这个测试要在正式版代码里做而不是专门写一套测试页面因为审核拿到的代码包可能与你测的形态不一致。上线后的前三天把后台的“用户操作次数”和“正面总次数”做一次粗校验如果两者比例偏移超过 3%优先怀疑第三方 SDK 覆盖了 Math.random 方法。6.2 广告重复触发验证与降级开关激励视频广告有一个容易被忽略的运行时问题连续触发两次show()会抛异常。线上用户如果双击按钮会导致第二次调用进入失败回调表现为“点了没反应”。处理方式是在广告对象外部包一层加载锁let adShowing false; function safeShowRewardedVideo(onReward) { if (adShowing) return; adShowing true; showRewardedVideo(() { adShowing false; onReward(); }, () { adShowing false; }); }此外广告拉取失败不能阻断游戏本身。在小程序后台的“流量主”模块里可以查看每个广告位的填充率。如果激励视频填充率持续偏低最直接的影响是用户看完后无法获得奖励口碑直接崩坏。运营侧兜底做法是在show()失败时直接发奖励并且这次失败不发奖励因为用户根本没有看到广告。上线后用另一台手机做真机预览不进开发者工具把币抛上 20 次同时录屏正面与反面数量大致均衡、插屏广告出现的节奏符合预设、激励视频点关闭按钮时没有任何奖励发放。这条链路全绿再点提交审核。审核期间不要更新代码不要动广告位配置尤其不要临时调高插屏频率去测数据。等审核通过后先小流量观察三天广告的 eCPM 与填充率再决定是否调整广告位布局。本文还有配套的精品资源点击获取
