尧图网页设计 
简介这份PHP代理分销系统是一套面向中小电商企业、代理分销创业者及PHP开发者的电子商务解决方案重点解决多级代理管理、佣金结算与商城运营问题适合具备一定PHP基础、希望研究电商系统架构或进行二次开发的技术人员。压缩包为rar格式整体约11.5MB上游未提供具体文件数量与类型明细从描述看应包含前后台源码、数据库脚本及接口配置等核心内容。系统前端涵盖注册登录、商品展示、购物车、订单处理与客户服务后端则提供商品管理、代理分销审核与佣金计算、订单发货退款、用户管理及销售数据统计等模块并可能采用MVC架构与MySQL数据库集成支付宝、微信支付及物流接口。目前已有1349人学习下载读者可借此理解代理分销的等级设定与佣金逻辑掌握电商系统的目录组织与二次开发思路同时学习数据加密、防SQL注入与XSS攻击等安全处理要点为自建商城或定制功能提供参考。1. PHP代理分销系统从一套无限级关系链说起很多人第一次接触 PHP代理分销系统脑子里想的是三级返佣、拉人头、自动结算但真正落到代码上第一个卡住你的不是佣金公式而是代理关系怎么存。我见过太多项目代理表里塞一个parent_id就开干上线三个月后运营要查某个代理下面第 7 层的总业绩一条递归 SQL 直接把数据库拖垮。所以这篇笔记不讲分销模式怎么设计得花哨只讲一套能跑、能扛、能查的 PHP代理分销系统该怎么落地代理层级怎么建模、佣金怎么算不重复、订单回调怎么防并发、后台怎么查下级。适合正在用 PHP 做分销、返佣、渠道管理这类系统的后端同学也适合接手别人半成品源码、被无限级查询折磨过的运维。我一般把这类系统拆成四块代理关系树、订单归因、佣金结算、后台查询。四块里任何一块偷懒后面都要还债。下面按我实际做过的顺序从数据建模一路讲到并发和排查中间给的都是能直接抄的 PHP 代码和 SQL参数怎么调、坑在哪都会说清楚。2. 代理关系树怎么建邻接表、路径枚举还是闭包表代理分销系统的地基是关系树。选错存储方式后面每一次查下级都是血泪经验。这一章把三种主流方案摆出来说清各自边界再给一套我常用的混合方案。2.1 三种层级存储方案的取舍邻接表parent_id是最省事的每个代理存一个上级 ID。写入快改上级也快但查所有下级必须递归。MySQL 8 之前没有递归 CTE只能靠 PHP 循环查库层级一深就是 N 次查询代理上千后后台列表直接转圈。路径枚举path给每个代理存一条从根到自己的路径比如1/5/23/。查某代理的所有下级只要WHERE path LIKE 1/5/23/%一条 SQL 搞定索引也能用上。代价是移动代理换上级时要批量改所有子孙的 path写放大明显。闭包表closure table单独建一张关系表存每一对祖先-后代的距离。查询任意层级都是等值 JOIN最灵活但表行数是 O(n²) 级别代理规模上万后维护成本高。我的选择是路径枚举为主parent_id 冗余保留。理由很实际——分销系统里换上级是低频操作而查下级业绩是高频操作用低频的写代价换高频的读性能划算。parent_id 留着是为了单层查询和后台展示方便不用每次解析 path。2.2 建表 SQL 与字段说明CREATE TABLE agent ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, parent_id BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT 直接上级ID0为根, path VARCHAR(255) NOT NULL DEFAULT COMMENT 层级路径形如 1/5/23/, level TINYINT UNSIGNED NOT NULL DEFAULT 1 COMMENT 自身层级根为1, username VARCHAR(64) NOT NULL, rate DECIMAL(5,4) NOT NULL DEFAULT 0.1000 COMMENT 自身佣金比例, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 0冻结, created_at INT UNSIGNED NOT NULL DEFAULT 0, PRIMARY KEY (id), KEY idx_path (path), KEY idx_parent (parent_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;path用1/5/23/这种前后都带斜杠的格式是为了让LIKE 1/5/%不会误匹配到1/50/。level冗余存一份省得每次数斜杠。rate用 DECIMAL 不用 FLOAT佣金算钱千万别用浮点这是踩过的坑。新增代理时path 由上级拼出来function createAgent(PDO $pdo, int $parentId, string $username, float $rate): int { // 先取上级信息根代理 parentId0 时 path 为空 if ($parentId 0) { $stmt $pdo-prepare(SELECT path, level FROM agent WHERE id ? AND status 1); $stmt-execute([$parentId]); $parent $stmt-fetch(PDO::FETCH_ASSOC); if (!$parent) { throw new RuntimeException(上级不存在或已冻结); } $path $parent[path] . $parentId . /; $level $parent[level] 1; } else { $path ; $level 1; } $stmt $pdo-prepare( INSERT INTO agent (parent_id, path, level, username, rate, created_at) VALUES (?,?,?,?,?,?) ); $stmt-execute([$parentId, $path, $level, $username, $rate, time()]); $id (int)$pdo-lastInsertId(); // 根代理自身 path 补上自己的 id保证格式统一 if ($parentId 0) { $pdo-prepare(UPDATE agent SET path ? WHERE id ?)-execute([$id . /, $id]); } return $id; }逻辑上分两步先根据上级算出自己的 path 和 level插入后再给根代理补 path。参数$parentId传 0 表示建根代理$rate是自身佣金比例建议限制在 0 到 1 之间入库前做校验。注意这里没有做并发保护同一上级下并发建代理不会冲突因为 path 只依赖上级不依赖兄弟节点。2.3 查下级一条 SQL 拿到整棵子树有了 path查某代理的所有下级就是SELECT id, username, level, rate FROM agent WHERE path LIKE CONCAT((SELECT path FROM agent WHERE id :id), :id, /%) AND status 1 ORDER BY level ASC, id ASC;这里CONCAT(path, id, /)拼出的是以该代理为前缀的路径。比如代理 5 的 path 是1/那它的下级前缀就是1/5/所有 path 以1/5/开头的都是它的子孙。ORDER BY level让结果按层级排后台展示直接能用。提示LIKE 前缀%能走索引但前缀是动态拼的MySQL 优化器有时会放弃索引。代理量超过 5 万后建议把前缀在 PHP 里算好再传进去别在 SQL 里套子查询。如果要查某代理下面第 N 层加一个level 上级level N条件即可不用递归。这就是路径枚举最爽的地方。3. 订单归因与佣金结算怎么算不重复、不遗漏关系树建好只是开始真正让分销系统翻车的是佣金。用户下单钱该分给谁、分几层、比例怎么叠稍不注意就重复返佣或者漏返。这一章讲归因和结算的完整链路。3.1 订单归因绑定关系与下单快照归因的核心问题是这笔订单算哪个代理的业绩常见做法是用户注册时绑定一个代理user.agent_id下单时把这个 agent_id 写进订单。但这里有个坑——如果用户后来换了绑定代理历史订单的归属会跟着变对账时全是糊涂账。我的做法是下单时打快照订单表里存agent_id和agent_path一旦写入不再改。这样即使代理关系树后来调整历史订单的归属永远稳定。CREATE TABLE order ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, user_id BIGINT UNSIGNED NOT NULL, agent_id BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT 归属代理快照, agent_path VARCHAR(255) NOT NULL DEFAULT COMMENT 下单时代理路径快照, amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已退款, created_at INT UNSIGNED NOT NULL DEFAULT 0, PRIMARY KEY (id), KEY idx_agent (agent_id), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;agent_path存的是下单时该代理的完整路径比如1/5/23/。有了它结算时不用再查 agent 表就能知道要分几层、分给谁。3.2 佣金计算按路径逐层返比例可配置佣金规则我一般做成逐层递减一级代理拿最高比例往上逐层降低到某个层级封顶。比例存在配置表里不写死在代码。function calcCommission(string $agentPath, float $amount, array $rateMap): array { // agentPath 形如 1/5/23/拆出所有祖先ID含自身 $ids array_filter(explode(/, $agentPath), strlen); $ids array_reverse($ids); // 从最近的代理往上算 $result []; $depth 0; foreach ($ids as $agentId) { $depth; if (!isset($rateMap[$depth])) { break; // 超过配置层级停止返佣 } $rate $rateMap[$depth]; $fee round($amount * $rate, 2); if ($fee 0) { continue; } $result[] [agent_id (int)$agentId, depth $depth, rate $rate, fee $fee]; } return $result; }$rateMap形如[1 0.10, 2 0.05, 3 0.02]表示一级返 10%、二级 5%、三级 2%。array_reverse保证从离订单最近的代理开始算depth 从 1 递增。round(..., 2)是必须的金额保留两位小数避免出现0.30000000000000004这种浮点尾巴。注意$rateMap的总和不要超过 1否则会出现返佣总额大于订单金额的资损。上线前一定要加一道校验array_sum($rateMap) 1。3.3 结算落库幂等是底线佣金算出来要写进佣金流水表这一步最大的风险是重复结算。支付回调可能重试定时任务可能重跑没有幂等保护就会重复返佣。CREATE TABLE commission ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, order_id BIGINT UNSIGNED NOT NULL, agent_id BIGINT UNSIGNED NOT NULL, depth TINYINT UNSIGNED NOT NULL, rate DECIMAL(5,4) NOT NULL, fee DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1已入账 0已撤销, created_at INT UNSIGNED NOT NULL DEFAULT 0, PRIMARY KEY (id), UNIQUE KEY uk_order_agent (order_id, agent_id), KEY idx_agent (agent_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;关键在UNIQUE KEY (order_id, agent_id)。同一订单对同一代理只能有一条佣金记录重复插入直接报唯一键冲突用INSERT ... ON DUPLICATE KEY UPDATE或者捕获异常都能实现幂等。function settleOrder(PDO $pdo, int $orderId): void { $pdo-beginTransaction(); try { // 加行锁防止并发重复结算 $stmt $pdo-prepare(SELECT * FROM order WHERE id ? AND status 1 FOR UPDATE); $stmt-execute([$orderId]); $order $stmt-fetch(PDO::FETCH_ASSOC); if (!$order) { $pdo-rollBack(); return; } $rateMap [1 0.10, 2 0.05, 3 0.02]; $list calcCommission($order[agent_path], (float)$order[amount], $rateMap); $ins $pdo-prepare( INSERT INTO commission (order_id, agent_id, depth, rate, fee, created_at) VALUES (?,?,?,?,?,?) ON DUPLICATE KEY UPDATE fee VALUES(fee), rate VALUES(rate) ); foreach ($list as $row) { $ins-execute([$orderId, $row[agent_id], $row[depth], $row[rate], $row[fee], time()]); } $pdo-commit(); } catch (Throwable $e) { $pdo-rollBack(); throw $e; } }FOR UPDATE锁住订单行保证同一订单不会被两个进程同时结算。ON DUPLICATE KEY UPDATE让重跑安全。参数上status 1表示只结算已支付订单退款时把对应佣金status置 0 即可不要物理删除留痕对账。4. 高并发下的订单回调与队列处理分销系统一旦接支付回调就是并发重灾区。用户支付成功支付平台可能连发三次通知你的接口如果每次都跑一遍结算轻则重复返佣重则数据库锁等待拖垮整个站。这一章讲怎么把回调削峰、怎么用队列兜底。4.1 回调接口只做两件事验签和入队我的原则是回调接口越薄越好。验签通过后不直接结算而是把订单号丢进队列立刻返回成功。这样支付平台不会因为你的结算慢而重试。// 回调入口仅验签 入队 function notifyHandler(PDO $pdo, array $post): string { if (!verifySign($post)) { return fail; } $orderNo $post[out_trade_no] ?? ; if ($orderNo ) { return fail; } // 幂等已处理过的回调直接返回成功 $stmt $pdo-prepare(SELECT id FROM order WHERE id ? AND status 1); $stmt-execute([$orderNo]); if ($stmt-fetch()) { return success; } // 入队交给后台 worker 结算 $pdo-prepare(INSERT INTO order_queue (order_id, created_at) VALUES (?, ?)) -execute([$orderNo, time()]); return success; }verifySign按支付平台规则实现这里不展开。关键是入队后立刻返回success把结算压力转移给 worker。order_queue表加唯一索引order_id防止同一订单入队多次。4.2 队列消费批量拉取 限速worker 用常驻进程跑每次拉一批待处理订单逐个结算。PHP 常驻进程要注意内存和数据库连接复用别在循环里反复 new PDO。function runWorker(PDO $pdo): void { while (true) { $rows $pdo-query( SELECT order_id FROM order_queue ORDER BY id ASC LIMIT 50 )-fetchAll(PDO::FETCH_COLUMN); if (!$rows) { sleep(2); continue; } foreach ($rows as $orderId) { try { settleOrder($pdo, (int)$orderId); $pdo-prepare(DELETE FROM order_queue WHERE order_id ?)-execute([$orderId]); } catch (Throwable $e) { // 记录失败留待人工排查不阻塞后续订单 error_log(settle fail order{$orderId} msg . $e-getMessage()); $pdo-prepare(UPDATE order_queue SET retry retry 1 WHERE order_id ?) -execute([$orderId]); } } usleep(200000); // 限速避免打满数据库 } }LIMIT 50控制单批大小usleep(200000)是 0.2 秒限速。失败订单不删除累加retry字段超过阈值告警。这套结构在日订单几万的量级下足够稳再大就上 Redis 队列思路一样。提示PHP 常驻进程跑久了会内存泄漏建议每处理 1000 单重启一次 worker用 supervisor 托管最省心。5. 后台查询与对账代理业绩怎么查才不卡运营最常干的事是查某代理本月业绩和某笔订单返了谁。这两个查询如果写不好后台列表页能卡到怀疑人生。这一章给两条优化过的查询和一套对账思路。5.1 代理业绩汇总预聚合表实时SUM佣金表在数据量大后很慢。我的做法是建一张按天预聚合的业绩表定时任务每天凌晨跑一次后台查汇总直接读这张表。CREATE TABLE agent_stat_daily ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, agent_id BIGINT UNSIGNED NOT NULL, stat_date DATE NOT NULL, order_cnt INT UNSIGNED NOT NULL DEFAULT 0, order_amt DECIMAL(12,2) NOT NULL DEFAULT 0.00, commission DECIMAL(12,2) NOT NULL DEFAULT 0.00, PRIMARY KEY (id), UNIQUE KEY uk_agent_date (agent_id, stat_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;聚合 SQL 按订单归属代理分组注意这里统计的是直接归属的订单如果要算整棵子树的业绩用 path 前缀匹配INSERT INTO agent_stat_daily (agent_id, stat_date, order_cnt, order_amt, commission) SELECT o.agent_id, DATE(FROM_UNIXTIME(o.created_at)), COUNT(*), SUM(o.amount), SUM(c.fee) FROM order o LEFT JOIN commission c ON c.order_id o.id AND c.agent_id o.agent_id WHERE o.status 1 AND o.created_at UNIX_TIMESTAMP(CURDATE() - INTERVAL 1 DAY) AND o.created_at UNIX_TIMESTAMP(CURDATE()) GROUP BY o.agent_id, DATE(FROM_UNIXTIME(o.created_at)) ON DUPLICATE KEY UPDATE order_cnt VALUES(order_cnt), order_amt VALUES(order_amt), commission VALUES(commission);ON DUPLICATE KEY UPDATE保证重跑不产生重复行。stat_date用 DATE 类型查询时按日期范围过滤索引友好。5.2 查整棵子树的业绩要查某代理及其所有下级的合计业绩用 path 前缀SELECT SUM(s.order_amt) AS total_amt, SUM(s.commission) AS total_fee FROM agent_stat_daily s JOIN agent a ON a.id s.agent_id WHERE a.path LIKE CONCAT((SELECT path FROM agent WHERE id :id), :id, /%) AND s.stat_date BETWEEN :start AND :end;这条查询走idx_path索引代理几千个、数据几十万行也能秒回。如果还慢把子树代理 ID 列表缓存进 Redis定时刷新查询时直接WHERE agent_id IN (...)。5.3 对账三个必须核对的数对账我只看三个数订单总额、佣金总额、代理余额变动总额。三者关系是佣金总额 代理余额增加总额对不上就是有 bug。写个定时脚本每天跑一次差额超过阈值就告警。退款场景要特别注意订单退款后对应佣金要置为撤销代理余额要扣回这三步必须在一个事务里完成否则对账永远平不了。6. 避坑与排查分销系统上线后最容易翻车的 5 个点这一章全是踩过的坑每条按现象、原因、解决写照着排查能省不少时间。坑一佣金重复发放。现象是同一订单同一代理出现两条佣金记录。原因是支付回调重试时没有幂等保护或者定时任务和回调同时触发结算。解决是给commission表加(order_id, agent_id)唯一索引结算前用FOR UPDATE锁订单行双保险。坑二path 前缀误匹配。现象是查代理 5 的下级把代理 50 的下级也查出来了。原因是 path 格式没加分隔符LIKE 1/5%会匹配到1/50/。解决是 path 统一用1/5/23/前后带斜杠的格式查询用LIKE 1/5/%。坑三浮点算钱出现分位误差。现象是佣金累加后总额和手工算的差几分钱。原因是用了 FLOAT 或 DOUBLE 存金额。解决是所有金额字段用 DECIMALPHP 里计算用round($x, 2)涉及累加的场景考虑用整数分存储。坑四代理换上级后历史订单归属错乱。现象是代理调整了上级之前订单的返佣对象跟着变了。原因是订单表只存了 agent_id没存路径快照。解决是下单时把agent_path一起写进订单结算只认快照不查实时关系树。坑五后台查下级卡死数据库。现象是运营点开某个大代理的下级列表页面转圈几十秒。原因是用了递归查询或者LIKE没走索引。解决是 path 字段建索引查询前缀在 PHP 里拼好再传实在慢就上预聚合表和 Redis 缓存。注意这五个坑里前三个是资损级别的上线前必须写测试用例覆盖后两个是体验问题但拖久了运营会天天找你。7. 一个实用技巧用递归 CTE 做数据校验MySQL 8 支持递归 CTE 后我多了一个校验手段用递归 CTE 重新算一遍代理树和 path 字段比对能揪出历史脏数据。这个技巧在接手别人半成品源码时特别有用。WITH RECURSIVE tree AS ( -- 锚点所有根代理 SELECT id, parent_id, path, level, CAST(id AS CHAR(255)) AS calc_path, 1 AS calc_level FROM agent WHERE parent_id 0 UNION ALL -- 递归逐层往下拼路径 SELECT a.id, a.parent_id, a.path, CONCAT(t.calc_path, /, a.id) AS calc_path, t.calc_level 1 AS calc_level FROM agent a JOIN tree t ON a.parent_id t.id ) SELECT id, path, CONCAT(calc_path, /) AS expect_path, level, calc_level FROM tree WHERE path CONCAT(calc_path, /) OR level calc_level;这条 SQL 会列出所有 path 或 level 和实际树结构对不上的代理。calc_path是递归算出来的真实路径expect_path是它应该有的值。查出来为空说明数据干净有结果就说明历史上有过直接改库或者程序 bug需要修复。参数上没什么可调的注意CAST(id AS CHAR(255))的宽度要够代理 ID 位数多的话调大。递归深度默认受cte_max_recursion_depth限制默认 1000 层分销系统够用。我现在的习惯是每次上线新的分销逻辑前先跑一遍这个校验确认关系树是干净的再动佣金。这个习惯帮我拦下过好几次脏数据导致的返佣异常。做分销系统关系树就是地基地基歪了上面盖什么都是危房。希望帮到你。本文还有配套的精品资源点击获取 PHP代理分销系统实战：无限级关系链建模与佣金结算
简介这份PHP代理分销系统是一套面向中小电商企业、代理分销创业者及PHP开发者的电子商务解决方案重点解决多级代理管理、佣金结算与商城运营问题适合具备一定PHP基础、希望研究电商系统架构或进行二次开发的技术人员。压缩包为rar格式整体约11.5MB上游未提供具体文件数量与类型明细从描述看应包含前后台源码、数据库脚本及接口配置等核心内容。系统前端涵盖注册登录、商品展示、购物车、订单处理与客户服务后端则提供商品管理、代理分销审核与佣金计算、订单发货退款、用户管理及销售数据统计等模块并可能采用MVC架构与MySQL数据库集成支付宝、微信支付及物流接口。目前已有1349人学习下载读者可借此理解代理分销的等级设定与佣金逻辑掌握电商系统的目录组织与二次开发思路同时学习数据加密、防SQL注入与XSS攻击等安全处理要点为自建商城或定制功能提供参考。1. PHP代理分销系统从一套无限级关系链说起很多人第一次接触 PHP代理分销系统脑子里想的是三级返佣、拉人头、自动结算但真正落到代码上第一个卡住你的不是佣金公式而是代理关系怎么存。我见过太多项目代理表里塞一个parent_id就开干上线三个月后运营要查某个代理下面第 7 层的总业绩一条递归 SQL 直接把数据库拖垮。所以这篇笔记不讲分销模式怎么设计得花哨只讲一套能跑、能扛、能查的 PHP代理分销系统该怎么落地代理层级怎么建模、佣金怎么算不重复、订单回调怎么防并发、后台怎么查下级。适合正在用 PHP 做分销、返佣、渠道管理这类系统的后端同学也适合接手别人半成品源码、被无限级查询折磨过的运维。我一般把这类系统拆成四块代理关系树、订单归因、佣金结算、后台查询。四块里任何一块偷懒后面都要还债。下面按我实际做过的顺序从数据建模一路讲到并发和排查中间给的都是能直接抄的 PHP 代码和 SQL参数怎么调、坑在哪都会说清楚。2. 代理关系树怎么建邻接表、路径枚举还是闭包表代理分销系统的地基是关系树。选错存储方式后面每一次查下级都是血泪经验。这一章把三种主流方案摆出来说清各自边界再给一套我常用的混合方案。2.1 三种层级存储方案的取舍邻接表parent_id是最省事的每个代理存一个上级 ID。写入快改上级也快但查所有下级必须递归。MySQL 8 之前没有递归 CTE只能靠 PHP 循环查库层级一深就是 N 次查询代理上千后后台列表直接转圈。路径枚举path给每个代理存一条从根到自己的路径比如1/5/23/。查某代理的所有下级只要WHERE path LIKE 1/5/23/%一条 SQL 搞定索引也能用上。代价是移动代理换上级时要批量改所有子孙的 path写放大明显。闭包表closure table单独建一张关系表存每一对祖先-后代的距离。查询任意层级都是等值 JOIN最灵活但表行数是 O(n²) 级别代理规模上万后维护成本高。我的选择是路径枚举为主parent_id 冗余保留。理由很实际——分销系统里换上级是低频操作而查下级业绩是高频操作用低频的写代价换高频的读性能划算。parent_id 留着是为了单层查询和后台展示方便不用每次解析 path。2.2 建表 SQL 与字段说明CREATE TABLE agent ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, parent_id BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT 直接上级ID0为根, path VARCHAR(255) NOT NULL DEFAULT COMMENT 层级路径形如 1/5/23/, level TINYINT UNSIGNED NOT NULL DEFAULT 1 COMMENT 自身层级根为1, username VARCHAR(64) NOT NULL, rate DECIMAL(5,4) NOT NULL DEFAULT 0.1000 COMMENT 自身佣金比例, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 0冻结, created_at INT UNSIGNED NOT NULL DEFAULT 0, PRIMARY KEY (id), KEY idx_path (path), KEY idx_parent (parent_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;path用1/5/23/这种前后都带斜杠的格式是为了让LIKE 1/5/%不会误匹配到1/50/。level冗余存一份省得每次数斜杠。rate用 DECIMAL 不用 FLOAT佣金算钱千万别用浮点这是踩过的坑。新增代理时path 由上级拼出来function createAgent(PDO $pdo, int $parentId, string $username, float $rate): int { // 先取上级信息根代理 parentId0 时 path 为空 if ($parentId 0) { $stmt $pdo-prepare(SELECT path, level FROM agent WHERE id ? AND status 1); $stmt-execute([$parentId]); $parent $stmt-fetch(PDO::FETCH_ASSOC); if (!$parent) { throw new RuntimeException(上级不存在或已冻结); } $path $parent[path] . $parentId . /; $level $parent[level] 1; } else { $path ; $level 1; } $stmt $pdo-prepare( INSERT INTO agent (parent_id, path, level, username, rate, created_at) VALUES (?,?,?,?,?,?) ); $stmt-execute([$parentId, $path, $level, $username, $rate, time()]); $id (int)$pdo-lastInsertId(); // 根代理自身 path 补上自己的 id保证格式统一 if ($parentId 0) { $pdo-prepare(UPDATE agent SET path ? WHERE id ?)-execute([$id . /, $id]); } return $id; }逻辑上分两步先根据上级算出自己的 path 和 level插入后再给根代理补 path。参数$parentId传 0 表示建根代理$rate是自身佣金比例建议限制在 0 到 1 之间入库前做校验。注意这里没有做并发保护同一上级下并发建代理不会冲突因为 path 只依赖上级不依赖兄弟节点。2.3 查下级一条 SQL 拿到整棵子树有了 path查某代理的所有下级就是SELECT id, username, level, rate FROM agent WHERE path LIKE CONCAT((SELECT path FROM agent WHERE id :id), :id, /%) AND status 1 ORDER BY level ASC, id ASC;这里CONCAT(path, id, /)拼出的是以该代理为前缀的路径。比如代理 5 的 path 是1/那它的下级前缀就是1/5/所有 path 以1/5/开头的都是它的子孙。ORDER BY level让结果按层级排后台展示直接能用。提示LIKE 前缀%能走索引但前缀是动态拼的MySQL 优化器有时会放弃索引。代理量超过 5 万后建议把前缀在 PHP 里算好再传进去别在 SQL 里套子查询。如果要查某代理下面第 N 层加一个level 上级level N条件即可不用递归。这就是路径枚举最爽的地方。3. 订单归因与佣金结算怎么算不重复、不遗漏关系树建好只是开始真正让分销系统翻车的是佣金。用户下单钱该分给谁、分几层、比例怎么叠稍不注意就重复返佣或者漏返。这一章讲归因和结算的完整链路。3.1 订单归因绑定关系与下单快照归因的核心问题是这笔订单算哪个代理的业绩常见做法是用户注册时绑定一个代理user.agent_id下单时把这个 agent_id 写进订单。但这里有个坑——如果用户后来换了绑定代理历史订单的归属会跟着变对账时全是糊涂账。我的做法是下单时打快照订单表里存agent_id和agent_path一旦写入不再改。这样即使代理关系树后来调整历史订单的归属永远稳定。CREATE TABLE order ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, user_id BIGINT UNSIGNED NOT NULL, agent_id BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT 归属代理快照, agent_path VARCHAR(255) NOT NULL DEFAULT COMMENT 下单时代理路径快照, amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已退款, created_at INT UNSIGNED NOT NULL DEFAULT 0, PRIMARY KEY (id), KEY idx_agent (agent_id), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;agent_path存的是下单时该代理的完整路径比如1/5/23/。有了它结算时不用再查 agent 表就能知道要分几层、分给谁。3.2 佣金计算按路径逐层返比例可配置佣金规则我一般做成逐层递减一级代理拿最高比例往上逐层降低到某个层级封顶。比例存在配置表里不写死在代码。function calcCommission(string $agentPath, float $amount, array $rateMap): array { // agentPath 形如 1/5/23/拆出所有祖先ID含自身 $ids array_filter(explode(/, $agentPath), strlen); $ids array_reverse($ids); // 从最近的代理往上算 $result []; $depth 0; foreach ($ids as $agentId) { $depth; if (!isset($rateMap[$depth])) { break; // 超过配置层级停止返佣 } $rate $rateMap[$depth]; $fee round($amount * $rate, 2); if ($fee 0) { continue; } $result[] [agent_id (int)$agentId, depth $depth, rate $rate, fee $fee]; } return $result; }$rateMap形如[1 0.10, 2 0.05, 3 0.02]表示一级返 10%、二级 5%、三级 2%。array_reverse保证从离订单最近的代理开始算depth 从 1 递增。round(..., 2)是必须的金额保留两位小数避免出现0.30000000000000004这种浮点尾巴。注意$rateMap的总和不要超过 1否则会出现返佣总额大于订单金额的资损。上线前一定要加一道校验array_sum($rateMap) 1。3.3 结算落库幂等是底线佣金算出来要写进佣金流水表这一步最大的风险是重复结算。支付回调可能重试定时任务可能重跑没有幂等保护就会重复返佣。CREATE TABLE commission ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, order_id BIGINT UNSIGNED NOT NULL, agent_id BIGINT UNSIGNED NOT NULL, depth TINYINT UNSIGNED NOT NULL, rate DECIMAL(5,4) NOT NULL, fee DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1已入账 0已撤销, created_at INT UNSIGNED NOT NULL DEFAULT 0, PRIMARY KEY (id), UNIQUE KEY uk_order_agent (order_id, agent_id), KEY idx_agent (agent_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;关键在UNIQUE KEY (order_id, agent_id)。同一订单对同一代理只能有一条佣金记录重复插入直接报唯一键冲突用INSERT ... ON DUPLICATE KEY UPDATE或者捕获异常都能实现幂等。function settleOrder(PDO $pdo, int $orderId): void { $pdo-beginTransaction(); try { // 加行锁防止并发重复结算 $stmt $pdo-prepare(SELECT * FROM order WHERE id ? AND status 1 FOR UPDATE); $stmt-execute([$orderId]); $order $stmt-fetch(PDO::FETCH_ASSOC); if (!$order) { $pdo-rollBack(); return; } $rateMap [1 0.10, 2 0.05, 3 0.02]; $list calcCommission($order[agent_path], (float)$order[amount], $rateMap); $ins $pdo-prepare( INSERT INTO commission (order_id, agent_id, depth, rate, fee, created_at) VALUES (?,?,?,?,?,?) ON DUPLICATE KEY UPDATE fee VALUES(fee), rate VALUES(rate) ); foreach ($list as $row) { $ins-execute([$orderId, $row[agent_id], $row[depth], $row[rate], $row[fee], time()]); } $pdo-commit(); } catch (Throwable $e) { $pdo-rollBack(); throw $e; } }FOR UPDATE锁住订单行保证同一订单不会被两个进程同时结算。ON DUPLICATE KEY UPDATE让重跑安全。参数上status 1表示只结算已支付订单退款时把对应佣金status置 0 即可不要物理删除留痕对账。4. 高并发下的订单回调与队列处理分销系统一旦接支付回调就是并发重灾区。用户支付成功支付平台可能连发三次通知你的接口如果每次都跑一遍结算轻则重复返佣重则数据库锁等待拖垮整个站。这一章讲怎么把回调削峰、怎么用队列兜底。4.1 回调接口只做两件事验签和入队我的原则是回调接口越薄越好。验签通过后不直接结算而是把订单号丢进队列立刻返回成功。这样支付平台不会因为你的结算慢而重试。// 回调入口仅验签 入队 function notifyHandler(PDO $pdo, array $post): string { if (!verifySign($post)) { return fail; } $orderNo $post[out_trade_no] ?? ; if ($orderNo ) { return fail; } // 幂等已处理过的回调直接返回成功 $stmt $pdo-prepare(SELECT id FROM order WHERE id ? AND status 1); $stmt-execute([$orderNo]); if ($stmt-fetch()) { return success; } // 入队交给后台 worker 结算 $pdo-prepare(INSERT INTO order_queue (order_id, created_at) VALUES (?, ?)) -execute([$orderNo, time()]); return success; }verifySign按支付平台规则实现这里不展开。关键是入队后立刻返回success把结算压力转移给 worker。order_queue表加唯一索引order_id防止同一订单入队多次。4.2 队列消费批量拉取 限速worker 用常驻进程跑每次拉一批待处理订单逐个结算。PHP 常驻进程要注意内存和数据库连接复用别在循环里反复 new PDO。function runWorker(PDO $pdo): void { while (true) { $rows $pdo-query( SELECT order_id FROM order_queue ORDER BY id ASC LIMIT 50 )-fetchAll(PDO::FETCH_COLUMN); if (!$rows) { sleep(2); continue; } foreach ($rows as $orderId) { try { settleOrder($pdo, (int)$orderId); $pdo-prepare(DELETE FROM order_queue WHERE order_id ?)-execute([$orderId]); } catch (Throwable $e) { // 记录失败留待人工排查不阻塞后续订单 error_log(settle fail order{$orderId} msg . $e-getMessage()); $pdo-prepare(UPDATE order_queue SET retry retry 1 WHERE order_id ?) -execute([$orderId]); } } usleep(200000); // 限速避免打满数据库 } }LIMIT 50控制单批大小usleep(200000)是 0.2 秒限速。失败订单不删除累加retry字段超过阈值告警。这套结构在日订单几万的量级下足够稳再大就上 Redis 队列思路一样。提示PHP 常驻进程跑久了会内存泄漏建议每处理 1000 单重启一次 worker用 supervisor 托管最省心。5. 后台查询与对账代理业绩怎么查才不卡运营最常干的事是查某代理本月业绩和某笔订单返了谁。这两个查询如果写不好后台列表页能卡到怀疑人生。这一章给两条优化过的查询和一套对账思路。5.1 代理业绩汇总预聚合表实时SUM佣金表在数据量大后很慢。我的做法是建一张按天预聚合的业绩表定时任务每天凌晨跑一次后台查汇总直接读这张表。CREATE TABLE agent_stat_daily ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, agent_id BIGINT UNSIGNED NOT NULL, stat_date DATE NOT NULL, order_cnt INT UNSIGNED NOT NULL DEFAULT 0, order_amt DECIMAL(12,2) NOT NULL DEFAULT 0.00, commission DECIMAL(12,2) NOT NULL DEFAULT 0.00, PRIMARY KEY (id), UNIQUE KEY uk_agent_date (agent_id, stat_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;聚合 SQL 按订单归属代理分组注意这里统计的是直接归属的订单如果要算整棵子树的业绩用 path 前缀匹配INSERT INTO agent_stat_daily (agent_id, stat_date, order_cnt, order_amt, commission) SELECT o.agent_id, DATE(FROM_UNIXTIME(o.created_at)), COUNT(*), SUM(o.amount), SUM(c.fee) FROM order o LEFT JOIN commission c ON c.order_id o.id AND c.agent_id o.agent_id WHERE o.status 1 AND o.created_at UNIX_TIMESTAMP(CURDATE() - INTERVAL 1 DAY) AND o.created_at UNIX_TIMESTAMP(CURDATE()) GROUP BY o.agent_id, DATE(FROM_UNIXTIME(o.created_at)) ON DUPLICATE KEY UPDATE order_cnt VALUES(order_cnt), order_amt VALUES(order_amt), commission VALUES(commission);ON DUPLICATE KEY UPDATE保证重跑不产生重复行。stat_date用 DATE 类型查询时按日期范围过滤索引友好。5.2 查整棵子树的业绩要查某代理及其所有下级的合计业绩用 path 前缀SELECT SUM(s.order_amt) AS total_amt, SUM(s.commission) AS total_fee FROM agent_stat_daily s JOIN agent a ON a.id s.agent_id WHERE a.path LIKE CONCAT((SELECT path FROM agent WHERE id :id), :id, /%) AND s.stat_date BETWEEN :start AND :end;这条查询走idx_path索引代理几千个、数据几十万行也能秒回。如果还慢把子树代理 ID 列表缓存进 Redis定时刷新查询时直接WHERE agent_id IN (...)。5.3 对账三个必须核对的数对账我只看三个数订单总额、佣金总额、代理余额变动总额。三者关系是佣金总额 代理余额增加总额对不上就是有 bug。写个定时脚本每天跑一次差额超过阈值就告警。退款场景要特别注意订单退款后对应佣金要置为撤销代理余额要扣回这三步必须在一个事务里完成否则对账永远平不了。6. 避坑与排查分销系统上线后最容易翻车的 5 个点这一章全是踩过的坑每条按现象、原因、解决写照着排查能省不少时间。坑一佣金重复发放。现象是同一订单同一代理出现两条佣金记录。原因是支付回调重试时没有幂等保护或者定时任务和回调同时触发结算。解决是给commission表加(order_id, agent_id)唯一索引结算前用FOR UPDATE锁订单行双保险。坑二path 前缀误匹配。现象是查代理 5 的下级把代理 50 的下级也查出来了。原因是 path 格式没加分隔符LIKE 1/5%会匹配到1/50/。解决是 path 统一用1/5/23/前后带斜杠的格式查询用LIKE 1/5/%。坑三浮点算钱出现分位误差。现象是佣金累加后总额和手工算的差几分钱。原因是用了 FLOAT 或 DOUBLE 存金额。解决是所有金额字段用 DECIMALPHP 里计算用round($x, 2)涉及累加的场景考虑用整数分存储。坑四代理换上级后历史订单归属错乱。现象是代理调整了上级之前订单的返佣对象跟着变了。原因是订单表只存了 agent_id没存路径快照。解决是下单时把agent_path一起写进订单结算只认快照不查实时关系树。坑五后台查下级卡死数据库。现象是运营点开某个大代理的下级列表页面转圈几十秒。原因是用了递归查询或者LIKE没走索引。解决是 path 字段建索引查询前缀在 PHP 里拼好再传实在慢就上预聚合表和 Redis 缓存。注意这五个坑里前三个是资损级别的上线前必须写测试用例覆盖后两个是体验问题但拖久了运营会天天找你。7. 一个实用技巧用递归 CTE 做数据校验MySQL 8 支持递归 CTE 后我多了一个校验手段用递归 CTE 重新算一遍代理树和 path 字段比对能揪出历史脏数据。这个技巧在接手别人半成品源码时特别有用。WITH RECURSIVE tree AS ( -- 锚点所有根代理 SELECT id, parent_id, path, level, CAST(id AS CHAR(255)) AS calc_path, 1 AS calc_level FROM agent WHERE parent_id 0 UNION ALL -- 递归逐层往下拼路径 SELECT a.id, a.parent_id, a.path, CONCAT(t.calc_path, /, a.id) AS calc_path, t.calc_level 1 AS calc_level FROM agent a JOIN tree t ON a.parent_id t.id ) SELECT id, path, CONCAT(calc_path, /) AS expect_path, level, calc_level FROM tree WHERE path CONCAT(calc_path, /) OR level calc_level;这条 SQL 会列出所有 path 或 level 和实际树结构对不上的代理。calc_path是递归算出来的真实路径expect_path是它应该有的值。查出来为空说明数据干净有结果就说明历史上有过直接改库或者程序 bug需要修复。参数上没什么可调的注意CAST(id AS CHAR(255))的宽度要够代理 ID 位数多的话调大。递归深度默认受cte_max_recursion_depth限制默认 1000 层分销系统够用。我现在的习惯是每次上线新的分销逻辑前先跑一遍这个校验确认关系树是干净的再动佣金。这个习惯帮我拦下过好几次脏数据导致的返佣异常。做分销系统关系树就是地基地基歪了上面盖什么都是危房。希望帮到你。本文还有配套的精品资源点击获取