激励视频赚金币小程序开源项目：Spring Boot+uniapp前后端分离实战

说实话身边找我咨询“看广告赚金币”类小程序怎么做的人一直没断过。这类项目的吸引力很直接——用户有薅羊毛的冲动广告主有曝光需求而小程序本身又能借助微信生态快速传播看起来是“三方共赢”。但真正下场做过的人都知道这里面的坑比想象中深得多平台审核越来越严、动不动封禁、用户数据隐私要求高稍有不慎项目就没了。我前阵子正好梳理了一套可以直接跑起来的前后端分离开源项目把容易踩雷的地方全部做了“脱敏”处理同时尽量保证“易过审”。这里说的脱敏指的是用户数据层面的隐私保護而“易过审”则是从产品设计到代码实现都遵守微信小程序平台的规则不跟审核底线对着干。先说一句最重要的话这个项目里没有“自动看广告”这种作弊逻辑。用户手动点击观看激励视频服务端校验真实性后发放积分这套路径才走得通。把“自动”理解为“业务流程自动化”比如自动发奖、自动核销、自动分账这才是良性循环。1. 项目整体设计与思路拆解1.1 这类项目的真实生态与风险边界很多人一听到“看广告赚金币”脑子里浮现的是用户疯狂刷视频、金币余额飞涨、平台靠广告分成躺赚的画面。但现实里能长期运营的同类项目没有一个敢把“刷量”当成核心竞争力。激励广告的本质是用户用注意力换福利广告主为有效曝光付费。如果开发者通过脚本、模拟点击、虚拟机批量操作等方式伪造观看行为轻则广告主拒付甚至追偿重则平台直接封号、清退小程序还可能因为涉嫌破坏计算机信息系统、诈骗等被追究法律责任。所以项目设计的第一原则就是采用“用户主动触发 服务端二次校验”的激励视频模式。在我这个开源项目里广告播放使用的是微信官方流量主组件由微信侧控制广告真实展示。小程序端只负责在用户点击“领取奖励”按钮后拉起广告广告关闭后把回调结果上报给后端后端校验广告位 ID、用户状态、领取频次之后再做积分入账。整个过程没有人去伪造设备、模拟点击安全性上有保障。这样的设计还有一个隐藏优势真正的人工观看行为在微信广告系统里是健康的流量流量主也就是你自己的小程序的 ecpm 会被判定为优质长期来看广告单价更稳定。反过来刷量号的 ecpm 会被持续压低甚至被联盟拉黑得不偿失。1.2 把“VIP分红”翻译成合规产品语言标题里的“VIP分红”听起来很有吸引力但也非常敏感。如果真做成“用户充值成为VIP然后按平台收入分红”或者“邀请好友获得下线返利”大概率会被平台判定为传销或资金盘直接封禁账号基本没商量。在这个开源项目里我把这套逻辑翻译成了两个完全合规的模块VIP会员等级用户通过完成日常任务、累计签到获取成长值等级越高单次任务积分加成越高、兑换商品折扣越大。每日权益平台可以把某一天的部分广告收入拿出来转换成“积分返场活动”或者“限时兑换券”以福利形式返还给活跃用户。本质上用户确实享受到了“分红”的获得感——平台赚到广告费拿出一部分回馈用户——但产品层面不出现“投资、返利、层级、下线”这些字眼也没有真实的现金分红链路。这样既保留了运营的吸引力又不触碰监管红线。1.3 开源技术选型背后的思考整个项目采用前后端分离架构这也是目前中小团队最熟悉、最容易招人的组合。后端选择 Spring Boot 3 MyBatis-Plus Redis MySQL。Spring Boot 生态成熟MyBatis-Plus 能少写很多 CRUD 模板代码Redis 用来做积分任务的频控和热点数据缓存MySQL 负责核心业务数据持久化。前端选择 uniapp 一套代码编译到微信小程序后续如果想同步输出支付宝小程序、抖音小程序改造成本也很低。为什么不直接用云开发微信云开发的广告组件和用户鉴权确实方便但它的问题在于云函数调试相对繁琐而且如果你自己做的是开源项目很多开发者手头没有云环境直接用 MySQL 本地接口反而更容易部署。所以我的方案是后端代码完全本地化前端通过配置项切换接口地址个人开发者一台普通服务器就能跑起来。2. 核心细节解析与实操要点2.1 积分任务防刷设计自己给自己省心积分结算这种事看起来简单但并发一上来全是问题。最典型的就是用户重复点击、多点几次领取按钮然后绕过广告回调直接要求发奖。我在项目里做了三层防线第一层是小程序端限制。点击领取后按钮置灰进入 loading 状态广告关闭前不允许再次操作。这层防不住有意作弊的人但能挡住大部分误操作。第二层是后端接口防重。每个用户的领取请求携带一个由后端下发的 taskToken这个 token 在 Redis 里设置 10 分钟有效期并绑定用户ID和任务ID。用户观看完广告后前端把广告回调的 channelId 和 taskToken 一起提交后端校验 token 存在且未被使用后才入账。由于 Redis 的 key 是唯一的天然规避了同一任务重复领取的问题。第三层是频控。普通用户一天能完成的任务次数有限我在 Redis 里维护了按天维度的计数器任务中心定义每日上限。比如广告任务每天最多 30 次、签到任务每天 1 次超过就直接返回“今日次数已用完”。这层既防止刷量也保护广告主利益属于双赢。2.2 积分账户与流水的数据一致性积分属于资产类数据不能直接每次做增减否则对账的时候想死的心都有。我设计了“积分账户 积分流水”两张表所有变动都必须写流水。用户积分的查询走 Redis 缓存热点用户查询不到时再回源数据库。积分的变动走 MySQL 事务先插入流水表再更新账户余额两件事必须同时成功。为了避免脏读账户表的余额字段在更新时用乐观锁校验版本号一旦版本号冲突说明有并发提交该次更新重试。对于兑换消费我还加了一个“锁定积分”的逻辑用户兑换商品时先把所需积分从余额转入锁定金额订单状态为“处理中”发货成功后锁定金额清零订单状态改为“已完成”。如果用户主动取消订单锁定金额退回余额。这套逻辑跟电商支付流程很像刚开始会觉得麻烦但实际运营中能少吵无数架。2.3 数据脱敏不是简单打码标题里的“脱敏”其实是这个项目中最值得展开的部分。微信小程序开发中开发者可获取到的用户信息越来越少但即便如此手机号、头像、昵称、openid 依然属于敏感数据。我的处理方式分三层存储层openid 不直接明文存数据库使用 AES 加密后存储密钥放在服务端环境变量中。手机号通过前端获取微信绑定的手机号后仅保留区号 后四位用于展示完整号码直接丢弃不落库。接口层所有接口输出前统一经过脱敏组件处理。昵称包含手机号、身份证等敏感信息时自动替换为星号。日志打印方面项目里统一使用 MDC 过滤机制日志中禁止输出 token、手机号、openid 的完整值。传输层全站接口统一走 HTTPS每次请求携带 AppId 时间戳 签名后端验签后拒绝过期或重放请求。签名算法采用 HMAC-SHA256密钥只保存在服务端。这样处理后即使数据库被拖库或者日志泄露攻击者拿到的也是密文和脱敏数据难以还原真实用户信息。这也是“易过审”的重要技术支撑毕竟隐私保护是小程序审核的核心考察项。3. 实操过程与核心环节实现3.1 数据库表设计先把地基打牢项目核心表一共 6 张加一个定时任务用的数据字典表结构如下user_account用户账户表记录用户ID、openid加密、昵称脱敏、总积分、锁定积分、会员等级、成长值、状态、创建时间等。task_info任务信息表定义任务名称、任务类型签到、广告、邀请、活动、单次奖励积分数、每日上限、状态、生效时间。user_task_record用户任务完成记录表记录 userId、taskId、完成时间、来源广告位ID、taskToken。user_points_log积分流水表记录变动积分、变动类型签到、广告奖励、兑换消费、退款退回、活动赠送、变动后余额、关联单号。exchange_order兑换订单表记录用户兑换的商品、消耗积分、收货信息脱敏、状态、发货时间。user_member_level会员等级配置表等级编号、等级名称、成长值下限、任务奖励倍率、兑换折扣。这里面有几个字段要特别解释一下。taskToken 字段是服务端下发的唯一令牌用来防重复领取。它在 Redis 里存一份数据库里也留一份防止极端情况下 Redis 数据丢失导致对账失败。openid 字段存储的是加密串而不是明文。这样即使你以后把项目交给其他人维护也不会出现 openid 被滥用的问题。没提表之间的外键关系我自己做项目从来不用物理外键全部靠逻辑关联。原因很简单MySQL 在分布式拆分和迁移的时候物理外键是负担不建外键反而灵活。3.2 核心后端接口与代码片段整个后端接口设计围绕几个核心链路登录、任务列表、领取任务、广告回调上报、积分入账、兑换下单。以“广告任务完成上报”为例接口思路是PostMapping(/api/task/ad/report) public ResultVoid reportAdTask(RequestBody AdTaskReportDTO dto) { // 1. 校验签名与用户状态 LoginUser user UserContext.get(); if (user null) { return Result.error(401, 未登录); } // 2. 校验广告位ID是否属于当前小程序 if (!adConfigService.isValidAdUnit(dto.getAdUnitId())) { return Result.error(400, 非法广告位); } // 3. 校验taskToken是否存在且未使用 String tokenKey ad:task: dto.getTaskToken(); Boolean used redisTemplate.hasKey(tokenKey); if (used null || !used) { return Result.error(400, 任务凭证无效或已过期); } // 4. 校验用户今日该任务次数是否达上限 String countKey ad:cnt: user.getId() : LocalDate.now(); Long count redisTemplate.opsForValue().increment(countKey); if (count ! null count taskInfo.getDailyLimit()) { return Result.error(400, 今日任务次数已用完); } // 5. 事务内写入任务记录与积分流水 return taskService.addReward(user, taskInfo, dto); }这个接口的关键点在 Redis 的原子自增天然防止了高并发下超发。而 taskToken 的校验放在事务外先校验后入账能拦截 95% 以上的重复请求。我再补一个积分入账的 Service 核心代码可以看到事务和乐观锁的应用Transactional(rollbackFor Exception.class) public ResultVoid addReward(LoginUser user, TaskInfo taskInfo, AdTaskReportDTO dto) { // 锁定用户账户 UserAccount account userAccountMapper.selectByIdForUpdate(user.getId()); if (account null) { throw new BizException(账户不存在); } // 计算实际奖励积分这里会乘上会员等级倍率 int rewardPoints calculateReward(taskInfo, account.getMemberLevel()); // 写入任务记录 UserTaskRecord record new UserTaskRecord(); record.setUserId(user.getId()); record.setTaskId(taskInfo.getId()); record.setSourceAdUnitId(dto.getAdUnitId()); record.setTaskToken(dto.getTaskToken()); userTaskRecordMapper.insert(record); // 写入积分流水 UserPointsLog log new UserPointsLog(); log.setUserId(user.getId()); log.setPoints(rewardPoints); log.setChangeType(ad_reward); log.setBalanceAfter(account.getPoints() rewardPoints); log.setBizOrderNo(dto.getTaskToken()); userPointsLogMapper.insert(log); // 更新账户余额使用版本号乐观锁 int updated userAccountMapper.updatePointsWithVersion( user.getId(), account.getPoints() rewardPoints, account.getVersion() ); if (updated 0) { throw new BizException(账户更新冲突请重试); } // 同步更新缓存 redisTemplate.opsForValue().set( points:user: user.getId(), String.valueOf(account.getPoints() rewardPoints) ); return Result.success(); }注意 selectByIdForUpdate 会锁行保证同一时刻只有一个线程能读到一个账户的余额。配合乐观锁的版本号字段双保险效果非常稳。3.3 前端激励视频组件使用注意事项前端部分使用 uniapp在微信小程序端本质是调用 wx.createRewardedVideoAd 这个 API。有一点要特别注意同一个激励视频广告对象最好做成全局单例不要每次调用都重新创建并且要在用户点击事件回调里调用 show() 方法。这是因为微信小程序要求激励视频必须由用户主动触发如果 onLoad 里静默调起广告大概率会被判定为骚扰式广告。代码示例// 全局激励视频广告管理器 export class RewardedVideoManager { constructor(adUnitId) { this.adUnitId adUnitId this.ad null } load() { if (!this.ad) { this.ad wx.createRewardedVideoAd({ adUnitId: this.adUnitId }) this.ad.onError((err) { console.log(广告加载失败, err) }) } return this.ad.load() } show() { // 需要在用户click事件中调用 return new Promise((resolve, reject) { this.load().then(() { this.ad.show().catch(() { this.ad.load().then(() this.ad.show()).catch(reject) }) }) this.ad.onClose((res) { if (res res.isEnded) { resolve(true) } else { resolve(false) } }) }) } }用户在页面里点击“观看广告领取奖励”按钮后才执行 show()广告正常播完拿到 isEndedtrue 的结果再调后端上报接口。如果用户中途关闭广告isEndedfalse就不给积分。这种前后端闭环的设计跟微信官方要求的“完整观看”完全对齐。还有一个容易忽略的点广告回调上报有时间窗口最好在广告关闭后 3 秒内上报。因为 taskToken 是有有效期的拖太久容易过期而过期后重新领 token 又要让用户再点一次体验很差。3.4 项目部署与目录结构开源仓库里的目录结构如下backendSpring Boot 后端服务frontenduniapp 前端工程sql数据库初始化脚本docs接口文档与部署文档后端部署到一台 2核4G 的服务器就够安装 JDK 17、MySQL 8.0、Redis 7。前端使用 HBuilderX 打包后在微信开发者工具中导入并配置 AppID。小程序后台要开通流量主并创建激励视频广告位拿到 adUnitId 后填到前端配置文件中。部署的核心流程初始化数据库执行 sql/init.sql。修改 application.yml 里的数据库账号、Redis 密码、AES 密钥、微信小程序 AppSecret。执行 mvn package 打包java -jar 启动后端服务。前端 config.js 中修改接口地址为后端域名必须是 HTTPS 且在小程序后台配置 request 合法域名。上传体验版测试登录、任务、兑换全流程后提交审核。整个流程熟练的话两个小时能从零到上线这也是开源项目最大的优势不需要重复造轮子。4. 常见问题与排查技巧实录4.1 微信审核被拒的高频原因速查小程序审核确实严格但大多数被拒都有规律可循。根据我自己和身边朋友的经验原因集中在以下几条审核拒绝原因问题本质解决方案涉及虚拟支付用人民币买虚拟商品虚拟权益一律用积分兑换不出现真实货币购买入口诱导分享/分享得奖励分享后才有积分奖励不要强制诱导分享改为“分享后可查看活动页”这种弱引导涉及分销/返利层级返佣、下线返利模式保留邀请好友的入口但只奖励一次邀请积分不做层层返佣隐私不合规过度收集用户信息只获取必要信息手机号解密后不落库广告组件违规自动播放、强制观看全部激励视频必须手动点击触发我见过很多人被拒之后反复提交改三天三夜还过不了结果就是没搞懂审核的重点是“模式”而不是“代码”。你代码写得再漂亮如果产品逻辑天生和微信生态相悖一样白搭。4.2 “自动看广告”被封禁的真实教训这里要特别提醒一下对“自动化薅广告羊毛”感兴趣的朋友我接触过几个因刷量被封的真实案例。有一位老哥写了脚本通过抓包拿到广告关闭的回调参数直接模拟请求上报后端实现“不看广告也能领积分”。刚开始确实刷了几千块广告分成结果不到一个月微信风控检测到广告点击率异常、转化率为零、时段集中在凌晨直接封了流量主账户连带小程序被封禁。平台还发函要求说明情况那叫一个难受。更麻烦的是封禁之后不仅广告分成拿不到已经提现的部分也可能被要求退款甚至被广告联盟拉入黑名单以后想再申请流量主就难了。所以我在项目文档里反复强调任何绕开真实广告播放的自动化操作都是在刀尖上跳舞。你以为是技术上的成熟套路实际上是把自己送进风险名单。真正的自动化应该体现在发货、对账、风控这些后端流程上而不是去伪造用户行为。4.3 虚拟支付、积分兑换与变现合规很多新人会踩一个大坑积分兑换的商品用了现金定价或者积分本身可以反向兑换成人民币。这在小程序生态里非常危险。微信明确规定小程序虚拟支付功能需要特定类目资质支持普通个人主体基本没有开通条件。如果做的是虚拟商品、会员卡、在线课程这类东西最容易在支付环节被卡死。我的做法是积分兑换完全只兑换实物或虚拟权益码比如优惠券码、兑换卡密。用户提交兑换订单时填写收货地址由运营在后台人工发货。整个过程不涉及小程序内虚拟支付因此绕开了微信支付类目的限制审核难度直线下降。如果非要让用户花钱买积分或会员我会把购买动作引导到 H5 页面或外部商城去完成不在小程序内核心里做收款。这在体验上多了一步但在合规性上安全很多。4.4 数据脱敏中的那些隐藏坑数据脱敏看着简单实际上一不留神就翻车。我举几个真实的坑第一日志脱敏不是只处理系统输出日志。很多框架的全局异常处理器会把请求参数原样打印出来里面可能就带着用户手机号、openid 和 token。我的做法是在异常处理器里对 RequestBody 和 QueryParam 做统一过滤凡是指定为敏感字段的 key 全部替换为***。第二数据库脱敏后的数据在开发环境要能识别。有一次团队成员从生产数据库导了一份数据到测试库调试里面全是被 AES 加密的 openid导致本地开发登录时怎么都对不上。后来我加了脱敏标识位加解密工具类的环境判断测试库可以配置自动解密生产库默认不解密。第三微信手机号快速验证组件解密后的手机号要立即处理不要让明文在内存和异步线程里多待一秒。明文手机号出现在日志、消息队列、临时文件中的情况我见过不少这不仅是技术失误在《个人信息保护法》框架下还面临合规风险。5. 项目后续还可以怎么扩展这个开源项目当前版本做的是闭环的积分任务系统但它的扩展空间其实很大。可以把积分升级为多币种体系比如金币、成长值、能量值分别对应不同的业务目的。金币用来兑换成长值决定等级能量值作为参与活动的门票。这样运营手段更丰富用户粘性也会更好。可以接入用户签到提醒利用订阅消息每天定时提醒用户回来打卡。激励视频任务本身是低频场景如果能把拉新和召回结合起来项目生命周期会拉长很多。如果后端压力大了可以把任务中心的配置迁移到 Nacos 或 Apollo通过配置中心动态调整任务奖励而不需要重启服务。针对大规模用户数据库可以引入分表策略积分流水表按 userId 做哈希分表日志和任务记录表按天分表。我个人在实际操作中最受益的一个习惯是每次上线前都会过一遍广告任务接口的并发测试。模拟 100 个用户同时点击领取任务看 Redis 计数器和小程序接口返回的成功率。既测试了接口稳定性也能在源头上发现防重逻辑是不是真的有 bug。做这类项目稳定压倒一切宁可功能少一点也不能让用户觉得“积分又少了”或者“广告白看了”。