简介：这份资源是一套可直接运行的「抛硬币」微信小程序源码，主要面向想快速上手小程序开发、或希望了解流量主变现方式的开发者。小程序提供随机正反面结果，适合日常决策、趣味互动等场景，结构简洁，无需配置合法域名，用微信开发者工具即可打开运行。压缩包共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 class="coin-wrap" @tap="handleTap"> <view class="coin" :class="{ flipped: isFlipped }"> <view class="coin-face front">{{ result }}</view> <view class="coin-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.random
3.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-if="showBanner" unit-id="adunit-xxxxxxxxxxxxxxxx" ad-type="banner" @load="onAdLoaded" @error="onAdError" ></ad>onAdError(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 与填充率，再决定是否调整广告位布局。
本文还有配套的精品资源，点击获取
