小程序积分任务系统开源：广告变现与防刷设计全解析

前阵子把一套积分任务类小程序完整地开源了出来前后端代码都在仓库里。项目标题是自动看广告赚金币VIP分红兑换小程序脱敏易过审前后端开源看起来很长其实就是一套围绕激励视频广告积分任务会员权益兑换发货做出来的完整业务闭环。很多人看到自动两个字就兴奋看到VIP分红就警惕看到脱敏易过审就想知道怎么避开审核坑。这篇文章我打算把整个项目从设计思路到落地实现再到开源仓库的整理方法一次讲透。讲之前先立个规矩标题里的自动指的是广告任务从创建、播放、回调校验到金币入账的全流程自动化是后端风控与状态机的自动化处理绝不是教人用脚本去造假数据、刷平台广告收益。平台规则是红线这类灰产操作碰都别碰。你把这套系统的防刷设计看明白就知道为什么脚本刷量在架构层面就活不下来。这篇内容适合谁看适合正在做小程序积分任务、广告变现、会员体系的开发者也适合手里有流量想做产品化落地、但被审核和风控卡住的人。前后端完整思路都会讲到代码结构也会拆开说看完可以直接拿去改造成自己的项目。1. 项目整体设计思路拆解1.1 这类任务激励小程序解决了什么问题做小程序最难受的一件事就是留存。用户进来一次就再也不打开广告收益、转化率、品牌曝光全成了空话。任务激励体系的本质是给用户一个每天回来做点小事的理由。看一条激励视频得20积分连续签到7天送额外奖励邀请一个新用户注册得50积分攒够一定积分可以兑换实物或虚拟权益。这套玩法的核心不是那几毛钱的广告收益而是把用户回访频率拉起来让产品有继续运营下去的流量基础。这个项目的目标用户非常明确想快速启动积分任务体系的小团队或个人开发者。你不需要从零开始设计数据库、写防刷逻辑、搭后台管理仓库里已经有一套能跑通前后端的代码。我当时的考量是与其做一个只有展示效果的demo不如把真实运营会遇到的问题都先埋进设计里比如金币流水怎么记账才不会乱、广告回调怎么验真、VIP权益怎么和普通用户拉开差距、兑换订单怎么走审核流程。这些问题不解决功能上线一个星期就会出乱子。做这类项目还有一个容易忽略的点就是规则透明。用户能清楚看到自己为什么获得积分、为什么被限制。所以整套系统的设计原则是所有的奖励发放和扣除必须有一张明细可查的流水表任何一笔账都能追溯到来源。这一点不仅是用户体验问题也是审核合规的基本要求。1.2 自动背后是一套任务状态机很多做这类功能的人第一反应就是在小程序端写一个播放广告-发奖励的流程看起来简单实际上漏掉了很多关键环节。广告播放不一定成功播放了不一定看完看完了不一定能拿到回调回调到了不一定能立刻发奖——这中间任何一个环节断了用户就会遇到看了广告没到账的投诉。我在这套项目里把自动看广告实现为一条清晰的状态流转链路任务创建后进入初始状态前端发起广告播放请求后端记录本次请求并返回一个带过期时间的任务ID广告播放过程中前端监听激励视频的回调事件拿到结果后再调用后端的确认接口后端拿到确认请求后先校验任务ID是否存在、是否属于当前用户、是否已经发放过奖励再结合广告平台回传的凭证信息做二次校验最后才把金币写入用户账户并生成流水记录。这套流程跑通了之后用户的体验就是点一下广告、看完、金币自动到账不需要任何手动操作。你的工作重心全部放在异常路径上广告加载失败怎么办、用户中途退出怎么办、回调参数缺失怎么办、同一任务重复确认怎么办。我把这些异常状态全部落进任务表里用状态机统一管理每个状态都有对应的处理逻辑。这样系统才能稳定运行不是靠运气。2. 前后端架构与开源方案选型2.1 为什么选前后端分离而不是云开发现在做小程序很多人第一反应是用微信云开发因为不用管服务器和数据库。我没选云开发原因是这类业务对后端可控性要求太高。广告反作弊策略要频繁调整金币流水要做复杂的对账查询VIP权益和兑换订单要跟外部系统对接这些逻辑放在云函数里不是不能做但调试、部署、版本管理都很别扭而且云开发的费用到了一定用户量级并不便宜。前后端分离的好处在于小程序端只负责展示和交互所有业务规则、数据校验、风控策略全部在后端。前端代码可以随意改版不影响核心账务逻辑后端可以单独发版灰度发布、紧急修复都更方便。对于开源项目来说前后端分离还有一个额外优势使用者不一定非得复用我的前端代码他可能想用原生小程序或者uniapp重写一套界面只要后端接口不变前端怎么折腾都行。技术栈方面小程序端我用了原生框架加uni-app双版本。原生版本适合直接拉下来改没有额外依赖uni-app版本适合要同时做App、H5、小程序多端的团队。后端用的是Spring Boot加MyBatis-Plus数据库MySQL缓存Redis。这套组合在中小型项目里非常常见资料多、踩坑记录丰富、招聘也容易找人。你要是更熟悉Node.js接口设计思路同样能复用核心是业务模型和状态机设计不是具体语言。2.2 开源仓库的目录结构怎么组织才不劝退开源项目最怕的是别人拉下来不知道从哪看起。我整理目录时遵循一个原则按业务模块切分而不是按技术层切分。auto-reward-miniprogram ├── miniprogram-native // 原生小程序端 │ ├── pages // 页面首页、任务、兑换、个人中心 │ ├── components // 组件广告卡片、金币余额、签到弹窗 │ └── utils // 工具请求封装、登录态管理 ├── miniprogram-uniapp // uni-app版本多端适配 ├── server // Spring Boot后端 │ ├── admin // 运营后台接口模块 │ ├── api // 小程序端接口模块 │ ├── common // 通用工具、脱敏组件、异常处理 │ ├── modules // 业务模块user、task、ad、exchange、vip │ └── quartz // 定时任务对账、过期清理、分红结算 ├── sql // 初始化脚本 └── docs // 接口文档、部署文档、审核自查清单common模块里放了一个比较重要的东西就是脱敏工具类。所有接口返回给前端的数据只要包含手机号、openid、订单号这类敏感信息都会经过统一注解脱敏。你写接口的时候只需要在字段上加一个SensitiveMask注解序列化阶段自动处理不会出现漏网之鱼把用户明文手机号暴露到日志或者前端页面的情况。这个设计后面会单独展开讲。2.3 数据库表设计与字段设计的关键决策这套系统的表结构一共十张左右最核心的是用户表、金币流水表、任务表、广告播放记录表、兑换订单表、VIP套餐表和分红记录表。字段设计上有几个关键决策值得说一下。第一金额和积分全部用decimal不用double和float。这个应该不用多解释浮点数在金额计算上会有精度问题一分钱对不上账就很尴尬。第二每张业务表都带create_time和update_time用MyBatis-Plus的自动填充功能不用每个插入语句手写。第三核心表都带version字段做乐观锁尤其是金币流水和用户余额的更新一定要用乐观锁或者行锁否则并发场景下会出现超发、重复扣减的问题。金币流水表我单独说这是整个系统的账本。每条流水记录包含用户ID、变动金额、变动类型获取/消费/退回/过期、关联业务ID、操作前余额、操作后余额、备注、幂等键。无论什么业务产生金币变动都必须走同一个流水插入逻辑不允许业务方直接改用户余额字段。这样后续对账、排查用户投诉拉一条SQL就能看清整个时间线不会出现“余额对不上”的死账。CREATE TABLE coin_flow ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL COMMENT 用户ID, change_amount decimal(10,2) NOT NULL COMMENT 变动金额正为增负为减, balance_before decimal(10,2) NOT NULL COMMENT 变动前余额, balance_after decimal(10,2) NOT NULL COMMENT 变动后余额, biz_type varchar(32) NOT NULL COMMENT 业务类型AD_TASK/EXCHANGE/REWARD/REFUND, biz_id varchar(64) DEFAULT NULL COMMENT 关联业务ID, idempotent_key varchar(128) NOT NULL COMMENT 幂等键, remark varchar(255) DEFAULT NULL COMMENT 备注, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_idempotent (idempotent_key), KEY idx_user_time (user_id, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT金币流水表;唯一索引加在幂等键上这是防止金币重复发放的最后一道防线。就算代码逻辑有bug漏掉了校验数据库层面也会直接把重复插入挡掉。这也是我反复强调的越底层的防护越可靠。3. 核心功能模块的实现细节3.1 金币任务体系与防刷策略任务体系的表结构本身不复杂就是任务类型、奖励金额、每日上限、状态这几个字段。复杂的是“防刷”这是这类系统能不能长久运营的分水岭。没有防刷机制的任务系统上线三天就会被薅秃。我实现的防刷策略分三层。第一层是频率限制基于Redis做接口限流每个用户每分钟最多请求N次每台设备每天最多播放M条广告。第二层是行为校验检查用户的手机号注册时长、账号是否实名、当天活跃时段分布异常账号直接进入人工审核队列。第三层是数据校验广告回调凭证必须来自广告平台且与后端下发的任务ID一一对应单日收益超过阈值自动触发提现审核。// 广告任务完成后发放金币 Override Transactional(rollbackFor Exception.class) public RewardResult rewardUserAdTask(Long userId, String taskId) { AdTask task getValidTaskByUserAndId(userId, taskId); if (task null) { throw new BizException(任务不存在或已过期); } // 幂等校验同一任务只允许发放一次 String idempotentKey AD_REWARD: taskId; boolean inserted tryInsertIdempotentRecord(idempotentKey); if (!inserted) { return new RewardResult(false, 重复领取); } // 额度校验 if (!canRewardToday(userId)) { throw new BizException(今日奖励已领取完毕); } // 写入流水并更新余额 UserAccount account userAccountMapper.selectByUserIdForUpdate(userId); CoinFlow flow new CoinFlow(); flow.setUserId(userId); flow.setChangeAmount(task.getRewardAmount()); flow.setBalanceBefore(account.getBalance()); flow.setBalanceAfter(account.getBalance().add(task.getRewardAmount())); flow.setBizType(AD_TASK); flow.setBizId(taskId); flow.setIdempotentKey(idempotentKey); flow.setRemark(激励视频任务奖励); coinFlowMapper.insert(flow); account.setBalance(flow.getBalanceAfter()); userAccountMapper.updateById(account); return new RewardResult(true, 领取成功); }这段代码里有几个细节值得注意。selectByUserIdForUpdate用的是悲观锁直接锁住用户账户行幂等记录和流水写入在同一事务里要么全部成功要么全部回滚所有业务校验放在事务入口处保证异常状态不会进入记账流程。用select for update天然会串行化同一个用户的金币操作虽然并发性能会下降但这类业务每用户的操作频次本来就不高安全性远大于那一点性能损失。3.2 激励视频广告的合规接入方式广告接入这块必须严格按照平台规范来。以微信小程序为例激励视频广告要用官方的RewardedVideoAd组件广告位ID在小程序后台申请。关键点在于播放奖励不能只看前端回调必须以后端校验为准。具体做法是广告播放回调触发时前端把抖音/微信广告平台返回的凭证信息广告位ID、播放时长、平台交易ID等连同任务ID一起发给后端后端做真实性校验后再发奖。// 小程序端激励视频广告播放 const rewardedVideoAd wx.createRewardedVideoAd({ adUnitId: adunit-xxxxxxxxxxxxxxxx }) rewardedVideoAd.onLoad(() { console.log(广告加载成功) }) rewardedVideoAd.onError((err) { // 广告加载失败提示用户稍后再试 wx.showToast({ title: 广告加载中请重试, icon: none }) }) rewardedVideoAd.onClose((res) { if (res res.isEnded) { // 用户完整看完广告调用后端确认接口 confirmAdTask(taskId) } else { // 未看完不发奖 wx.showToast({ title: 需完整观看广告, icon: none }) } })这里有一个非常容易踩的坑广告回调返回的isEnded字段只能说明用户是否看完了广告但它本身是可以被伪造的。前端代码被反编译后别人完全可以在控制台里手动调用onClose回调伪造isEnded为true。所以后端不能轻信这个值必须校验任务ID的有效期、任务状态、以及用户播放频次是否异常。关于自动再补充一点有人问能不能用Xposed、无障碍服务这种手段模拟点击广告实现真正的全自动。我的态度很明确这种做法不仅违反平台规则还会让开发者账号面临封禁风险更严重的是可能涉及不正当竞争。这套开源系统里设计的自动化指的是业务编排自动化而不是设备操控自动化。看清楚这个边界才不会把自己做进坑里。3.3 VIP分红与兑换中心的合规设计说完广告说权益。标题里VIP分红这四个字很容易让人联想到资金盘和传销但真正合规的设计思路是完全不同的。我在这套系统里把分红实现为一种基于用户贡献值的奖励机制。用户开通VIP后可以获得更高比例的任务奖励同时如果他通过邀请链接带来新用户新用户完成任务产生的部分收益会以积分形式返还给邀请人。这里的关键是只做一层邀请关系不做多级分销不做现金返利所有奖励都以积分形式存在于小程序内而不是直接提现成人民币。兑换中心同样要守住合规红线。微信小程序对虚拟支付管得很严不能直接通过微信支付购买虚拟商品不能有明确的充钱换金币路径。我采用的替代方案是金币只能通过做任务、签到、参与活动获取兑换的商品以实物小礼品、优惠券、虚拟会员体验为主。积分兑换实物商品需要消耗用户的金币但金币本身不能反向兑换成法定货币这样就绕开了虚拟支付监管的雷区。兑换订单的状态机设计为待审核-已通过-已发货-已完成或者待审核-已拒绝。所有订单必须经过后台人工审核不是为了刁难用户而是为了防止批量注册机器人刷兑换。运营后台里可以看到每个兑换用户的注册时长、任务完成率、金币来源分布这些数据组合起来基本能判断一个账号是否正常。3.4 脱敏模块的完整设计与实现脱敏易过审这几个字在标题里说明这是很多人关注的痛点。这里的脱敏我分四层来做。第一层是接口数据脱敏。所有后端返回的JSON数据涉及手机号、身份证、openid等字段序列化时自动打码。手机号显示138****1234openid只保留前四位。用Jackson的自定义注解实现业务代码不用写任何打码逻辑。第二层是日志脱敏。日志是最容易泄露数据的地方。很多人排查问题喜欢直接打印参数结果用户手机号和订单号全落到日志文件里。我在日志配置里加了全局的敏感词过滤器输出前统一替换。第三层是仓库脱敏。开源仓库里不能出现任何真实的密钥、小程序AppSecret、广告位ID、服务器IP。我的做法是写一个配置模板文件真实配置放在application-local.yml里且不提交到Git模板文件里全是占位符。开源前还要用工具扫描历史提交记录就算后期把密钥删了只要之前提交过Git历史里还能翻出来必须彻底清理。第四层是文案脱敏。这是易过审的关键一环。小程序审核人员会检查页面文案、标题、类目设置像赚钱提现躺赚日入这类词统统不能用。我在项目里整理了敏感词替换表赚金币换成获得积分提现换成兑换权益邀请返利换成邀请有礼。文案层面干净了过审概率会高很多。4. 过审经验平台到底在审什么4.1 小程序审核的常见驳回点与解决方案微信小程序审核的驳回理由五花八门但归纳起来跑不出这几类类目选择不匹配、页面内容涉及未开放领域、功能描述与实际情况不符、缺少必要的用户协议和隐私政策、存在诱导分享或虚假宣传行为。空类目问题最基础任务积分类小程序建议选择工具-信息查询或者商业服务-广告推广相关类目不要选游戏类目否则要提供游戏版号普通开发者根本拿不到。页面内容方面金币、积分、兑换这类词汇本身没有问题但要注意不能出现红包提现可提现到微信零钱这类话术这是审核红线。功能描述与实际情况不符这条特别容易踩坑。你提交审核的版本里如果写了看视频得金币那审核人员打开小程序就一定能找到看视频的入口。如果你把入口藏得很深或者只有特定条件下才展示会被判定为功能与描述不符。稳妥的做法是提审版本只保留最核心、最完整的体验路径其他功能全部先注释掉。用户协议和隐私政策这块很多小团队容易忽略却是审核必查项。项目里我准备了标准的用户协议模板和隐私政策模板里面明确说明了数据收集范围、使用目的、第三方SDK信息尤其是广告SDK。这一块不要省也不要从别的地方随便抄一份里面的公司主体信息要和小程序主体认证信息一致。4.2 脱敏过审的完整自查清单我把自己每次提审前的检查流程做成了清单开源项目里也放了一份。这里分享几个重点。页面截图检查把所有主要页面截图保存逐张检查有没有出现返利提现投资收益等字眼包括弹窗弹出来的文案。广告弹窗检查广告卡片上的文案模板不能出现领取现金红包之类的诱导文案。广告位所在的页面要符合当前类目不能把广告放得比主功能还显眼。分享文案检查转发给好友的标题和缩略图不能带有帮我点一下我就有钱拿了这类诱导语气。后台配置检查运营后台设置的任务名称、banner图、公告文案提审前要全部走一遍敏感词扫描。有一个技巧是准备一个审核专用开关。在后台配置中心加一个audit_mode参数提审时打开这个开关小程序端会自动隐藏一些高风险功能比如兑换中心里的高价值商品、邀请活动的分享入口只保留最基础的任务和积分展示。审核通过后再把开关关掉恢复完整功能。这个方案在合规上存在一定争议使用时需要评估自己项目的实际情况我的建议是尽量不做功能层面的“双轨制”而是把风险功能的文案、样式、交互都优化到合规标准不要靠隐藏功能骗过审核。4.3 用户协议里的免责条款怎么设计用户协议很多人都是网上复制一份改个名字就完了实际上里面的条款和你的功能对应不上真出了纠纷反而是隐患。任务积分类小程序至少要包含五个部分账号注册与使用规范、积分获得与使用规则、兑换服务说明、账号违规处理办法、免责声明。积分规则这块建议写清楚积分为平台虚拟权益不具备货币属性不能转让不能变现平台有权对异常获取的积分做冻结处理。这句话很关键万一出现系统bug被薅了积分你追回是有协议依据的否则用户投诉到平台你连下架的资格都没有。免责声明里要说明第三方广告内容的真实性由广告主负责平台不承担因广告内容引发的纠纷责任。5. 常见问题与排查技巧实录5.1 广告无法播放或回调不触发短信边做边踩坑这里挑几个高频问题讲。广告无法播放先查三件事accredit状态是否为正式、adUnitId有没有绑定到当前小程序、测试机和线上环境的广告位ID是否一致。微信后台的广告位分为测试广告位和正式广告位测试广告位的ID在线上环境是无效的。我一开始没注意把测试ID写在线上配置里上线后广告一直没有填充后台一查全是adUnitId无效报错。回调不触发大概率是页面已经销毁或者onClose里的异步请求发晚了。广告播放完成后如果用户立刻关闭小程序页面onClose回调可能不会触发。稳妥做法是在TaskService里加一个定时轮询或延迟确认机制前端在onShow时检查当前是否有未确认的广告任务有就重新调用确认接口。5.2 金币账务不平与重复发放账户余额出现负数是这类系统最容易出的问题。排查思路是先用对账SQL把用户表余额和流水表sum对比找出差异用户再按biz_type分组看哪个业务类型产生的流水和实际发放记录不一致最后定位到具体代码查看并发条件下是否存在超扣。我用乐观锁之后负数问题基本消失但偶尔会出现扣款失败因为version冲突导致更新影响行数为0。这时候不能直接报错要做重试或者把失败信息放入消息队列。-- 对账SQL找出余额与流水不一致的用户 SELECT u.id, u.balance, IFNULL(SUM(f.change_amount), 0) AS flow_amount, u.balance - IFNULL(SUM(f.change_amount), 0) AS diff FROM user_account u LEFT JOIN coin_flow f ON f.user_id u.id GROUP BY u.id, u.balance HAVING diff 0;重复发放的问题主要出现在幂等键设计不合理。如果幂等键只用taskId那用户第一次请求异常后重试任务ID不会变幂等没问题但如果系统生成taskId的逻辑里带了时间戳两次请求可能生成不同taskId幂等就失效了。幂等键必须是业务逻辑上唯一稳定的字段不能每次生成不同的随机串。5.3 审核被拒后的处理节奏审核被拒不用慌先看驳回原因再定修改方案。最常见的驳回原因是涉及平台未开放的业务这种一般不是代码问题是类目或者文案问题。按驳回描述逐项排查修改后重新提审即可。有一点要提醒审核被拒后不要频繁提交修改版本。有朋友被拒后一天改三次提三次结果每次都被拒原因都一样。微信审核是有记录和风控的反复提交相同问题会被判定为无效提交甚至延长审核周期。正确做法是第一次被拒就把所有问题改彻底提交时在备注里说明本次修改内容这样审核人员能快速定位。6. 开源落地的细节与后续扩展方向6.1 开源仓库的敏感信息披露问题把代码开源是一件好事但开源之前的信息脱敏比写代码更重要。很多开发者习惯把配置文件写在application.yml里本地跑的时候直接用的微信支付密钥、商户号、数据库密码然后顺手就git push到GitHub了。这种事我见过不止一次后果非常严重轻则密钥被脚本扫描盗用重则被人薅调用量、刷订单。开源前要做三件事。一是扫描代码库搜索appSecret、password、privateKey等关键词确认没有真实密钥残留。二是查看git历史就算当前版本已经清理历史提交里可能还有。用BFG Repo-Cleaner或者git filter-branch清理历史记录然后强制推送。三是设置GitHub的Secret扫描告警选项万一有遗漏平台会主动通知你。6.2 文档要写给使用者看不是写给平台看很多开源项目的README就是README三行依赖列表都懒得写。我写这份文档的时候参考了周到的开源项目经验把内容分成几个部分项目简介、演示截图、功能清单、技术栈说明、快速启动指南、接口文档索引、配置项说明、常见问题。每个部分都不长但确保使用者照着操作能跑起来。快速启动指南我踩过不少坑。一开始只写了配置数据库连接后运行SpringBootApplication结果一堆人私信问启动报错。后来我把依赖安装、数据库初始化的具体命令、Redis连接异常的处理方式都写进去问题才少很多。记住一句话开源项目的文档默认读者是第一次接触这个项目的陌生人不是你自己。6.3 这套系统还能往哪些方向扩展这个项目目前已经能支撑一个中小型流量产品的日常运营但扩展空间还很大。一是广告平台接入目前只做了微信小程序端的激励视频头条小程序、抖音小程序、百度小程序都有各自的广告体系uni-app版本就是把这套业务逻辑平移到其他端。二是数据看板现在运营后台只做了基础的订单审核和数据统计可以考虑接入开源的BI工具实现实时收益、用户留存、任务完成率的可视化分析。三是自动化风控当前的风控规则是写死的阈值可以考虑引入规则引擎或者简单的机器学习模型让防刷策略能够动态调整。如果团队有一定开发能力还可以把前端管理后台换成若依这类成熟框架尽快补上权限管理、日志审计、操作留痕这些企业级功能。做这类业务稳定性和安全性永远是第一位的功能可以少账不能乱风控不能丢。最后再说一句实际体会这套项目做完并开源出去对我个人最大的收获不是代码本身而是把做业务和守边界两件事结合了起来。广告变现本身是正当的商业模式积分任务也早就被各大平台广泛应用关键在于你的系统能不能支撑透明、公平、可追溯的规则能不能主动把刷量、作弊挡在门外。代码是死的但别人怎么用它决定了它的价值。我希望看到这篇文章的人能把这套架构用在正当的业务上把用户服务好把平台规则守好剩下的事情时间会给你答案。