用user_ancestor表固化多级关系链，字段含user_id、ancestor_id、level；佣金规则存commission_rule表，按匹配精度JOIN计算；结算用settlement_id幂等控制，退款需反向扣佣。
怎么存下多级关系链（不是用递归查数据库）
关系链不能靠每次查 SELECT * FROM users WHERE parent_id = ? 一层层往上翻，MySQL 深度递归查 10 级就卡住，PHP 层递归还容易超时或爆栈。真实项目里得把“谁是谁的第几级上级”这个信息固化下来。
- 用一张
user_ancestor表，字段至少包含：user_id、ancestor_id、level（比如 level=1 表示直推，level=2 是推上一级的人） - 用户注册或变更上级时，一次性写入所有祖先路径：先查出上级的全部祖先，再拼上自己 → 插入新记录
- 查询某人下面 3 级分销成员？直接
SELECT u.* FROM users u JOIN user_ancestor a ON u.id = a.user_id WHERE a.ancestor_id = ? AND a.level
常见错误是只存直推关系，后面算佣金时临时找上级，结果订单量一上来，DB CPU 直接冲到 90%。
佣金怎么按级数动态算（别硬编码 if-else）
佣金比例往往不是固定值：一级 10%，二级 5%，三级 2%，还可能按商品类目、用户等级浮动。硬写 if ($level === 1) { $rate = 0.1; } elseif ($level === 2) { ... } 后期改规则就得改代码、发版、测全链路。
- 把规则存在配置表
commission_rule：字段含level、min_amount、rate、category_id、user_tier（允许 NULL 表示通用） - 计算时用 SQL JOIN 查匹配规则，优先级按字段非空数量倒序（例如同时匹配 category_id + user_tier 的比只匹配 level 的更精确）
- PHP 层只做数据组装和落库，不参与比例计算逻辑
注意：浮点数存 rate 用 DECIMAL(5,4)，别用 FLOAT，否则 0.1 + 0.2 ≠ 0.3，分账对不上。
订单结算时怎么避免重复计算或漏算
用户 A → B → C → D，D 下单，A/B/C 都该拿佣金。但并发下单、补偿任务重试、事务没包住，很容易同一笔订单被算两遍，或者某级被跳过。
- 关键动作必须加唯一标识：每笔订单生成一个
settlement_id（如order_123456_settle_v1），用于幂等判断 - 佣金计算前先查
commission_log表是否存在相同settlement_id+user_id+level记录 - 整个结算流程放在事务里，但不要锁整张 user_ancestor 表；用
SELECT ... FOR UPDATE锁住涉及的几条祖先记录即可
最容易被忽略的是「退款后反向扣佣」：如果只记正向佣金，退单时没走同样幂等路径，就会出现“佣金发了不收回”的资损。
为什么不能用 Laravel 的 Eloquent 关系自动加载做分销链
with('parent.parent.parent') 看起来省事，但实际会触发 N+1 查询，且无法控制深度——你想查 5 级，它可能只加载了 3 级就停了；想限制 level 字段，Eloquent 关系定义里又没法传参。
- Eloquent 的
hasManyThrough只适合固定层级，不适用“最多支持 10 级但实际只有 3 级有数据”的场景 - 更严重的是内存问题：一个用户有 200 个下级，每个下级又带 3 层 parent，PHP 数组瞬间吃掉 100MB+
- 真实系统里，关系链查询和佣金计算必须拆成独立 SQL，用索引覆盖（
KEY idx_anc_aid_lvl (ancestor_id, level)），而不是依赖 ORM 的懒加载
复杂点在于：链路不是静态树，用户可以换上级、团队合并、冻结节点——这些操作都要同步刷新 user_ancestor 表，漏一步，后续所有佣金都错。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
