如果你最近关注过“微信小游戏看广告”相关的内容大概率会刷到两种说法一种是玩家视角讨论“玩小游戏看广告领奖励”到底划不划算另一种是开发者视角宣称“做了个微信小游戏靠看广告每天300”。前者是用户体验问题后者是商业化问题。这篇文章不打算讨论玩家怎么薅奖励而是从开发者的角度把这件事讲透微信小游戏里的激励视频广告到底怎么接入Unity 开发的游戏要怎么打包成微信小游戏以及所谓的“每天300”在技术层面和运营层面分别意味着什么。先说结论接入微信小游戏广告组件本身并不复杂真正决定收益的不是代码而是流量量级、用户观看习惯和广告填充情况。如果你正打算做一个微信小游戏并且想通过激励视频广告变现这篇文章可以帮你把账号准备、广告接入、Unity 打包、收益模型、常见坑点和合规要求一次看清楚。1. 这篇文章真正要解决的问题很多独立开发者的第一反应是“我要做一个微信小游戏上线后接入广告就能有被动收入”。这个想法没错但容易忽略两个核心问题。第一广告不是你想接就能接。微信小游戏广告组件有开通条件你需要注册小游戏账号、完成主体认证、满足流量主开通门槛并且使用的广告位 ID 必须和线上版本一一对应。这些流程如果走错最常见的结果是“广告刷不出来”或者“开发环境正常上线后全空白”。第二激励视频广告不是简单放一个“看广告”按钮就完事。它的核心是奖励发放逻辑用户完整看完广告才能拿到道具中途退出不能发奖励广告加载失败要有兜底策略被判定为刷量或诱导后还会影响账号权重。这部分做得不严谨轻则被用户薅羊毛重则被平台判定违规。从技术上看微信小游戏有两种主流开发方式一种是用微信小游戏原生技术栈写 JavaScript 逻辑另一种是用 Unity 开发游戏再通过转换工具打包成微信小游戏。后者是很多游戏团队的选择因为 Unity 的 3D 能力、物理系统和资源管理更成熟。但 Unity 打包微信小游戏有一套独立的适配流程很多第一次接触的人会在“导出 WebGL”“引用微信 SDK”“JS 与 C# 互相调用”这些环节卡住。这篇文章会同时覆盖原生接入和 Unity 打包两条线并给出完整的代码示例。读完你至少能搞清楚四件事广告组件怎么申请、激励视频怎么接入、Unity 工程怎么转成微信小游戏、以及广告收益模型里最关键的变量是什么。2. 微信小游戏广告形态与激励视频原理微信小游戏广告并不是只有一种。从组件类型来看常见的有 banner 广告、插屏广告、激励视频广告和格子广告。它们之间的差异主要在于展示方式、用户主动性和收益量级。广告类型展示方式用户主动性典型场景适合的开发者Banner 广告常驻页面角落或底部被动看到游戏主界面、结算界面追求低打扰、补充收入插屏广告在固定时机全屏弹出被动看到关卡切换、游戏暂停日活较大、页面切换频繁激励视频广告用户主动点击观看主动选择看广告复活、翻倍奖励、每日任务需要设计奖励闭环的游戏格子广告固定的聚合位展示被动看到小游戏大厅、推荐位有一定流量基础后接入为什么大家都在聊“激励视频”因为它的用户主动性最强收益也通常高于其他广告位。它的交互模型是玩家在游戏里触发某个按钮点击后拉起一个视频广告用户必须看完视频并且关闭广告后游戏才给玩家发放奖励。这个“看广告换奖励”的过程对用户来说有明确的收益预期对开发者来说则获得了广告曝光收益而对广告主来说获得了真实的观看用户。理解激励视频广告关键是理解三个回调状态onLoad广告加载成功。只有加载成功后才能调用show展示。onClose广告关闭。关闭时返回一个res对象其中res.isEnded表示用户是否完整播放了视频。onError广告加载或播放失败。奖励发放的依据就是isEnded。如果用户中途退出isEnded为false这时候不应该发奖励。如果用户完整播放isEnded为true再执行发奖逻辑。这个规则必须放到服务端或客户端一起做校验不能只相信前端返回值。很多新手最容易犯的错误是在onClose里直接发奖励然后发现有人通过快速关闭广告也能刷道具。更稳妥的做法是先判断isEnded再结合业务逻辑做幂等处理防止同一个广告位重复发放奖励。3. 环境准备与前置条件不管你是用原生 JavaScript 还是 Unity都需要先准备好以下环境和账号。3.1 微信小游戏账号与流量主第一步是注册一个微信小游戏账号。个人和企业的申请流程略有不同但都需要完成主体信息填写和认证。小游戏账号和普通小程序账号是分开的注册时要选择“小游戏”类目。广告组件想产生收益必须开通“流量主”。微信平台对流量主有开通条件要求比如累计用户数达到某个门槛后才能申请。具体门槛数值会随平台规则调整不建议作为技术依赖。你可以先开发好游戏积累一定的测试用户后再申请开通。需要注意的是开通流量主后你需要在小游戏后台创建广告位。每一个广告位会生成一个唯一的adUnitId这个 ID 是广告接入的关键参数。在开发环境测试时可以使用测试广告位 ID但不能直接用于线上线上广告位 ID 必须在正式发布前替换。3.2 开发工具无论哪种开发方式都需要安装微信开发者工具。它用于预览小游戏、查看日志、上传代码和调试真机效果。如果你使用 Unity还需要安装 Unity Editor并确保版本和微信小游戏转换工具兼容。建议以官方工具当前支持的版本为准本文演示核心链路不绑定某个具体版本。对于原生 JavaScript 开发一个文本编辑器加微信开发者工具就够了。对于 Unity 开发你还需要理解一个概念微信小游戏并不直接运行 Unity 的 PC/移动工程而是要求 Unity 先导出 WebGL 版本再通过适配转换工具生成微信小游戏可识别的包结构。这个转换过程会涉及资源压缩、代码裁剪、JS 桥接等属于工程化层面的额外成本。3.3 基础库要求微信小游戏的广告 API 依赖基础库版本。如果你的游戏环境基础库过低wx.createRewardedVideoAd等方法可能不存在。在真机预览时建议先查看微信开发者工具中当前基础库版本并在代码里做兼容判断。后面示例代码里会有wx.createRewardedVideoAd是否存在的能力检测这个判断属于防御式写法真机测试时能节省大量排查时间。4. 原生微信小游戏接入激励视频广告这里先讲原生 JavaScript 接入方式因为它是理解广告组件最直接的方式。后面 Unity 打包场景也需要依赖同样的逻辑。4.1 创建广告实例在微信小游戏入口文件通常为game.js中通过wx.createRewardedVideoAd创建广告实例。示例代码如下// 文件路径minigame/js/rewarded-video.js let videoAd null; function initRewardedVideoAd() { if (!wx.createRewardedVideoAd) { console.warn(当前基础库不支持激励视频广告); return; } videoAd wx.createRewardedVideoAd({ adUnitId: adunit-xxxxxxxxxx // 替换为后台申请的广告位 ID }); videoAd.onLoad(() { console.log(激励视频广告加载成功); }); videoAd.onError((err) { console.error(激励视频广告加载失败, err); }); videoAd.onClose((res) { if (res res.isEnded) { // 用户完整看完视频触发奖励 onRewardedVideoComplete(); } else { // 用户中途关闭不发放奖励 showToast(看完视频才能领取奖励哦); } }); }这段代码包含三件事创建广告、监听生命周期、判断是否完整播放。adUnitId必须替换成你在微信后台创建的广告位 ID否则广告组件无法正确定位到归属账号。4.2 展示广告与加载兜底在需要用户点击“看广告领奖励”的位置调用show展示广告。但不是每次调用show都能直接成功如果广告还没加载好show会返回失败。因此需要做一次加载兜底。// 文件路径minigame/js/rewarded-video.js function showRewardedVideoAd() { if (!videoAd) { initRewardedVideoAd(); } if (!videoAd) { showToast(广告组件初始化失败); return; } videoAd.show().catch(() { // 展示失败时重新加载 videoAd.load() .then(() videoAd.show()) .catch((err) { console.error(广告重新加载失败, err); showToast(广告加载中请稍后再试); }); }); }这段代码是线上项目里比较稳的写法先尝试展示失败后再加载一次再展示。如果加载失败至少要给用户一个友好提示不能直接卡在按钮上。4.3 发放奖励与幂等控制这里的核心原则是只有onClose中res.isEnded true才发奖励。但在实际项目中还需要防止用户反复点击按钮同一个任务触发多次广告和多次奖励。更好的做法是在业务层加一个状态锁。// 文件路径minigame/js/rewarded-video.js let isRewarding false; function onRewardedVideoComplete() { if (isRewarding) { console.warn(正在发放奖励请勿重复操作); return; } isRewarding true; // 这里执行真正的奖励发放逻辑 // 例如增加金币、解锁道具、领取体力 grantGameReward(); // 发放完成后解锁状态 setTimeout(() { isRewarding false; }, 300); }这段代码的核心是isRewarding状态锁。它避免用户在奖励回调触发期间再次点击广告按钮导致同一个广告位发放多份奖励。更严格的做法是把奖励发放逻辑放到服务端通过用户身份和业务单号实现幂等客户端只负责展示广告并上报结果。5. Unity 微信小游戏打包与广告桥接很多团队不会用原生 JavaScript 开发游戏而是使用 Unity。Unity 项目要跑在微信小游戏环境里需要经过一次打包转换。下面重点讲清楚这条链路。5.1 Unity 导出 WebGL 与微信小游戏适配Unity 官方支持导出 WebGL 平台但微信小游戏环境并不是完整的浏览器环境它没有普通浏览器里的 DOM、Window 对象也没有完整 WebGL API。因此从 Unity 到微信小游戏并不是简单地把 WebGL 产物塞进去而是要通过适配层把微信环境的能力映射给 Unity WebGL 运行时。常用做法是先在 Unity 中把目标平台切换到 WebGL完成一次 WebGL 构建然后使用微信小游戏的适配工具或插件将构建产物转换成微信小游戏可识别的目录结构并注入微信 API 的桥接代码。这个转换过程会处理文件路径、分包加载、内存管理等细节。具体工具名称和版本建议以微信官方或 Unity 官方当前提供的方案为准因为这类工具更新较快写死了反而容易误导。5.2 Unity 调微信广告的桥接代码Unity 环境中没办法直接写wx.createRewardedVideoAd因为 C# 代码运行在 Unity 引擎里而微信小游戏的wx对象属于小游戏运行时。通常需要在 JavaScript 侧暴露一个全局函数再通过 Unity WebGL 的jslib机制调用该函数。下面给出一个常见的.jslib文件示例。这个文件可以放在 Unity 项目的Assets/Plugins/WebGL目录下并在 C# 脚本中通过DllImport声明外部函数。// 文件路径Assets/Plugins/WebGL/RewardedVideoBridge.jslib mergeInto(LibraryManager.library, { JSShowRewardedVideo: function () { if (typeof wx ! undefined) { if (typeof window.showRewardedVideo function) { window.showRewardedVideo(); } } } });同时你需要在微信小游戏环境里的入口脚本中定义window.showRewardedVideo。这样做的好处是 Unity 侧调用桥接函数时最终执行的是小游戏环境里的完整广告逻辑。对应的 C# 侧代码可以这样写// 文件路径Assets/Scripts/RewardedVideoWrapper.cs using System.Runtime.InteropServices; using UnityEngine; public class RewardedVideoWrapper : MonoBehaviour { [DllImport(__Internal)] private static extern void JSShowRewardedVideo(); public void ShowRewardedVideo() { #if UNITY_WEBGL !UNITY_EDITOR JSShowRewardedVideo(); #else Debug.Log(当前环境不支持直接调用广告桥接方法); // 在编辑器里可以做模拟处理方便测试游戏流程 #endif } }这里的关键是#if UNITY_WEBGL !UNITY_EDITOR条件编译。编辑器里没有微信环境直接调用JSShowRewardedVideo会报错因此需要做环境判断。5.3 奖励回调到 Unity完整流程不能只有 Unity 调 JS还要让 JS 侧广告回调通知 Unity。最简单的方式是在 JS 逻辑里调用 Unity 的SendMessage把广告结果发给 Unity 场景中的某个 GameObject。假设 Unity 场景中有一个名为GameManager的对象挂载了RewardHandler脚本那么 JS 侧可以在onClose回调中这样调用// 文件路径minigame/js/ad-bridge.js videoAd.onClose((res) { if (res res.isEnded) { // 通知 Unity 发放奖励 if (typeof unityInstance ! undefined) { unityInstance.SendMessage(GameManager, OnRewardedVideoComplete, ); } } });对应的 C# 接收方法如下// 文件路径Assets/Scripts/RewardHandler.cs using UnityEngine; public class RewardHandler : MonoBehaviour { public void OnRewardedVideoComplete(string message) { Debug.Log(激励视频完整播放开始发放奖励); // 在这里调用游戏内的发奖逻辑 // 比如给用户增加钻石、金币或解锁关卡 } }这种方式简单直观适合中小型小游戏。但要注意SendMessage的名称和参数要与 Unity 侧保持一致哪怕只是大小写不同也会导致回调失败。调试时建议在微信开发者工具 Console 里打印日志确认回调是否进入 Unity。6. 如何评估“看广告每天300”的收益模型技术接入完成后你需要理解收入从哪来。微信小游戏广告收益并不是按“看几次广告给几次钱”这种固定方式计算而是通过 eCPM每千次展示收益来估算。收益公式可以简化成日收益 ≈ DAU × 人均激励视频观看次数 × eCPM / 1000其中DAU日活跃用户数。人均激励视频观看次数代表每个用户平均每天完整观看多少次激励视频。eCPM每千次广告展示预估收益。这个值受广告主出价、用户地区、广告内容、平台分成等因素影响波动很大。举个例子。假设你的小游戏日活跃用户是 3000 人平均每人每天完整观看 3 次激励视频那么每天的总展示次数约为 9000 次。如果广告 eCPM 是 30 元那么日收益约为3000 × 3 × 30 / 1000 270 元。DAU人均观看次数eCPM元日收益估算元100023060300033027050003304503000530450注意表格里的 eCPM 是演示假设不代表实际水平。真实 eCPM 会受到广告主投放策略、用户价值、广告填充率、节日周期等多方面影响。网上宣传的“每天300”通常是某个运营状态下的结果不是接入广告后必然达到的水平。如果把这个公式反过来看你就能理解为什么很多小游戏赚不到钱要么是 DAU 不够要么是人均观看次数太低要么是 eCPM 一直很低。广告接入只是把流量转化为收益的通道流量本身才是核心资产。激励视频的人均观看次数又取决于游戏设计。比如游戏里如果设计了“看广告复活”“看广告加时”“看广告翻倍奖励”这些强需求入口用户观看次数自然会更高。反之如果广告只是无意义地弹出来用户不会主动点填充率再高也白搭。7. 常见问题与排查思路广告接入和 Unity 打包过程中有一些高频问题值得单独列出来。下表是实际开发中最常遇到的问题、可能原因和排查方向。问题现象可能原因排查方式解决方案广告组件加载失败adUnitId 错误、广告位未开通、基础库版本过低查看开发者工具 Console 的 error 日志检查广告位 ID确认流量主已开通升级基础库wx.createRewardedVideoAd不存在基础库版本过低或非小游戏环境打印wx对象信息通过能力检测做兼容处理并更新基础库版本Unity 中点击按钮没反应JS 桥接方法未注册、jslib 路径不对在小游戏 Console 打印全局函数是否存在确认window.showRewardedVideo已定义SendMessage 回调失败GameObject 名称或方法名不一致检查 Unity 场景对象名称查看 Console 报错统一命名并在 JS 侧打印调用日志用户中途关闭广告仍获得奖励奖励发放条件判断有误检查onClose中的res.isEnded逻辑只有isEnded true才发奖励广告填充率长期偏低广告主投放不足、用户地区或时段影响观察后台广告填充率报表优化用户分布尝试不同广告位组合上线后广告不显示开发环境正常线上版本未替换正式广告位 ID检查后台线上版本广告位配置替换为线上 adUnitId并上传最新版本小游戏包体积过大Unity 导出资源未压缩查看构建日志和包体报告做资源压缩、分包加载、移除无用素材排查广告问题时第一件事永远是打开微信开发者工具的 Console 面板。广告组件所有的错误提示都会输出在这里。通过错误码和错误信息往往能快速定位到是账号权限问题、参数问题还是环境问题。对于 Unity 打包场景第二件事就是确认小游戏环境里是否存在wx对象。有些转换工具处理不当会导致 Unity 侧调用的全局函数没有挂载到小游戏运行时的window上。你可以在小游戏入口脚本里加一行日志先确认全局桥接函数是否已经存在再继续排查广告逻辑。8. 最佳实践与工程建议广告接入虽然门槛不高但要想做得稳、减少后期风险最好从一开始就遵守下面这些工程和设计原则。第一奖励发放要具备幂等性。客户端状态锁只能防住手速快的用户防不住接口重放。如果你的游戏有服务端建议把奖励发放和广告展示结果绑定用业务订单号做唯一校验。这样即使客户端重复调用发奖接口服务端也能拒绝重复发放。第二不要诱导或强制用户看广告。微信对诱导点击、强制观看、遮挡广告等行为有明确治理逻辑。广告出现的位置和频次要尊重用户体验否则容易出现投诉、封禁广告权限等风险。第三预留广告失败时的游戏路径。当广告加载失败、用户网络中断或者平台无填充时玩家的游戏任务不能被卡死。比如看广告复活失败要允许用户用金币或者等待时间代替看广告领奖励失败要允许用户稍后重试。用户体验不好才真的会流失。第四Unity 打包要注意资源体积和加载时间。微信小游戏对首包体积和启动时间比较敏感。Unity 工程里不要一股脑把大模型、多套贴图全部打进包内合理的做法是先做资源分类再用分包加载的方式渐进式加载。首包越小广告能触达的用户规模才越大。第五关注广告位数据而不是只看收益。后台的展示量、填充率、人均观看次数、eCPM 每一项都值得独立分析。收益下降的时候不要只怀疑代码改了先看填充率和 eCPM 是否波动。很多收益问题其实是市场投放侧的波动和你的代码无关。第六内容合规设计。游戏内的奖励设计、公告文案、隐私说明都需要遵守微信小游戏运营规范。尤其涉及用户虚拟财产奖励时要明确说明奖励的获取和使用边界避免产生纠纷。9. 总结与后续学习方向回到文章标题“微信小游戏看广告每天300”你应该已经理解这个数字不是一个固定的技术结果而是一个经营目标。技术接入解决的是“能不能展示广告”的问题流量和产品设计解决的是“能赚多少钱”的问题。本文讲清了微信小游戏激励视频广告的完整接入逻辑包括广告实例创建、播放完成判断、奖励发放、Unity 打包转换和 JS/C# 桥接并给出了收益估算公式和常见问题排查思路。如果你正准备做一个微信小游戏下一步最值得做的事是先跑通一个包含激励视频的最小 Demo用自己的小游戏账号在开发者工具里完成一次完整的“加载广告—完整播放—发放奖励”流程然后再考虑把 Unity 游戏转换进小游戏环境。技术层面继续深入可以研究微信广告的服务端回调、订单校验、分包策略和性能优化产品层面则可以关注激励视频的触发点设计、用户留存和广告频率控制。这些内容单独拿出来都能写出一篇新的实战文章以后有机会再逐一拆解。建议先把本文收藏等做到账号申请和广告接入那一步时对照着操作一遍。第一次跑通后后面的迭代会平滑很多。