ThinkPHP分销商城需构建独立user_distribution关系表存储层级，佣金实行“冻结→确认→发放”三阶段管理，微信分账与佣金发放须解耦，推荐码应通过hash_hmac生成并Redis缓存校验，确保财务规则、状态机与接口调用严格对齐。
ThinkPHP分销商城不是“套模板就能跑”的功能模块，它本质是业务逻辑嵌入数据关系的系统工程。直接照搬开源案例容易在三级佣金结算、推荐关系追溯、分账触发时机上翻车。
ThinkPHP里怎么存分销层级关系
别往user表加parent_id字段做递归查询——用户量一过万，查“我的上级的上级”就会拖垮数据库。正确做法是单独建一张关系表，比如user_distribution：
-
id：自增主键 -
user_id：当前用户ID -
ancestor_id：祖先用户ID（比如一级推荐人） -
level：层级（1/2/3） -
path：用逗号拼接的完整路径，如"1001,1002,1005"，便于快速判断是否属于同一链条
这样查三级下线只要SELECT * FROM user_distribution WHERE ancestor_id = ? AND level IN (1,2,3)，不用JOIN或递归，MySQL能走索引。
三级分销佣金怎么算才不漏单
佣金不能只靠订单完成事件触发一次写死，必须拆成“冻结→确认→发放”三阶段：
立即学习“PHP免费学习笔记（深入）”；
- 订单状态变更为
order_completed时，先写入commission_log表，status设为pending，金额按配置的rates数组计算（如[0.5, 0.3, 0.2]） - 设置定时任务（如每小时跑一次），扫描
pending且超过settlement_days（比如7天）的记录，核对对应订单是否已过售后期，再批量更新为confirmed - 提现申请时，只允许从
confirmed状态的佣金中扣减，避免“订单被拒收后佣金已发”的资金风险
漏单常发生在售后期内订单状态反复变更，所以commission_log里必须存原始订单号、商品ID、结算时间戳，不能只记金额。
微信分账和分销佣金怎么协同
微信原生分账接口（profitsharing）和分销佣金是两套逻辑，强行耦合会出问题：
- 微信分账只能分给已实名认证的商户号，但分销用户大多是个人，无法直接受分账；必须走“平台代付”模式：佣金先入平台账户，再调用微信
transfers（企业付款到零钱）打给个人 - 分账请求必须在支付成功后24小时内发起，而分销佣金要等售后期结束，所以不能把
profitsharing当佣金发放动作 - 务必在
wechat_shop.php配置里区分开关：'profit_sharing'=>false用于纯分销场景，true仅用于店铺间分润（如门店+总部）
常见错误是把profit_sharing当成通用分佣开关，结果个人用户收不到钱，还触发微信风控拦截。
分销推荐码生成和校验的关键点
推荐码不是简单取user_id转base62——容易被遍历撞库，也难控制长度和可读性：
- 生成用
hash_hmac('sha256', $user_id . $salt, config('app.key'))截取前6位，加字母前缀（如"U8A3K9"），保证唯一且不可逆 - 校验时不在登录流程里实时查库，而是把推荐关系缓存在
Redis，key为referral:code:U8A3K9，value为user_id，过期时间设为30分钟 - 用户注册成功后，再异步写入
user_distribution并清空Redis缓存，避免高并发下重复写入
忽略缓存一致性，会在活动高峰期出现“两人同时用同一推荐码，只有一人被计入下线”的情况。
分销最麻烦的从来不是代码怎么写，而是“谁在什么时候、依据什么条件、拿到多少钱”的规则必须和财务口径完全对齐。数据库字段设计、状态机流转、第三方接口调用顺序，三者差一点，钱就对不上。
