ThinkPHP如何实现分销裂变_邀请关系树与佣金结算【详解】

先拆开看：ThinkPHP搞分销裂变，绕不开两个核心——关系树要稳，用金算得准。推荐用path字段或user_ancestor冗余表存关系，邀请码校验防作弊，用金结算服务化+幂等化，退款时必须反向扣佣。

在ThinkPHP里做分销裂变，归根到底就是两个命门：关系树要建得稳，用金要算得准。关系链不能靠临时递归查，用金逻辑不能散在控制器里——否则订单一多就卡，规则一改就崩，一退单就资损。

邀请关系怎么存才靠谱

别只用 parent_id 字段硬连。查下级要N+1，算三级用金得连查3次，高并发下数据库直呼吃不消。

• 建议加 path 字段（如 "0-100-205-318"），注册时由上级path拼接生成，开头固定为0
• path 字段设为 VARCHAR(255)，支持至少5级以上深度
• 或更进一步，建 user_ancestor 冗余表：每条记录存 user_id、ancestor_id、level（1=直推，2=间推…），用户注册/换上级时一次性补全所有祖先路径
• 两者都建议加索引：KEY idx_path (path) 或 KEY idx_anc (ancestor_id, level)

邀请码与裂变追踪怎么做

邀请码可不是随便生成的，它是裂变链路的唯一入口。

• 每个用户生成8到10位唯一邀请码（字母数字组合），存在users表或独立的invite_codes表
• 新用户注册时提交邀请码，后端校验有效性，并写入 inviter_id 和 invite_time
• 防作弊必须做：同一设备ID / IP / 手机号24小时内最多记3次有效邀请
• 奖励触发点要明确：注册、首单支付、复购完成等行为，通过事件（如 UserRegistered、OrderPaid）驱动奖励发放

用金结算必须服务化 + 幂等化

用金不是“订单完成就发钱”，而是“按规则、按状态、按幂等标识精准落账”。

• 抽离 CommissionService 类，封装所有计算逻辑；控制器只负责触发事件（如 event('OrderPaid', $order)）
• 用金比例走配置：存在 commission_levels 表或配置文件，字段含 level、rate、min_amount，可选 category_id 或 user_tier
• 结算前生成唯一 settlement_id（如 order_88923_settle_v1），查 commission_log 表确认未处理再执行
• 关键操作进事务：SELECT ... FOR UPDATE 锁住当前用户及其上级几条记录，避免并发重复结算
• 退款必须反向扣佣：同样走 CommissionService，传入负金额 + 原 settlement_id，保证账务可追溯、可对冲

查下级、算层级、分组展示

前端常要“显示我下面一级、二级、三级分别有谁”，别用with关联或PHP层循环explode。

• 用path查询全部下级：User::where('path', 'like', $user->path . '-%')->select()
• MySQL内算层级差：LENGTH(path) - LENGTH(REPLACE(path, '-', '')) - LENGTH('$userPath') + LENGTH(REPLACE('$userPath', '-', ''))，结果即为相对级数
• 更省事：在users表加 level 字段（相对于平台根节点），业务层维护；查某人第N级下线直接 WHERE level = {$userLevel + $n}
• 高频查询场景，建议把level单独建字段并加索引，避免每次字符串计算