简介这套源码基于PHP开发是一套自动阅读挂机浏览广告新闻任务系统。面向需要搭建积分任务平台的站长、运营者以及PHP学习者能解决网站活跃度不足与广告曝光率提升的核心问题。系统整合了自动浏览、赚取积分、支付宝提现、小熊阅读以及三级团队推广等模块适用于新闻阅读、广告点击等任务激励场景。资源包共含4个文件压缩后约41.27MB包括项目源码ZIP、数据库脚本SQL、安装说明TXT以及界面文档HTM覆盖从部署到运行的完整链路。目前已有1198人学习下载通过阅读源码可系统掌握PHP任务调度、积分累计与兑换、支付接口对接、多级分销逻辑等关键实现尤其三级团队机制能清晰演示上下级关系维护与收益分配策略对理解裂变推广模式很有帮助。对于想快速上线类似平台的人来说按安装说明配置数据库与支付信息即可部署同时它也是一份完整的PHP业务系统学习案例非常适合作为二次开发参考。1. 基于PHP的自动阅读挂机任务源码先看闭环再看挂机这套源码真正值钱的不是“自动阅读”那几个 PHP 脚本而是它把任务派发、积分流水、三级团队佣金和支付宝提现串成了一个完整闭环。你从 zip 里解出一堆task.php、point.php、withdraw.php如果只盯着“怎么挂机”等于把系统里最不设防的那部分当成了核心。实际部署场景通常是积分任务站、地推激励或新闻资讯类 H5 的拉新玩法用户完成任务获得积分积分可以按比例提现推荐新用户还能拿三代佣金。适合的团队规模不大PHP 7.x MySQL 5.7 Redis 就能撑起来代码改造成本远低于从零设计一套账务系统。建议拿到源码包后先别急着装按“任务链路 → 积分链路 → 提现链路”的顺序读表结构和接口谁先谁后决定了你会不会在提现环节被账不平的问题坑一夜。2. 任务与积分系统的数据链路从任务派发到流水落库2.1 拆解 zip 源码包之前先确认四张核心表我一般拿到这类 PHP 源码包第一件事是打开install.sql或sql/migration.sql找四张表用户表、任务表、任务记录表、积分流水表。如果连这四张都没有说明源码只是演示版后面的积分和提现逻辑都只能靠猜。最小可运行的建表结构如下字段名可能因源码品牌不同有差异但信息量是必须的CREATE TABLE t_user ( user_id int(11) NOT NULL AUTO_INCREMENT, openid varchar(64) DEFAULT , invite_code varchar(12) DEFAULT , parent_id int(11) DEFAULT 0 COMMENT 推荐人ID, created_at datetime NOT NULL, PRIMARY KEY (user_id), UNIQUE KEY uk_invite_code (invite_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_task ( task_id int(11) NOT NULL AUTO_INCREMENT, task_type varchar(20) NOT NULL COMMENT read/ad/invite, title varchar(128) NOT NULL, reward_points int(11) NOT NULL DEFAULT 0 COMMENT 单次奖励积分, channel varchar(32) DEFAULT bear_reader COMMENT 渠道标识, 小熊阅读等来源, status tinyint(1) NOT NULL DEFAULT 1, PRIMARY KEY (task_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_task_log ( log_id bigint(20) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, task_id int(11) NOT NULL, task_date date NOT NULL, progress int(11) NOT NULL DEFAULT 0 COMMENT 进度, 通常按秒累计, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0进行中 1完成, finish_time datetime DEFAULT NULL, PRIMARY KEY (log_id), UNIQUE KEY uk_user_task_date (user_id,task_id,task_date), KEY idx_user_status (user_id,status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_point_log ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, change_point int(11) NOT NULL COMMENT 正负积分, balance int(11) NOT NULL COMMENT 变更后余额, biz_type varchar(20) NOT NULL COMMENT task/team/withdraw, biz_id varchar(64) NOT NULL COMMENT 关联业务单号, created_at datetime NOT NULL, PRIMARY KEY (id), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;四张表的核心逻辑是t_task_log记录“某个用户某天某个任务做了多少进度”t_point_log记录“每一笔积分变化的来龙去脉”。二者通过biz_id关联。如果源码里积分流水只有change_point没有balance快照那对账的时候会很痛苦建议自己补上。uk_user_task_date这个唯一键是被刷系统的防线之一同一用户同一天执行同一任务只允许一行记录。虽然 Redis 也能防但数据库唯一键是兜底Redis 挂了它还能挡住重复单。2.2 自动阅读进度上报的最小 PHP 实现挂机阅读的常见做法不是服务端 sleep而是前端 H5 页面每 N 秒上报一次阅读进度服务端记录进度达到阈值后结算积分。这样即使用户中途切走页面服务端也能判定任务未完成而不是白白发钱。前端定时器发送到report.php服务端代码如下?php // report.php?user_id1task_id3device_idabc $user_id intval($_GET[user_id] ?? 0); $task_id intval($_GET[task_id] ?? 0); $device_id substr((string)($_GET[device_id] ?? ), 0, 64); if (!$user_id || !$task_id) { http_response_code(400); exit(json_encode([code 1, msg 参数缺失])); } $pdo new PDO(mysql:host127.0.0.1;dbnametask_app, root, root); $pdo-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); $stmt $pdo-prepare( INSERT INTO t_task_log (user_id, task_id, task_date, progress, status) VALUES (?, ?, CURDATE(), 1, 0) ON DUPLICATE KEY UPDATE progress progress 1 ); $stmt-execute([$user_id, $task_id]); $row $pdo-query( SELECT ttl.progress, t.reward_points, t.ttl_seconds FROM t_task_log ttl LEFT JOIN t_task t ON t.task_id ttl.task_id WHERE ttl.user_id {$user_id} AND ttl.task_id {$task_id} AND ttl.task_date CURDATE() )-fetch(PDO::FETCH_ASSOC); if ($row $row[progress] $row[ttl_seconds] $row[status] 0) { // 达到阅读时长, 结算积分 give_points($user_id, $row[reward_points], task, $task_id); $pdo-prepare(UPDATE t_task_log SET status1, finish_timeNOW() WHERE user_id? AND task_id? AND task_dateCURDATE()) -execute([$user_id, $task_id]); exit(json_encode([code 0, msg 任务完成, points $row[reward_points]])); } echo json_encode([code 0, msg progress_ok, progress $row[progress] ?? 0]);ON DUPLICATE KEY UPDATE progress progress 1是这段代码的巧劲利用uk_user_task_date唯一键实现“有则累加、无则插入”避免了先 select 再 update 的竞态窗口。ttl_seconds是任务时长参数比如阅读一篇文章需要 60 秒那每 5 秒上报一次累计 12 次就结算。结算前再查一次status 0防止重复发积分。注意这段代码省略了give_points()的事务逻辑实际使用必须把积分流水写入放在同一个事务里否则会出现任务完成但积分没到账的现象。2.3 重复刷任务的防线Redis 锁与并发兜底进度上报接口天生容易被并发请求刷爆。一个用户开 10 个标签页同时打report.php如果只靠 MySQL 行锁高并发下 InnoDB 的锁竞争会让接口响应变慢而且ON DUPLICATE KEY UPDATE的原子性也会在极端情况下被打破。我一般会在进入数据库之前先走一层 Redis$lock_key task_progress:{$user_id}:{$task_id}: . date(Ymd); $ttl 10; // 锁10秒, 防止卡死 $result $redis-set($lock_key, $device_id, [NX, EX $ttl]); if (!$result) { exit(json_encode([code 2, msg 提交过快])); }锁的用途不是让所有请求串行而是丢弃“同一秒钟内的重复上报”。一个正常用户开一个页面5 秒上报一次不可能在 1 秒内提交两次。如果report.php里出现大量locked返回基本可以判定有人用脚本刷接口。Redis 锁加在$_GET参数校验之后、MySQL 写入之前。锁粒度按用户任务日期设计避免同一个用户做不同任务时互相阻塞。如果 Redis 不可用代码要能降级到直接走 MySQL靠唯一键兜底而不是整个接口 500 崩溃。3. 挂机阅读的调度设计与广告任务边界3.1 Crontab 定时任务PHP CLI 跑批的三种常见写法阅读挂机不能只靠用户开着页面服务端得有一个调度器负责兜底把超时未完成的任务自动关闭、把异常任务恢复、把团队收益按周期结算。大多数源码包里的调度就是 Linux crontab 加 PHP CLI 脚本没有用 Swoole 或 Workerman这是最稳的选择。通常三个调度任务# 每分钟执行一次: 处理超时未完成任务 * * * * * /usr/bin/php /var/www/task_app/cli/close_timeout_task.php /data/logs/close_task.log 21 # 每5分钟执行一次: 重推未成功的支付宝提现 */5 * * * * /usr/bin/php /var/www/task_app/cli/retry_withdraw.php /data/logs/retry_withdraw.log 21 # 每天凌晨3点执行: 团队积分复算与报表 0 3 * * * /usr/bin/php /var/www/task_app/cli/settle_team_report.php /data/logs/settle.log 21如果源码里没有这三个目录说明它只实现了前端接口没有后台调度。这时候要么自己补 CLI 脚本要么把逻辑塞进某个接口里被动触发——后者在用户量上来后一定会出问题。第一个任务close_timeout_task.php的逻辑很简单把t_task_log里status 0且超过任务时长 2 倍仍无进度的记录标记为过期。注意不要直接删除记录因为运营需要看到“有多少人读了开头但没读完”这类数据对调任务奖励有参考价值。3.2 阅读时长、浏览间隔与每日任务量参数怎么定“小熊阅读”这类频道模块本质上是在 H5 容器里嵌套一篇资讯文章然后挂上阅读进度逻辑。参数设置直接决定收益成本参数常见配置设置理由ttl_seconds单任务时长3090 秒太短没广告价值太长用户流失report_interval上报间隔5 秒兼顾服务端压力和防刷粒度daily_task_limit每日任务数815 个控制单用户每日积分上限reward_points单任务积分15 分1 积分 ≈ 0.01 元时单人日成本 12 元withdraw_min最低提现100 积分1元过低会增加支付宝转账手续费损耗withdraw_max_daily每日提现次数1 次降低异常提现频率这些参数在源码包里通常集中在config/config.php或者后台设置表里。真正上线时不要把reward_points设成固定值建议按文章字数或阅读时长动态计算否则会出现“30 秒短文和 5 分钟长文同一个价”的套利空间。3.3 与真实广告任务的边界不要伪造第三方点击必须提醒一个边界问题源码里的“挂机浏览广告新闻”如果只是自己的 H5 页面那随便怎么设计都合规但如果要去请求第三方广告链接并模拟点击大概率会触发对方风控甚至导致账号封禁。常见的折中方案是在源码里把“自动浏览”改为“半自动”用户点击“开始阅读”后H5 在 iframe 里加载目标文章但服务端只记录阅读时长不发送任何点击信号。代码上可以通过onload事件确认内容加载完成再开始计时let startTime null; const iframe document.getElementById(readerFrame); iframe.addEventListener(load, function () { startTime Date.now(); window.taskTimer setInterval(() { const seconds Math.floor((Date.now() - startTime) / 1000); navigator.sendBeacon(/report.php, new URLSearchParams({ user_id: USER_ID, task_id: TASK_ID, progress: seconds })); }, 5000); });这里使用sendBeacon而不是fetch是因为页面切后台或关闭时sendBeacon有更高的几率把最后一次进度送达服务端减少“读了最后一秒没算完”的客诉。4. 赚积分系统与三级团队一个能跑的分润模型4.1 积分账务每笔变动都带业务单号积分系统的核心不是如何增加而是如何保证账平。最稳妥的方式是所有积分变动只经过一个统一入口函数任何业务代码不得直接操作t_user.points字段。统一入口的写法function give_points(int $user_id, int $change, string $biz_type, string $biz_id): bool { $pdo get_pdo(); $pdo-beginTransaction(); try { // 行锁锁住用户行, 防止并发导致 balance 计算错误 $stmt $pdo-prepare(SELECT points FROM t_user WHERE user_id ? FOR UPDATE); $stmt-execute([$user_id]); $current intval($stmt-fetchColumn()); $new_balance $current $change; if ($new_balance 0) { throw new Exception(insufficient_points); } $pdo-prepare(UPDATE t_user SET points ? WHERE user_id ?) -execute([$new_balance, $user_id]); $pdo-prepare(INSERT INTO t_point_log (user_id, change_point, balance, biz_type, biz_id, created_at) VALUES (?,?,?,?,?,NOW())) -execute([$user_id, $change, $new_balance, $biz_type, $biz_id]); $pdo-commit(); return true; } catch (Exception $e) { $pdo-rollBack(); return false; } }FOR UPDATE是关键它把用户行锁住确保先查余额再更新余额的间隙没有其他事务插进来。biz_id是业务单号比如task:12:20250116表示任务 12 在 2025 年 1 月 16 日产生的积分提现扣减则为withdraw:2001。如果源码包里没有统一入口而是散落着UPDATE t_user SET points points X建议重构成上面的结构否则永远算不清账。4.2 三级团队返佣怎么算衰减比例与死链处理三级团队是标题里的核心卖点。几乎这类源码都采用“一级 50%、二级 30%、三级 20%”或“一级 10%、二级 5%、三级 3%”的递减策略区别在于前者激进适合短周期拉新后者保守适合长期运营。我的建议是第一版采用保守模型原因很简单激进的返佣会催生刷团队。用户注册小号挂在自己下线一级返佣高时一个任务 5 积分他能拿回 2.5利润率接近 50%。团队分成计算函数如下function distribute_team_points(int $user_id, int $task_points, string $biz_type team): void { $levels [1 0.10, 2 0.05, 3 0.03]; $parent get_parent_id($user_id); for ($i 1; $i 3; $i) { if ($parent 0) { break; // 上上级不存在, 终止 } $bonus intval(floor($task_points * $levels[$i])); if ($bonus 0) { give_points($parent, $bonus, $biz_type, team:{$user_id}:{$i}); } $parent get_parent_id($parent); // 继续向上找 } }get_parent_id需要做缓存否则每笔任务返佣都要三次查询用户表。floor向下取整可以避免浮点误差也让极小值的分成直接归零减少碎积分。死链处理指的是用户 A 推荐 BB 又推荐 CC 完成任务时给 B 和 A 返佣。但如果 B 账号被封或者注销A 的返佣要不要跳到 D多数源码选择“断链不跨级”保证返佣路径清晰少数激进派会在用户表里存root_inviter来跨级。建议用前一种简单且不容易产生分账纠纷。4.3 上线前值得加的四个团队参数源码里团队模块通常只有固定的比例配置不够用。我一般会在config里加四个可控参数team_enable总开关用于活动结束后关闭返佣team_self_check是否允许用户推荐自己必须关掉team_level_limit最多算几级默认 3活动期间可临时降到 2team_bonus_ratio三级比例允许运营在后台动态调整加参数比改代码安全得多尤其当运营需要临时做 618 或双十一活动时改配置就能切换分润力度。5. 支付宝提现从申请到转账回调的闭环5.1 提现数据表与状态机设计withdraw.php是这套源码里最容易出安全问题的文件。提现必须走状态机不能做成“用户点一下PHP 直接调支付宝转账成功”。推荐状态表CREATE TABLE t_withdraw ( id int(11) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, amount_cent bigint(20) NOT NULL COMMENT 提现金额, 单位分, alipay_account varchar(64) NOT NULL, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0待审核 1已通过待转账 2转账中 3成功 4失败 5驳回, batch_no varchar(32) DEFAULT COMMENT 幂等键, audit_remark varchar(255) DEFAULT , created_at datetime NOT NULL, transferred_at datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_batch_no (batch_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;状态流转只有三条合法路径待审核 → 已通过 → 转账中 → 成功待审核 → 驳回转账中 → 失败。任何跳过“待审核”直接转账的实现都是隐患。batch_no是幂等键建议生成规则为W 年月日 用户ID 随机串例如W2025011612001x8k2。支付宝对同一batch_no的重复请求不会重复打款这是防止回调超时后重试导致双重转账的最后一道闸。5.2 支付宝转账接口对接金额单位与签名是两大坑支付宝企业转账对接用开放平台的alipay.fund.trans.toaccount.transfer接口。SDK 调用代码如下use Alipay\EasySDK\Payment\Common\Models\AlipayTradeRefundModel; $client new \Alipay\EasySDK\AlipayEasySDK(); $client-setConfig([ protocol https, gatewayHost openapi.alipay.com, signType RSA2, appId 2021000000000000, merchantPrivateKey $private_key, alipayPublicKey $alipay_public_key, ]); $result $client-common()-transfer([ out_biz_no $withdraw[batch_no], payee_account $withdraw[alipay_account], amount number_format($withdraw[amount_cent] / 100, 2, ., ), payee_type ALIPAY_LOGONID, remark 积分提现 ]);两个高频踩坑点。第一金额单位数据库里用分存储接口必须转成元的字符串number_format(..., 2)强制保留两位小数不能用浮点数直接拼接。第二公钥配置支付宝现在推荐使用公钥证书模式需要在开放平台上传应用公钥再下载支付宝公钥证书旧的alipayPublicKey字符串模式在部分产品线已经不再支持注册。真实环境里转账接口的返回码在异步通知里才体现最终结果transfer()同步返回10000只代表“受理成功”。所以代码里必须把同步返回为10000的记录标记为“转账中”而不是“成功”。5.3 异步回调的幂等处理与人工兜底支付宝会向配置的通知地址推送转账结果回调文件alipay_notify.php处理逻辑要遵循“先验签 → 再查单号 → 再更新状态”的顺序$ok $client-verifyNotify($_POST); if (!$ok) { exit(fail); } $batch_no trim($_POST[out_biz_no]); $status ($_POST[status] SUCCESS) ? 3 : 4; $pdo-beginTransaction(); try { $stmt $pdo-prepare(SELECT status FROM t_withdraw WHERE batch_no ? FOR UPDATE); $stmt-execute([$batch_no]); $current_status intval($stmt-fetchColumn()); if ($current_status 2) { // 只有转账中才允许状态更新 $pdo-prepare(UPDATE t_withdraw SET status ?, transferred_at NOW() WHERE batch_no ?) -execute([$status, $batch_no]); if ($status 4) { // 失败则退回积分 $w $pdo-query(SELECT user_id, amount_cent FROM t_withdraw WHERE batch_no {$batch_no})-fetch(); give_points(intval($w[user_id]), intval(ceil($w[amount_cent] / 100)), withdraw_refund, $batch_no); } } $pdo-commit(); exit(success); } catch (Exception $e) { $pdo-rollBack(); exit(fail); }状态判断里加FOR UPDATE是为了防止并发通知导致状态被覆盖为旧值。如果已经3成功重复通知不会改变状态如果是4失败事务回滚积分也不会重复执行。这是回调解耦的关键。另外后台管理页必须保留“转账失败后人工重新打款”的按钮不能完全依赖自动重试。自动转账连续失败三次就停住等待人工介入否则会把用户余额扣成负数。6. 上线前必调的验证与反作弊收尾6.1 用 curl 模拟完整任务链路部署完第一件事不要打开浏览器点界面用 curl 把三条链路打一遍# 1. 模拟阅读进度上报 15 次, 验证任务完成 for i in $(seq 1 15); do curl -s http://127.0.0.1/report.php?user_id1task_id3device_idtest001 sleep 1 done # 2. 查询用户积分, 确认余额与流水一致 curl -s http://127.0.0.1/api/user_info.php?user_id1 # 3. 提交提现申请 curl -s -X POST http://127.0.0.1/withdraw.php \ -d user_id1amount100alipay_accounttestexample.com正常预期是15 次后返回task_completed用户积分增加提现申请状态为「待审核」。如果第二次运行跑了 30 次才能完成说明进度上报累加逻辑有 bug。6.2 日志里追三个关键指标源码包里如果没有现成的日志类建议在report.php、withdraw.php、alipay_notify.php里加上请求和响应记录。不需要全量打印但至少要记录task_logs里progress每次跳变的幅度是否异常比如一次从 0 跳到 80同一device_id是否被多个user_id使用提现成功率成功笔数 / 转账中笔数低于 95% 说明账号或接口配置有问题6.3 上线第一周只盯配置不要频繁改代码上线后最容易出现的是任务奖励参数不合理。别急着改代码先用后台把reward_points从 3 调到 2观察完成率变化。单用户日收益控制在 1 元以内时套利刷子会主动放弃。如果连续三天提现失败率为 0再考虑放开团队返佣比例。这套源码能跑通不难难的是让它在没人手动干预的情况下稳定运转一周。调好日志、设好阈值、留好人工复核入口剩下交给时间。本文还有配套的精品资源点击获取
简介这套源码基于PHP开发是一套自动阅读挂机浏览广告新闻任务系统。面向需要搭建积分任务平台的站长、运营者以及PHP学习者能解决网站活跃度不足与广告曝光率提升的核心问题。系统整合了自动浏览、赚取积分、支付宝提现、小熊阅读以及三级团队推广等模块适用于新闻阅读、广告点击等任务激励场景。资源包共含4个文件压缩后约41.27MB包括项目源码ZIP、数据库脚本SQL、安装说明TXT以及界面文档HTM覆盖从部署到运行的完整链路。目前已有1198人学习下载通过阅读源码可系统掌握PHP任务调度、积分累计与兑换、支付接口对接、多级分销逻辑等关键实现尤其三级团队机制能清晰演示上下级关系维护与收益分配策略对理解裂变推广模式很有帮助。对于想快速上线类似平台的人来说按安装说明配置数据库与支付信息即可部署同时它也是一份完整的PHP业务系统学习案例非常适合作为二次开发参考。1. 基于PHP的自动阅读挂机任务源码先看闭环再看挂机这套源码真正值钱的不是“自动阅读”那几个 PHP 脚本而是它把任务派发、积分流水、三级团队佣金和支付宝提现串成了一个完整闭环。你从 zip 里解出一堆task.php、point.php、withdraw.php如果只盯着“怎么挂机”等于把系统里最不设防的那部分当成了核心。实际部署场景通常是积分任务站、地推激励或新闻资讯类 H5 的拉新玩法用户完成任务获得积分积分可以按比例提现推荐新用户还能拿三代佣金。适合的团队规模不大PHP 7.x MySQL 5.7 Redis 就能撑起来代码改造成本远低于从零设计一套账务系统。建议拿到源码包后先别急着装按“任务链路 → 积分链路 → 提现链路”的顺序读表结构和接口谁先谁后决定了你会不会在提现环节被账不平的问题坑一夜。2. 任务与积分系统的数据链路从任务派发到流水落库2.1 拆解 zip 源码包之前先确认四张核心表我一般拿到这类 PHP 源码包第一件事是打开install.sql或sql/migration.sql找四张表用户表、任务表、任务记录表、积分流水表。如果连这四张都没有说明源码只是演示版后面的积分和提现逻辑都只能靠猜。最小可运行的建表结构如下字段名可能因源码品牌不同有差异但信息量是必须的CREATE TABLE t_user ( user_id int(11) NOT NULL AUTO_INCREMENT, openid varchar(64) DEFAULT , invite_code varchar(12) DEFAULT , parent_id int(11) DEFAULT 0 COMMENT 推荐人ID, created_at datetime NOT NULL, PRIMARY KEY (user_id), UNIQUE KEY uk_invite_code (invite_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_task ( task_id int(11) NOT NULL AUTO_INCREMENT, task_type varchar(20) NOT NULL COMMENT read/ad/invite, title varchar(128) NOT NULL, reward_points int(11) NOT NULL DEFAULT 0 COMMENT 单次奖励积分, channel varchar(32) DEFAULT bear_reader COMMENT 渠道标识, 小熊阅读等来源, status tinyint(1) NOT NULL DEFAULT 1, PRIMARY KEY (task_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_task_log ( log_id bigint(20) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, task_id int(11) NOT NULL, task_date date NOT NULL, progress int(11) NOT NULL DEFAULT 0 COMMENT 进度, 通常按秒累计, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0进行中 1完成, finish_time datetime DEFAULT NULL, PRIMARY KEY (log_id), UNIQUE KEY uk_user_task_date (user_id,task_id,task_date), KEY idx_user_status (user_id,status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_point_log ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, change_point int(11) NOT NULL COMMENT 正负积分, balance int(11) NOT NULL COMMENT 变更后余额, biz_type varchar(20) NOT NULL COMMENT task/team/withdraw, biz_id varchar(64) NOT NULL COMMENT 关联业务单号, created_at datetime NOT NULL, PRIMARY KEY (id), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;四张表的核心逻辑是t_task_log记录“某个用户某天某个任务做了多少进度”t_point_log记录“每一笔积分变化的来龙去脉”。二者通过biz_id关联。如果源码里积分流水只有change_point没有balance快照那对账的时候会很痛苦建议自己补上。uk_user_task_date这个唯一键是被刷系统的防线之一同一用户同一天执行同一任务只允许一行记录。虽然 Redis 也能防但数据库唯一键是兜底Redis 挂了它还能挡住重复单。2.2 自动阅读进度上报的最小 PHP 实现挂机阅读的常见做法不是服务端 sleep而是前端 H5 页面每 N 秒上报一次阅读进度服务端记录进度达到阈值后结算积分。这样即使用户中途切走页面服务端也能判定任务未完成而不是白白发钱。前端定时器发送到report.php服务端代码如下?php // report.php?user_id1task_id3device_idabc $user_id intval($_GET[user_id] ?? 0); $task_id intval($_GET[task_id] ?? 0); $device_id substr((string)($_GET[device_id] ?? ), 0, 64); if (!$user_id || !$task_id) { http_response_code(400); exit(json_encode([code 1, msg 参数缺失])); } $pdo new PDO(mysql:host127.0.0.1;dbnametask_app, root, root); $pdo-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); $stmt $pdo-prepare( INSERT INTO t_task_log (user_id, task_id, task_date, progress, status) VALUES (?, ?, CURDATE(), 1, 0) ON DUPLICATE KEY UPDATE progress progress 1 ); $stmt-execute([$user_id, $task_id]); $row $pdo-query( SELECT ttl.progress, t.reward_points, t.ttl_seconds FROM t_task_log ttl LEFT JOIN t_task t ON t.task_id ttl.task_id WHERE ttl.user_id {$user_id} AND ttl.task_id {$task_id} AND ttl.task_date CURDATE() )-fetch(PDO::FETCH_ASSOC); if ($row $row[progress] $row[ttl_seconds] $row[status] 0) { // 达到阅读时长, 结算积分 give_points($user_id, $row[reward_points], task, $task_id); $pdo-prepare(UPDATE t_task_log SET status1, finish_timeNOW() WHERE user_id? AND task_id? AND task_dateCURDATE()) -execute([$user_id, $task_id]); exit(json_encode([code 0, msg 任务完成, points $row[reward_points]])); } echo json_encode([code 0, msg progress_ok, progress $row[progress] ?? 0]);ON DUPLICATE KEY UPDATE progress progress 1是这段代码的巧劲利用uk_user_task_date唯一键实现“有则累加、无则插入”避免了先 select 再 update 的竞态窗口。ttl_seconds是任务时长参数比如阅读一篇文章需要 60 秒那每 5 秒上报一次累计 12 次就结算。结算前再查一次status 0防止重复发积分。注意这段代码省略了give_points()的事务逻辑实际使用必须把积分流水写入放在同一个事务里否则会出现任务完成但积分没到账的现象。2.3 重复刷任务的防线Redis 锁与并发兜底进度上报接口天生容易被并发请求刷爆。一个用户开 10 个标签页同时打report.php如果只靠 MySQL 行锁高并发下 InnoDB 的锁竞争会让接口响应变慢而且ON DUPLICATE KEY UPDATE的原子性也会在极端情况下被打破。我一般会在进入数据库之前先走一层 Redis$lock_key task_progress:{$user_id}:{$task_id}: . date(Ymd); $ttl 10; // 锁10秒, 防止卡死 $result $redis-set($lock_key, $device_id, [NX, EX $ttl]); if (!$result) { exit(json_encode([code 2, msg 提交过快])); }锁的用途不是让所有请求串行而是丢弃“同一秒钟内的重复上报”。一个正常用户开一个页面5 秒上报一次不可能在 1 秒内提交两次。如果report.php里出现大量locked返回基本可以判定有人用脚本刷接口。Redis 锁加在$_GET参数校验之后、MySQL 写入之前。锁粒度按用户任务日期设计避免同一个用户做不同任务时互相阻塞。如果 Redis 不可用代码要能降级到直接走 MySQL靠唯一键兜底而不是整个接口 500 崩溃。3. 挂机阅读的调度设计与广告任务边界3.1 Crontab 定时任务PHP CLI 跑批的三种常见写法阅读挂机不能只靠用户开着页面服务端得有一个调度器负责兜底把超时未完成的任务自动关闭、把异常任务恢复、把团队收益按周期结算。大多数源码包里的调度就是 Linux crontab 加 PHP CLI 脚本没有用 Swoole 或 Workerman这是最稳的选择。通常三个调度任务# 每分钟执行一次: 处理超时未完成任务 * * * * * /usr/bin/php /var/www/task_app/cli/close_timeout_task.php /data/logs/close_task.log 21 # 每5分钟执行一次: 重推未成功的支付宝提现 */5 * * * * /usr/bin/php /var/www/task_app/cli/retry_withdraw.php /data/logs/retry_withdraw.log 21 # 每天凌晨3点执行: 团队积分复算与报表 0 3 * * * /usr/bin/php /var/www/task_app/cli/settle_team_report.php /data/logs/settle.log 21如果源码里没有这三个目录说明它只实现了前端接口没有后台调度。这时候要么自己补 CLI 脚本要么把逻辑塞进某个接口里被动触发——后者在用户量上来后一定会出问题。第一个任务close_timeout_task.php的逻辑很简单把t_task_log里status 0且超过任务时长 2 倍仍无进度的记录标记为过期。注意不要直接删除记录因为运营需要看到“有多少人读了开头但没读完”这类数据对调任务奖励有参考价值。3.2 阅读时长、浏览间隔与每日任务量参数怎么定“小熊阅读”这类频道模块本质上是在 H5 容器里嵌套一篇资讯文章然后挂上阅读进度逻辑。参数设置直接决定收益成本参数常见配置设置理由ttl_seconds单任务时长3090 秒太短没广告价值太长用户流失report_interval上报间隔5 秒兼顾服务端压力和防刷粒度daily_task_limit每日任务数815 个控制单用户每日积分上限reward_points单任务积分15 分1 积分 ≈ 0.01 元时单人日成本 12 元withdraw_min最低提现100 积分1元过低会增加支付宝转账手续费损耗withdraw_max_daily每日提现次数1 次降低异常提现频率这些参数在源码包里通常集中在config/config.php或者后台设置表里。真正上线时不要把reward_points设成固定值建议按文章字数或阅读时长动态计算否则会出现“30 秒短文和 5 分钟长文同一个价”的套利空间。3.3 与真实广告任务的边界不要伪造第三方点击必须提醒一个边界问题源码里的“挂机浏览广告新闻”如果只是自己的 H5 页面那随便怎么设计都合规但如果要去请求第三方广告链接并模拟点击大概率会触发对方风控甚至导致账号封禁。常见的折中方案是在源码里把“自动浏览”改为“半自动”用户点击“开始阅读”后H5 在 iframe 里加载目标文章但服务端只记录阅读时长不发送任何点击信号。代码上可以通过onload事件确认内容加载完成再开始计时let startTime null; const iframe document.getElementById(readerFrame); iframe.addEventListener(load, function () { startTime Date.now(); window.taskTimer setInterval(() { const seconds Math.floor((Date.now() - startTime) / 1000); navigator.sendBeacon(/report.php, new URLSearchParams({ user_id: USER_ID, task_id: TASK_ID, progress: seconds })); }, 5000); });这里使用sendBeacon而不是fetch是因为页面切后台或关闭时sendBeacon有更高的几率把最后一次进度送达服务端减少“读了最后一秒没算完”的客诉。4. 赚积分系统与三级团队一个能跑的分润模型4.1 积分账务每笔变动都带业务单号积分系统的核心不是如何增加而是如何保证账平。最稳妥的方式是所有积分变动只经过一个统一入口函数任何业务代码不得直接操作t_user.points字段。统一入口的写法function give_points(int $user_id, int $change, string $biz_type, string $biz_id): bool { $pdo get_pdo(); $pdo-beginTransaction(); try { // 行锁锁住用户行, 防止并发导致 balance 计算错误 $stmt $pdo-prepare(SELECT points FROM t_user WHERE user_id ? FOR UPDATE); $stmt-execute([$user_id]); $current intval($stmt-fetchColumn()); $new_balance $current $change; if ($new_balance 0) { throw new Exception(insufficient_points); } $pdo-prepare(UPDATE t_user SET points ? WHERE user_id ?) -execute([$new_balance, $user_id]); $pdo-prepare(INSERT INTO t_point_log (user_id, change_point, balance, biz_type, biz_id, created_at) VALUES (?,?,?,?,?,NOW())) -execute([$user_id, $change, $new_balance, $biz_type, $biz_id]); $pdo-commit(); return true; } catch (Exception $e) { $pdo-rollBack(); return false; } }FOR UPDATE是关键它把用户行锁住确保先查余额再更新余额的间隙没有其他事务插进来。biz_id是业务单号比如task:12:20250116表示任务 12 在 2025 年 1 月 16 日产生的积分提现扣减则为withdraw:2001。如果源码包里没有统一入口而是散落着UPDATE t_user SET points points X建议重构成上面的结构否则永远算不清账。4.2 三级团队返佣怎么算衰减比例与死链处理三级团队是标题里的核心卖点。几乎这类源码都采用“一级 50%、二级 30%、三级 20%”或“一级 10%、二级 5%、三级 3%”的递减策略区别在于前者激进适合短周期拉新后者保守适合长期运营。我的建议是第一版采用保守模型原因很简单激进的返佣会催生刷团队。用户注册小号挂在自己下线一级返佣高时一个任务 5 积分他能拿回 2.5利润率接近 50%。团队分成计算函数如下function distribute_team_points(int $user_id, int $task_points, string $biz_type team): void { $levels [1 0.10, 2 0.05, 3 0.03]; $parent get_parent_id($user_id); for ($i 1; $i 3; $i) { if ($parent 0) { break; // 上上级不存在, 终止 } $bonus intval(floor($task_points * $levels[$i])); if ($bonus 0) { give_points($parent, $bonus, $biz_type, team:{$user_id}:{$i}); } $parent get_parent_id($parent); // 继续向上找 } }get_parent_id需要做缓存否则每笔任务返佣都要三次查询用户表。floor向下取整可以避免浮点误差也让极小值的分成直接归零减少碎积分。死链处理指的是用户 A 推荐 BB 又推荐 CC 完成任务时给 B 和 A 返佣。但如果 B 账号被封或者注销A 的返佣要不要跳到 D多数源码选择“断链不跨级”保证返佣路径清晰少数激进派会在用户表里存root_inviter来跨级。建议用前一种简单且不容易产生分账纠纷。4.3 上线前值得加的四个团队参数源码里团队模块通常只有固定的比例配置不够用。我一般会在config里加四个可控参数team_enable总开关用于活动结束后关闭返佣team_self_check是否允许用户推荐自己必须关掉team_level_limit最多算几级默认 3活动期间可临时降到 2team_bonus_ratio三级比例允许运营在后台动态调整加参数比改代码安全得多尤其当运营需要临时做 618 或双十一活动时改配置就能切换分润力度。5. 支付宝提现从申请到转账回调的闭环5.1 提现数据表与状态机设计withdraw.php是这套源码里最容易出安全问题的文件。提现必须走状态机不能做成“用户点一下PHP 直接调支付宝转账成功”。推荐状态表CREATE TABLE t_withdraw ( id int(11) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, amount_cent bigint(20) NOT NULL COMMENT 提现金额, 单位分, alipay_account varchar(64) NOT NULL, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0待审核 1已通过待转账 2转账中 3成功 4失败 5驳回, batch_no varchar(32) DEFAULT COMMENT 幂等键, audit_remark varchar(255) DEFAULT , created_at datetime NOT NULL, transferred_at datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_batch_no (batch_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;状态流转只有三条合法路径待审核 → 已通过 → 转账中 → 成功待审核 → 驳回转账中 → 失败。任何跳过“待审核”直接转账的实现都是隐患。batch_no是幂等键建议生成规则为W 年月日 用户ID 随机串例如W2025011612001x8k2。支付宝对同一batch_no的重复请求不会重复打款这是防止回调超时后重试导致双重转账的最后一道闸。5.2 支付宝转账接口对接金额单位与签名是两大坑支付宝企业转账对接用开放平台的alipay.fund.trans.toaccount.transfer接口。SDK 调用代码如下use Alipay\EasySDK\Payment\Common\Models\AlipayTradeRefundModel; $client new \Alipay\EasySDK\AlipayEasySDK(); $client-setConfig([ protocol https, gatewayHost openapi.alipay.com, signType RSA2, appId 2021000000000000, merchantPrivateKey $private_key, alipayPublicKey $alipay_public_key, ]); $result $client-common()-transfer([ out_biz_no $withdraw[batch_no], payee_account $withdraw[alipay_account], amount number_format($withdraw[amount_cent] / 100, 2, ., ), payee_type ALIPAY_LOGONID, remark 积分提现 ]);两个高频踩坑点。第一金额单位数据库里用分存储接口必须转成元的字符串number_format(..., 2)强制保留两位小数不能用浮点数直接拼接。第二公钥配置支付宝现在推荐使用公钥证书模式需要在开放平台上传应用公钥再下载支付宝公钥证书旧的alipayPublicKey字符串模式在部分产品线已经不再支持注册。真实环境里转账接口的返回码在异步通知里才体现最终结果transfer()同步返回10000只代表“受理成功”。所以代码里必须把同步返回为10000的记录标记为“转账中”而不是“成功”。5.3 异步回调的幂等处理与人工兜底支付宝会向配置的通知地址推送转账结果回调文件alipay_notify.php处理逻辑要遵循“先验签 → 再查单号 → 再更新状态”的顺序$ok $client-verifyNotify($_POST); if (!$ok) { exit(fail); } $batch_no trim($_POST[out_biz_no]); $status ($_POST[status] SUCCESS) ? 3 : 4; $pdo-beginTransaction(); try { $stmt $pdo-prepare(SELECT status FROM t_withdraw WHERE batch_no ? FOR UPDATE); $stmt-execute([$batch_no]); $current_status intval($stmt-fetchColumn()); if ($current_status 2) { // 只有转账中才允许状态更新 $pdo-prepare(UPDATE t_withdraw SET status ?, transferred_at NOW() WHERE batch_no ?) -execute([$status, $batch_no]); if ($status 4) { // 失败则退回积分 $w $pdo-query(SELECT user_id, amount_cent FROM t_withdraw WHERE batch_no {$batch_no})-fetch(); give_points(intval($w[user_id]), intval(ceil($w[amount_cent] / 100)), withdraw_refund, $batch_no); } } $pdo-commit(); exit(success); } catch (Exception $e) { $pdo-rollBack(); exit(fail); }状态判断里加FOR UPDATE是为了防止并发通知导致状态被覆盖为旧值。如果已经3成功重复通知不会改变状态如果是4失败事务回滚积分也不会重复执行。这是回调解耦的关键。另外后台管理页必须保留“转账失败后人工重新打款”的按钮不能完全依赖自动重试。自动转账连续失败三次就停住等待人工介入否则会把用户余额扣成负数。6. 上线前必调的验证与反作弊收尾6.1 用 curl 模拟完整任务链路部署完第一件事不要打开浏览器点界面用 curl 把三条链路打一遍# 1. 模拟阅读进度上报 15 次, 验证任务完成 for i in $(seq 1 15); do curl -s http://127.0.0.1/report.php?user_id1task_id3device_idtest001 sleep 1 done # 2. 查询用户积分, 确认余额与流水一致 curl -s http://127.0.0.1/api/user_info.php?user_id1 # 3. 提交提现申请 curl -s -X POST http://127.0.0.1/withdraw.php \ -d user_id1amount100alipay_accounttestexample.com正常预期是15 次后返回task_completed用户积分增加提现申请状态为「待审核」。如果第二次运行跑了 30 次才能完成说明进度上报累加逻辑有 bug。6.2 日志里追三个关键指标源码包里如果没有现成的日志类建议在report.php、withdraw.php、alipay_notify.php里加上请求和响应记录。不需要全量打印但至少要记录task_logs里progress每次跳变的幅度是否异常比如一次从 0 跳到 80同一device_id是否被多个user_id使用提现成功率成功笔数 / 转账中笔数低于 95% 说明账号或接口配置有问题6.3 上线第一周只盯配置不要频繁改代码上线后最容易出现的是任务奖励参数不合理。别急着改代码先用后台把reward_points从 3 调到 2观察完成率变化。单用户日收益控制在 1 元以内时套利刷子会主动放弃。如果连续三天提现失败率为 0再考虑放开团队返佣比例。这套源码能跑通不难难的是让它在没人手动干预的情况下稳定运转一周。调好日志、设好阈值、留好人工复核入口剩下交给时间。本文还有配套的精品资源点击获取
