简介这是一套面向公众号/H5运营场景的早起打卡挑战商业版源码适合需要快速上线付费打卡活动的开发者或运营者。资源覆盖参与、打卡、分金、退款与推荐奖励机制支持每日1元参与挑战、次日5:00-8:00打卡、按时打卡用户平分昨日挑战金并支持打卡后自动参与下一天、主动申请退还本金等进阶玩法。压缩包共77个文件以PHP后端逻辑、HTML页面、JavaScript交互、CSS样式及PNG图片素材为主整体约1.1MB结构清晰便于部署与二次开发。目前已有138人学习下载。附带推荐奖励金额设置、海报二维码推荐、公众号关键词回复等配置说明以及商业版升级后未打卡金额分钱的注意事项方便运营者快速理解并落地使用。1. 早起打卡挑战3.3.5商业版靠“挑战金”转起来的自律生意一个反直觉的事实用户买自律产品很少是因为爱学习更多是因为“不打卡就会亏钱”的损失厌恶。早起打卡挑战商业版做的就是这个生意——用户支付一笔挑战金坚持早起打卡就能瓜分奖池中途失败则资金被留下。这套模式在私域社群、知识付费、习惯养成领域跑了好几年3.3.5商业版是这类产品里比较成熟的一套代码形态前端小程序、后端管理、支付分账、分销裂变都齐了。你要理解的第一件事这不是一个工具型小程序而是一个资金流产品。用户付出去的钱怎么收、怎么保管、怎么分、怎么退才是这个项目的灵魂。本文按“产品逻辑 → 部署搭建 → 商业化配置 → 避坑 → 验证”的顺序把一套能上线的方案讲透。适合有微信小程序开发基础、想快速搭建自律打卡类产品的团队和个人开发者。2. 产品逻辑与核心模块先搞清挑战金怎么流再动手搭2.1 打卡规则引擎周期、补签、请假三个参数定生死早起打卡的核心是规则引擎它决定用户的钱在什么条件下会输掉。最常见的商业化规则是三要素挑战周期常见 7 天 / 14 天 / 21 天 / 30 天、每日打卡窗口常见 04:00–08:00 或 05:00–09:00、失败判定缺卡即失败或允许补签 1 次、请假 1 次。这三个参数直接决定用户完成率和退款率。我把完成率做过一次模拟30 天周期、无补签无请假真实用户完成率通常在 18%–32% 之间加上 1 次补签后能到 45% 左右再加 1 次请假能稳定在 55%–65%。完成率不是越高越好——完成率太高意味着奖池分出去的钱多平台抽成变少太低则用户觉得被“杀猪”复购和口碑崩盘。商业版一般会在后台把这三个参数做成可配置项而不是写死在代码里。数据库设计上规则表至少要有这几个字段cycle_days周期天数、checkin_start打卡窗口开始时间、checkin_end打卡窗口结束时间、allow_makeup允许补签次数、allow_leave允许请假次数、challenge_fee挑战金额。规则是每一期挑战的“宪法”用户在报名时看到的规则文案、支付时勾选的协议、结算时的判定逻辑必须全部来自同一条规则记录不能前端写一套、后端判一套。2.2 奖池与分账钱怎么收、怎么分、平台抽成怎么算奖池模型是早起打卡商业模式的核心。常见做法是每期挑战结束后失败用户的挑战金进入奖池成功用户按一定规则瓜分。平台方抽成有两种主流方式一是从奖池固定抽成比如 10%二是从每笔报名费中直接抽成比如每人报名费 19.9 元抽 2 元剩余进奖池。账要算清楚我通常建议按“平台抽成 奖池分配 退款预留”三个账户拆分。比如 100 人报名 30 天挑战每人 30 元总资金 3000 元。假设完成率 60%即 60 人成功、40 人失败。失败资金 1200 元进入奖池平台从中抽 10% 即 120 元剩余 1080 元分给 60 个成功用户每人返 18 元。加上成功用户退回的挑战金 30 元实际每个成功用户拿到 48 元。这笔账在部署前必须算清楚并且要在规则说明里写明否则会引发客诉。商业版的分账逻辑在代码上通常体现为三个时间点报名时冻结资金、结算时计算分配、提现时实际打款。不能等到提现时才去算账而应该在每期挑战结束的当天生成结算单用户看到的“可提现余额”只是结算结果的展示。这个顺序一旦颠倒就会出现用户看到的余额和实际打款对不上的问题。2.3 报名 → 打卡 → 结算的完整状态机从用户视角是“报名、打卡、收钱”三步但从系统视角一个参与记录至少经历这几个状态待支付→已支付/进行中→已完成/已失败→已结算/未结算。中间还有已请假、已补签这样的子状态。我一般会专门画一张状态流转表部署前先对一遍状态机有没有死角特别是这几种边界用户报名后未支付就关闭页面订单要自动取消打卡窗口刚过 1 秒到达的请求用服务端时间判定拒绝但友好提示补签次数用完后再次申请补签前端要置灰后端也要校验结算过程中用户在后台申请退款锁定结算单。一个实用的做法是在参与记录表里加一个status字段和status_logJSON 字段每次状态变更写入一条日志。排查问题时status_log能帮你快速还原用户经历了什么而不是对着数据库猜。这个习惯排查线上问题时能省一半时间。3. 部署与初始化从商业版源码到本地跑通最小闭环3.1 环境选型微信小程序 云开发还是独立后端3.3.5 商业版这套体系在市面上最常见的托管方式有两种一种是微信小程序原生前端 微信云开发云函数 云数据库 云存储另一种是 uni-app 前端 独立服务器Node.js 或 PHP MySQL Redis。前者适合个人开发者、启动成本低不需要买服务器、不需要备案后者适合已经有服务器资源、需要深度定制和对接外部系统的团队。我推荐的路线是如果是第一次部署优先走云开发。理由很直接云开发的定时触发器、微信支付云调用、订阅消息云调用都是天然集成的省掉大量鉴权代码。早起打卡这类产品非常依赖“每天早上定时结算”和“给用户发提醒消息”这两个能力云开发的定时触发器可以按 cron 表达式执行比自己在服务器上配 crontab 要少踩很多系统的坑。如果是独立服务器方案技术栈一般选 ThinkPHP/Laravel MySQL Redis。Redis 在这里不只是缓存更重要的是做“打卡判重”和“并发控制”——同一个用户同一天同一期挑战只能打一次卡这个判断如果走数据库唯一索引可以但走 Redis 的 SETNX 更稳能扛住早上 8 点前的一波集中请求。3.2 初始化项目数据库表结构与最小配置拿到 3.3.5 商业版源码后第一步不是急着看代码而是先建库、配环境变量。以云开发为例至少需要创建这些集合challenge_rules、challenge_periods、participants、checkin_records、orders、settlements、users、admin_users。建议直接按源码里的database目录导入 JSON 索引文件不要手动建索引容易漏掉唯一索引。配置文件里最关键的三个参数是appid、mch_id微信支付商户号、api_v3_key商户 API 密钥。这三个参数错了或没配全后面每一步都会卡住。配置完成后建议先跑一个自检脚本确认云函数能正常访问数据库、能拿到微信支付证书。另外要注意 3.3.5 版本商业版和免费版的差异免费版通常只有单期挑战 固定规则商业版开放了多期并发、自定义打卡窗口、分销设置、管理后台多管理员、数据导出。部署时别只用免费版的配置思路去配商业版至少要把enable_distribution、platform_fee_rate、settlement_mode这三个商业版独有配置项确认一遍。3.3 跑通最小闭环创建一期挑战并模拟打卡部署完成后先不要接支付先走通“创建挑战 → 报名 → 打卡 → 结算”的最小闭环。我用云函数的方式演示核心逻辑前端只负责调用。创建挑战的云函数用 Node.js// 创建一期早起打卡挑战 const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event) { const { title, // 挑战标题如21天早起打卡 cycle_days, // 周期天数如 21 fee, // 挑战金额单位元 checkin_start, // 每日打卡开始如 04:00 checkin_end, // 每日打卡结束如 08:00 allow_makeup, // 允许补签次数 allow_leave, // 允许请假次数 platform_rate // 平台抽成比例如 0.10 } event if (!title || !cycle_days || !fee || !checkin_start || !checkin_end) { return { code: -1, msg: 缺少必要参数 } } // 在创建时提前计算 end_date保证后续结算不依赖前端传参 const startDate new Date() const endDate new Date(startDate.getTime() cycle_days * 24 * 60 * 60 * 1000) const res await db.collection(challenge_periods).add({ data: { title, cycle_days, fee, checkin_start, checkin_end, allow_makeup, allow_leave, platform_rate, start_date: db.serverDate({ offset: 8 * 60 * 60 * 1000 }), // 北京时间 end_date: endDate, status: pending, // pending 未开始 / running 进行中 / settled 已结算 created_at: db.serverDate() } }) return { code: 0, data: { id: res._id } } }云函数创建后在小程序端直接wx.cloud.callFunction调用。注意db.serverDate({ offset: 8 * 60 * 60 * 1000 })这个用法——云开发数据库默认存 UTC 时间如果你希望后台看到的开始时间是北京时间要显式指定 offset。这个细节我在部署时踩过一次后台显示的开赛时间和实际差了 8 小时用户也吐槽“不是 5 点开赛吗怎么 4 点就能打卡了”。打卡判定的核心逻辑注意必须用服务端时间不能信客户端// 用户打卡云函数 exports.main async (event) { const { openid, periodId } event const db cloud.database() const _ db.command // 1. 查询当前挑战期 const periodRes await db.collection(challenge_periods).doc(periodId).get() const period periodRes.data if (!period) return { code: -1, msg: 挑战不存在 } // 2. 用服务端当前时间判断是否在打卡窗口内 const now new Date() const nowStr ${String(now.getHours()).padStart(2, 0)}:${String(now.getMinutes()).padStart(2, 0)} if (nowStr period.checkin_start || nowStr period.checkin_end) { return { code: -1, msg: 当前不在打卡窗口内${period.checkin_start}-${period.checkin_end} } } // 3. 当天是否已打卡用日期字符串作为唯一键防止重复打卡 const today now.toISOString().slice(0, 10) const dup await db.collection(checkin_records) .where({ openid, periodId, date: today }) .count() if (dup.total 0) return { code: -1, msg: 今天已经打过卡了 } // 4. 写入打卡记录 await db.collection(checkin_records).add({ data: { openid, periodId, date: today, created_at: db.serverDate() } }) // 5. 累加连续打卡天数 await db.collection(participants) .where({ openid, periodId }) .update({ data: { checkin_days: _.inc(1) } }) return { code: 0, msg: 打卡成功 } }这个云函数里最关键的是第三步的“当天判重”。前端按钮可以控制用户只能点一次但早上集中打卡时用户可能双击、可能退出重进后端必须按openid periodId date做唯一性校验。如果你用的是独立后端而不是云开发建议在checkin_records表上建联合唯一索引(openid, period_id, date)效果等同而且比代码判重更底层、更稳。模拟跑通这段逻辑后你心里应该有一个“最小闭环已经成立”的底。这时候再接微信支付和订阅消息即使出现问题也知道问题出在支付层而不是打卡业务层。4. 商业版功能落位支付、分销、订阅消息与管理后台4.1 微信支付接入挑战金托管与退款的关键配置早起打卡产品的资金性质是“用户预付按结果分配”微信支付官方一般按“平台收钱再分给用户”的场景走。商家要开通微信支付商户号且主体类型和营业执照要匹配。个人主体通常不能做这种资金归集类业务至少需要个体户或企业资质。3.3.5 商业版在支付环节一般使用微信支付 JSAPI 下单 企业付款到零钱或商家转账完成分账。报名时用户通过小程序内支付钱进入商户号结算时系统调用微信支付的“商家转账”接口把瓜分奖金打给成功用户。这个流程里最容易踩的坑是“结算金额和转账金额精度不一致”。微信支付结算以“分”为单位后台计算的金额如果用了浮点数会出现 0.1 0.2 0.30000000000000004 这种精度问题转账时就会被拒。所有金额统一用整数“分”存储和计算展示时再除以 100。退款逻辑也要提前想好。微信支付规定虚拟商品原则上不支持退款但早起打卡这类“预付挑战金”业务如果用户在挑战开始前申请退款通常是可以退的。商业版一般会做一个“开赛前 X 小时可退开赛后不可退”的配置项默认 24 小时。退款时要注意如果用户已经支付但挑战还没开始后台应调用微信支付退款接口原路退回而不是通过商家转账人工打款。4.2 分销体系先想清楚合规边界再配置三级分成商业版的分销是吸引大量运营者选择付费版的原因之一老用户邀请新用户报名成功后邀请人获得一定比例奖励。3.3.5 商业版的分销配置通常在管理后台有开关enable_distribution、distribute_levels、distribute_rate。常见设置是两级一级 10%、二级 5%三级分销在当前合规环境下不建议碰尤其涉及多级返利时容易触线。分销奖励的发放在代码层面要遵循“结算后发放”原则即被邀请人完成整个挑战周期并成功结算后邀请人的奖励才进入可提现余额。如果用户报名后就立刻发奖励会出现大量“报名后不打卡但是邀请人已经拿钱”的情况资金风险很高。另外要注意分销奖励和挑战金分账是两条资金流。挑战金走“商户号 → 用户零钱”分销奖励也走“商户号 → 邀请人零钱”但在结算单上必须分开列明否则用户对账时看不懂明明打卡成功了为什么到账金额比预期少因为其中一部分被二级分销分走了。后台的结算页面最好给用户展示“打卡返还 瓜分奖池 分销奖励”三个明细行。4.3 订阅消息与定时任务让用户“记得打卡”是个系统工程早起打卡产品每天有两个关键任务提醒用户打卡、结算前一天的数据。3.3.5 商业版一般通过云函数定时触发器实现。你需要配置两个定时任务示意如下{ triggerName: dailyReminder, triggerType: timer, config: 0 0 6 * * * * }这个 cron 表达式表示每天 06:00 触发。在云函数里查询当天还没打卡的参与者并给他们的 openid 发送订阅消息。微信小程序订阅消息的特点是“一次性订阅”用户每次点击授权只能收到一条消息。所以商业版通常会在用户报名成功后弹一次订阅授权然后每日打卡成功后再弹一次授权让用户授权第二天的提醒。这个链路需要在代码里专门写一个“打卡成功后静默弹出订阅授权”的交互否则用户第一天的授权用完第二天开始就收不到提醒了。第二个定时任务是结算任务。一般配置在每天早上 09:00 或 10:00 执行避免打卡窗口刚关闭就结算导致时差争议。结算任务里依次做遍历所有running状态的挑战期 → 计算每个参与者的打卡天数 → 区分成功/失败 → 生成结算单 → 调用商家转账接口。整个流程建议做成可重入的如果转账接口超时了不要立刻重试转账而是把状态标记为pending_transfer由后台人工或另一个定时任务处理确认。否则容易出现“钱转出去了但订单状态还是未结算”的重复转账问题。4.4 管理后台数据看板、手动干预与对账导出的三个关键页面商业版的管理后台是你日常运营的主战场。3.3.5 商业版后台一般至少包含三个核心页面挑战管理、用户管理、财务对账。挑战管理页面上你可以创建新挑战、配置规则、提前结束一场异常挑战。注意“提前结束”这个操作商业版一般会做成“关停并结算”即按当前打卡天数计算成功失败并立即结算而不是简单删除。删除挑战是极其危险的操作会导致参与记录、打卡记录、结算单一并被删资金对不上。用户管理页面上可以查看每个用户的参与记录、打卡明细、当前余额、提现记录。这里商业版通常提供“手动调整余额”的入口比如用户反馈打卡失败是系统 bug 导致运营需要手动补偿 30 元积分或余额。手动调整一定要写入操作日志记录原因和操作人财务核对时才能追溯。财务对账页面是每天要看的总报名金额、总退款金额、平台抽成收入、分销奖励支出、实际转账金额。这五项应该满足一个简单的关系总报名金额 - 总退款金额 平台抽成收入 分销奖励支出 实际转账金额。如果等式不成立先去看有没有pending_transfer状态的结算单通常问题出在那里。5. 商业版避坑指南五个最容易翻车的环节5.1 客户端时间和服务端时间不一致导致打卡窗口判定混乱现象用户手机时间调快 3 分钟在窗口没开始时就能打卡或者手机时间慢了窗口内打卡被拒绝。用户截图反馈“我到点打的卡你们说我没打”。原因早期版本打卡判定直接用了new Date()的前端时间甚至有人直接调系统时间绕过打卡限制。解决判定必须全部走服务端时间。云函数里用db.serverDate()或云函数运行环境的系统时间前端只负责提交动作不参与判定。检查用户是否在窗口内时用 UTC 时间对比而不是拼接本地时间字符串。5.2 微信支付商家转账被风控拦截现象一批成功用户本应收到瓜分奖金但转账结果显示失败资金卡在商户号里。用户那边没收到钱开始投诉。原因新商户号短时间内向大量用户发起转账或者转账金额出现大量相同金额比如 18.00 元触发微信支付风控。解决上线前先把商户号的产品能力开通“商家转账”并做好风控准备。上线初期控制单次转账数量和频率可以按每 100 人一批、间隔 10 秒的方式分批转。更稳妥的做法是用户在小程序里绑定手机号且保持实名认证转账时微信风控的通过率会高不少。5.3 补签/请假次数被无限刷现象有用户每天打卡失败就申请补签/请假一个周期下来补签了 10 次比打卡还多最后还瓜分奖池。其他用户开始投诉。原因前端把补签按钮变成可点击状态后端在部分版本里没有校验剩余次数或者校验用的字段在每次补签后被重置。解决后端必须记录“已用补签次数”而不是“剩余次数”。每次补签请求时先查participants记录里的used_makeup与规则的allow_makeup对比超过则拒绝。补签操作和请假操作都必须写入checkin_records并标记type: makeup或type: leave不能只改一个数字。5.4 挑战金退款和开赛时间冲突现象用户在开赛前 1 小时申请退款后台退款成功但该用户在奖池的参与记录仍然存在结算时他被算作成功用户重复拿了一份奖金。原因退款操作和参与状态没有联动。退款接口只改了订单状态没有同步把participants记录置为refunded。解决退款时在事务里更新三个集合订单状态改为refunded、参与记录状态改为refunded、如果该用户已经打卡则删除其打卡记录或标记无效。微信云开发支持事务操作用db.startTransaction()包住这三个更新独立后端则用 MySQL 事务或 Redis 分布式锁保证一致性。5.5 并发打卡导致重复写入现象某用户 6:00 整连续点了两次打卡后台显示一天内打了两条卡连续打卡天数被加了两次。结算时多算了一天成功。原因前端用按钮 disabled 防止重复点击但用户可以通过快速切换页面绕过后端没有做当天唯一性约束。解决checkin_records表必须建联合唯一索引(openid, period_id, date)或者云数据库的 where 查询 原子更新。亲测最快的修复是给索引加上应用层判重作为第二道保险。如果你修改了数据库结构记得重建索引否则已有的线上数据里会出现脏数据需要手工清理。6. 从跑通到赚钱灰度验证与数据埋点代码都跑通了、支付也配置好了不等于这产品能赚到钱。上线前我最推荐的方式是先拉 20–50 个种子用户做灰度不要一上来就投付费流量。早起打卡这类产品在种子用户阶段要验证三个关键数据报名转化率、首日打卡率、7 天留存率。报名转化率衡量的是“看了规则愿不愿意付挑战金”。如果报名转化率低于 20%大概率是规则页文案或者挑战门槛出了问题金额太高、窗口太苛刻、奖励描述不清晰。首日打卡率通常要达到 80% 以上第一天就掉到 60% 以下说明用户对打卡操作本身有困惑订阅消息提醒没起到作用。7 天留存率在 40% 以上算及格低于 30% 说明用户对“早起打卡”这件事本身没有持续动力需要重新设计玩法和奖励梯度。这三个数据对应的埋点字段我一般在报名事件、支付成功事件、每日打卡事件、结算完成事件里各打一条日志openid、period_id、event_name、timestamp、extra_json。不需要埋太多采样数据量足够看趋势就行。灰度期间还有一个小技巧把挑战金额分成两档做对比测试。A 组 9.9 元、B 组 19.9 元其他配置完全一致。看两组的完成率、奖池金额、复购率。我见过某开发者用这个方式跑了一周数据发现 9.9 元的报名量是 19.9 元的 3 倍但完成率低 15%实际平台抽成收入反而更低——用户损失厌恶的程度和对小额金额的忽视直接改变了产品收入结构。所以定价不能拍脑袋要拿数据说话。终局习惯上我现在每天看的第一张表是“昨日结算单 今日待结算单”第二张才是收入。结算异常处理得越快用户的信任感越强复购率自然就上来。这个习惯救过我很多次希望你也能用上。希望帮到你。本文还有配套的精品资源点击获取