简介：一份基于PHP的企业三级分销与报单会员系统源码，面向需要搭建推广返佣体系的中小企业、电商运营方及PHP开发者，可快速部署会员邀请、三级分佣、商城销售与后台管理流程。资源压缩包共含745个文件，大小约16.26MB，主要文件类型为PHP业务脚本、JavaScript前端逻辑、CSS样式表及GIF/JPG/PNG图片素材，并附带SQL数据库文件和授权说明，结构清晰，便于直接导入或二次开发。目前已有259人学习下载。整套源码覆盖三级推广层级奖励、商品浏览、购物车、订单管理、第三方支付接口集成、自定义会员等级以及后台手动报单等功能，同时支持PC与移动端自适应访问；开发者可结合业务需求调整分销比例、会员权益与订单流程，适合作为会员增长型电商项目的起始框架。
1. 把分销返佣做进注册链路，先想清楚钱怎么走
三级推广报单分销源码在私域电商和社群裂变场景里一直有需求，但真正容易翻车的地方不在 PHP 代码，也不在 MySQL 表结构，而在返佣计算的边界条件：报单金额谁来确认、层级关系在哪个时机写入、佣金结算按什么状态触发。代码可以到处下载，但能跑通的业务闭环往往是现场调出来的。这套系统本质上是把「会员注册、报单付款、上级返佣、提现审核」四件事串成一条状态机，写代码前先把状态流转画清楚，比选框架重要得多。适合正在做微分销、社区团购或代理商体系的技术负责人参考，新手也能按后面的最小实现一步步跑通。
2. 三级分销的分佣模型与表结构设计
2.1 三级返佣的数学表达和“越级”陷阱
三级分销的核心规则是：一个订单只给上三级返佣，第四级及以上不参与。用公式表达就是：订单产生佣金总额为amount * rate，一级拿rate1，二级拿rate2，三级拿rate3，且rate1 + rate2 + rate3 <= 1。这是硬约束，不能靠代码逻辑去兜底，必须建表时就把比例字段设计成可配置。
真正容易出问题的是“越级”的判定。比如 A 推荐 B，B 推荐 C，C 下单，此时 A 是一级、B 是二级；但如果 C 又推荐了 D，D 下单时 C 是一级、B 是二级、A 是三级。这里的关键是：不能从订单发起人向上无脑查三代，因为如果中间有断开（比如某用户没有推荐人），链条就会断。常见做法是用户表里存parent_id，同时冗余一个referrer_chain字段记录完整的祖先路径，用逗号分隔。这样查询时直接按FIND_IN_SET或者拆字符串就能定位上三级，而不需要递归查表。
层级深度必须在注册时锁定。我见过很多项目在用户表里只存parent_id，等到结算时再递归查，结果用户量过了十万后接口直接超时。正确做法是在注册时就计算好这个用户在所有祖先节点中的层级偏移，至少把上三级的用户 ID 直接冗余到一张user_relation表里，字段分别为user_id、level1_id、level2_id、level3_id，这样结算时一次 JOIN 就拿到所有返佣对象。
2.2 报单表与佣金流水表的关键字段
报单是这套系统的资金入口，不能和普通订单表混在一起。建议单独建一张report_order表，核心字段如下：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| order_no | varchar | 唯一订单号，业务编号 |
| user_id | int | 报单人 |
| product_id | int | 报单产品 |
| amount | decimal(10,2) | 报单金额 |
| status | tinyint | 0待支付 1已支付 2已结算 3已取消 |
| pay_time | datetime | 支付时间 |
| settle_time | datetime | 佣金结算时间 |
| remark | varchar | 备注 |
佣金流水表commission_log要记录每一笔返佣的来源订单，字段包括order_id、from_user_id（产生订单的人）、to_user_id（拿到佣金的人）、level（一级/二级/三级）、amount、status（0冻结 1可提现 2已提现）。status 字段的存在是为了处理售后退款场景——如果订单退款了，佣金要能原路撤回。
提示：比例配置不要写死在代码里，放到系统配置表。运营人员改比例时不需要发版，而且不同产品线可能用不同比例。
2.3 注册时生成推荐关系的 SQL 实现
注册链路中推荐关系的写入要放在事务里。推荐码建议用用户 ID 做 Base64 编码或者直接拼接随机串，但必须在users表上加唯一索引。注册时的核心逻辑是：先校验推荐码有效性，然后拿到推荐人的上三级，生成user_relation记录。
-- 注册时写入推荐关系 START TRANSACTION; INSERT INTO users (username, password, parent_id, referrer_code) VALUES ('new_user', 'hashed_pwd', $parentId, 'CODE123'); SET @newUserId = LAST_INSERT_ID(); -- 查询推荐人的上三级 SELECT id, @lv1 := parent_id, @lv2 := (SELECT parent_id FROM users WHERE id = @lv1), @lv3 := (SELECT parent_id FROM users WHERE id = @lv2) FROM users WHERE id = $parentId; INSERT INTO user_relation (user_id, level1_id, level2_id, level3_id) VALUES (@newUserId, @lv1, @lv2, @lv3); COMMIT;这段逻辑的关键点是：@lv1是直接推荐人，@lv2是推荐人的推荐人，以此类推。如果某个层级不存在（比如推荐人本身没有上级），对应字段存 NULL 即可。这样在后续结算时，对任意一个订单只需要查一次user_relation表，不需要递归操作。注册请求的并发量上去以后，这一步的事务耗时基本可以控制在 10ms 以内。
3. 报单流程与佣金结算的事务实现
3.1 报单创建、支付回调与状态流转的三段式
报单流程拆成三步：创建订单 -> 支付回调 -> 结算佣金。创建订单时只生成待支付状态，不触发任何佣金计算；支付回调才是真正的业务入口，必须做幂等处理。常见做法是在report_order表上对order_no加唯一索引，回调处理时先尝试更新状态，如果更新影响行数为 0 说明重复回调，直接丢弃。
状态机约束是：0(待支付) -> 1(已支付) -> 2(已结算)，不允许跳变。已结算状态只能由支付成功后的同一个事务写入，不能由定时任务扫描补写，否则会出现用户未支付但佣金已发放的资损漏洞。
// 支付回调处理方法 public function handlePayNotify($orderNo, $payAmount) { $order = ReportOrder::where('order_no', $orderNo)->first(); if (!$order || $order->status != 0) { return false; // 订单不存在或已处理 } if (bccomp($order->amount, $payAmount, 2) !== 0) { Log::error('金额不一致：订单' . $orderNo); return false; } DB::transaction(function () use ($order) { $order->status = 1; $order->pay_time = now(); $order->save(); // 佣金结算放在这里 $this->settleCommission($order); $order->status = 2; $order->settle_time = now(); $order->save(); }); return true; }金额比较用bccomp而不是==，是因为浮点数直接比较在 PHP 里会出问题。整个支付回调和佣金结算在同一个事务里，要么全部成功要么全部回滚，避免出现支付成功但佣金没发的情况。
3.2 按user_relation表批量写入三级佣金
结算逻辑先读订单的报单人信息，然后按报单人的 ID 反查user_relation表，拿到三个层级的用户 ID，再按照配置表里的比例逐一计算佣金并写入commission_log。
public function settleCommission($order) { // 查询报单人的上级关系 $relation = UserRelation::where('user_id', $order->user_id)->first(); if (!$relation) return; // 读取分佣配置 $rate1 = Config::get('commission_rate_level1'); // 0.1 $rate2 = Config::get('commission_rate_level2'); // 0.05 $rate3 = Config::get('commission_rate_level3'); // 0.03 $levels = [ 1 => [$relation->level1_id, $rate1], 2 => [$relation->level2_id, $rate2], 3 => [$relation->level3_id, $rate3], ]; foreach ($levels as $level => [$userId, $rate]) { if (!$userId) continue; $amount = bcmul($order->amount, $rate, 2); if ($amount <= 0) continue; CommissionLog::create([ 'order_id' => $order->id, 'from_user_id' => $order->user_id, 'to_user_id' => $userId, 'level' => $level, 'amount' => $amount, 'status' => 0, // 冻结状态 ]); } // 更新用户可提现余额 DB::table('users') ->whereIn('id', [$relation->level1_id, $relation->level2_id, $relation->level3_id]) ->increment('balance', ...); }注意这里佣金先写入冻结状态，等过了售后期（比如 7 天）再统一解冻。否则用户下单后立刻申请退款，佣金已经提现走了，平台就要垫钱。常见做法是加一个定时任务，扫描订单状态为已完成且超过售后期未退款的记录，把对应的commission_log从 0 更新为 1。
3.3 并发扣减与余额操作的悲观锁处理
佣金发放涉及用户余额变更，并发下会出现超发或负数。最简单的方案是在 PHP 层面用lockForUpdate()锁行。开启一个事务，先SELECT ... FOR UPDATE锁定用户行，再执行余额扣减或增加，最后提交事务。
DB::transaction(function () use ($userId, $amount) { $user = User::where('id', $userId)->lockForUpdate()->first(); $user->balance = bcadd($user->balance, $amount, 2); $user->save(); CommissionLog::where('user_id', $userId) ->where('status', 0) ->update(['status' => 1]); });数据库层面再把users.balance字段加上非负约束，双保险。用bcadd而不是直接+，防止浮点精度问题导致余额多了几分钱。
提示：高并发场景下用 Redis 分布式锁替代数据库锁行，但在用户量没到百万级之前，MySQL 的行锁完全够用且实现简单、不容易写错。
4. 提现审核链路与会员等级的价值耦合
4.1 最小可用的提现申请到打款闭环
提现流程用户端就三步：提交申请、等待审核、确认到账。后端要设计的核心是「提现单」状态机：0(待审核) -> 1(审核通过) -> 2(已打款) / -1(驳回)。在审核通过时就要把用户余额冻结，而不是等到打款时再扣，否则会出现在审核期间用户把钱消费掉的问题。
public function auditWithdraw($withdrawId, $approve) { DB::transaction(function () use ($withdrawId, $approve) { $withdraw = Withdraw::where('id', $withdrawId)->lockForUpdate()->first(); if ($withdraw->status != 0) return; if ($approve) { $user = User::where('id', $withdraw->user_id)->lockForUpdate()->first(); if ($user->balance < $withdraw->amount) { throw new \Exception('余额不足，无法通过审核'); } $user->balance = bcsub($user->balance, $withdraw->amount, 2); $user->frozen_balance = bcadd($user->frozen_balance, $withdraw->amount, 2); $user->save(); $withdraw->status = 1; } else { $withdraw->status = -1; $withdraw->reject_reason = request('reason'); } $withdraw->save(); }); }驳回时不需要退回余额，因为用户从未扣款。审核通过后余额转到冻结余额，打款成功后再把冻结余额清掉并写入打款单号。这一步的钱是真正从平台账户出去的，所以打款动作要么调用第三方代付接口，要么人工线下转账后在后台打上「已打款」标记。
4.2 把返佣和积分/等级解耦的配置方案
很多分销系统把「会员等级」和「累计充值」或者「团队业绩」绑在一起，这不是业务必须的，但确实能提升复购率。技术实现上不复杂：用户表增加growth_value字段，每次报单成功按订单金额累加成长值，等级表配置各等级对应的成长值区间。佣金比例从「固定比例」改成「按等级配置」，即每个等级有独立的三个返佣比例。
这时候配置表要设计成level_commission：level_id、rate1、rate2、rate3。结算时先取报单人的等级，再读对应比例。注意这里报单人的等级决定了这笔订单的佣金比例，而不是拿佣金的人——这条规则如果搞反了，整个体系就乱套了。会员等级升级时不需要重新计算历史佣金，只对之后的订单生效，运营规则上提前说清楚即可。
4.3 财务对账单与订单明细的核对脚本
上线三个月后你一定会遇到这种情况：运营拿后台的佣金汇总数和实际打款数对不上。原因往往出在退款订单的佣金没撤回、或者线上环境有人手工改了数据库。所以从第一天就要留好对账脚本，每天凌晨拉取前一天的订单、佣金流水、提现记录，生成三张表的汇总比对：
-- 按天对账：订单金额 vs 佣金支出 SELECT DATE(pay_time) AS dt, SUM(amount) AS total_order_amount, (SELECT SUM(amount) FROM commission_log WHERE DATE(create_time) = DATE(pay_time) AND status IN (0,1)) AS total_commission FROM report_order WHERE status IN (1,2) GROUP BY DATE(pay_time);如果total_order_amount * (rate1+rate2+rate3)和实际total_commission差超过一块钱，就发告警通知。这个脚本不复杂但极其管用，能顶住大多数运营扯皮。再进一步可以做逐笔比对，把每笔订单的佣金流水明细导出，但那是后话了。
5. 保障返佣资金安全的 3 个校验参数
5.1 同一个 IP 注册多个账号的批量识别
刷佣金最常见的手法是用同一台设备或者代理 IP 批量注册账号，形成自买自卖的闭环。防刷不能只靠验证码，因为打码平台已经非常成熟。我一般会在注册接口里做三个层面的校验：IP 维度（同一 IP 24 小时注册超过 N 个就进入风控）、设备指纹维度（前端上报的 UA 和 Canvas 指纹）、推荐链维度（新注册用户的直接推荐人如果本身注册时间不足 24 小时，则延迟结算佣金）。
// 前端上报设备指纹到后端 const fingerprint = { ua: navigator.userAgent, canvas: getCanvasFingerprint(), // 示例函数 screen: `${screen.width}x${screen.height}`, timezone: new Date().getTimezoneOffset() }; fetch('/api/register', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ ...formData, device: fingerprint }) });后端对device.ua做 MD5 存储，同一天相同指纹注册超过阈值直接拒绝。这里的阈值要根据业务量调，一般 C 端产品设 2~3 个比较合理，因为正常家庭可能有夫妻两人都用同一部手机注册。
注意：设备指纹只能作为辅助风控，不能作为唯一判断标准，误杀率会很高。
5.2 退款自动撤回佣金的补偿事务
售后发生时要原路撤回已经发放的佣金。如果佣金还在冻结状态（status=0），直接删除或置为失效即可；如果是已解冻甚至已提现，就要生成一条负数佣金记录，在用户下次产生佣金时抵扣。
public function refundOrder($orderId) { DB::transaction(function () use ($orderId) { $order = ReportOrder::where('id', $orderId)->lockForUpdate()->first(); if ($order->status == 3) return; // 已退款不再处理 // 撤回该订单的佣金 $commissions = CommissionLog::where('order_id', $orderId)->get(); foreach ($commissions as $commission) { if ($commission->status == 2) { // 已提现，生成负数记录抵扣 CommissionLog::create([ 'order_id' => $orderId, 'from_user_id' => $commission->to_user_id, 'to_user_id' => $commission->to_user_id, 'level' => $commission->level, 'amount' => -$commission->amount, 'status' => 1, ]); } else { $commission->status = -1; // 标记为失效 $commission->save(); } } $order->status = 3; $order->save(); }); }负数佣金本质上就是欠款，用户下次提现时系统自动扣除。这种方式比直接扣减余额要安全，因为如果用户余额已经提空，扣减会失败，而负数流水是独立记账，不影响用户的实际余额操作逻辑。
5.3 后台一键锁定异常账号后的手工修正
分销系统上线后一定会出现恶意刷单、关系链异常、乃至运营误操作等情况，后台必须预留一个「强制修正」入口。实现上就是一组接口：重置某用户的上级关系、手工补发佣金、作废某笔佣金流水。其中最常用的是重置上级关系：把users.parent_id和user_relation中相关记录重建。
# 重置上下级关系（仅限后台操作） php artisan user:rebind --user_id=10023 --new_parent_id=5001执行时脚本会先注销旧的关系行，再重新计算新链路上的三级关系，同时保留一条审计日志记录操作人和时间。这个入口只对客服和管理员开放，生产环境还要做二次确认弹窗。没有这个兜底手段，真出了问题就只能连数据库操作，风险太大。
6. 用压测脚本验证你的分销链路扛得住 10 万用户
6.1 模拟注册与报单的并发脚本
代码写完，下一步是证明它能扛住真实流量。用 PHP 自带的 Swoole 协程或者 Go 写个简单的压测脚本，模拟注册 -> 报单 -> 结算全流程。
// 用 Go 模拟 1000 个并发注册+报单 package main import ( "fmt" "net/http" "net/url" "sync" ) func main() { var wg sync.WaitGroup for i := 0; i < 1000; i++ { wg.Add(1) go func(i int) { defer wg.Done() resp, err := http.PostForm("http://localhost:8080/api/register", url.Values{"username": {fmt.Sprintf("user%d", i)}, "referrer": {"code_1"}}) if err != nil { fmt.Printf("注册失败: %v\n", err) } resp.Body.Close() }(i) } wg.Wait() fmt.Println("注册压测完成") }压测前先准备 1 个根账号，然后所有新用户都以这个账号为直接推荐人，这样能形成三级链路。跑完后检查users表、user_relation表的记录数是否一致，然后抽查几个用户的三级关系是否和预期一致。如果出现user_relation缺失的记录，说明事务没做好，注册用户的父级链子在并发下读到了脏数据。
6.2 排查佣金漏发与重复发放的 SQL 验证语句
压测跑完的验证比压测本身更重要。用几条 SQL 就能快速检查佣金是否漏发或重复发：
-- 检查是否存在重复佣金 SELECT order_id, to_user_id, level, COUNT(*) FROM commission_log GROUP BY order_id, to_user_id, level HAVING COUNT(*) > 1; -- 检查漏发（订单金额不为0但佣金记录缺失） SELECT o.id, o.order_no FROM report_order o LEFT JOIN commission_log c ON o.id = c.order_id WHERE o.status = 2 AND c.id IS NULL; -- 检查佣金是否超过合法比例上限 SELECT c.order_id, SUM(c.amount) / o.amount AS total_rate FROM commission_log c LEFT JOIN report_order o ON c.order_id = o.id WHERE c.status IN (0, 1) GROUP BY c.order_id HAVING total_rate > 0.18; -- 假设三级比例之和为18%第三条验证尤其重要，如果出现 total_rate 超过配置比例，大概率是结算回调被重复执行，或者事务边界没控制好。出现这种情况时去看支付回调的幂等处理，而不是去改 SQL。压测时故意把配置的比例调成 0.1+0.05+0.03=0.18，跑完验证这条 SQL，能发现大部分事务问题。
6.3 一个让用户“永远查不到自己下级”的索引坑
最后一个容易踩的坑是索引设计。运营后台常见需求是「查看某用户的所有下级」，如果你在users.parent_id上没建索引，数据量到 50 万时这条查询会直接卡死。但更隐蔽的问题是：FIND_IN_SET无法走索引，如果你用referrer_chain LIKE '%123%'这种方式查下级列表，性能一样会崩。正确做法是建一张独立的user_tree_path表，存ancestor_id和descendant_id，两个字段都加联合索引。这样查某用户的所有下级只需WHERE ancestor_id = $id，毫秒级返回。这张表的数据在注册、重置关系时同步维护。如果不想多维护一张表，那就接受parent_id索引下只支持查直接下级，多级下级用队列异步展开。
本文还有配套的精品资源，点击获取
