一个客户想做二级分销加自购返佣商城，系统逻辑层面需要考虑哪些？

老板说客户想开发一个二级分销加自购返佣商城，简单版的我们已经有现成的了，但如果要做得比较完善，整体需要考虑的东西比较多，我们就从逻辑层面上来考虑。

二级分销与自购返佣的叠加会产生复杂的关系链条和资金流向。要做到逻辑全覆盖，我们需要从关系绑定、分销资格、佣金计算、状态流转四个维度进行极致细分。

一、 关系绑定逻辑

绑定逻辑决定了佣金的归属权，确定谁是谁的上级。

• 1. 绑定触发时机：
  • 扫码/点击即绑定： 只要点开链接就建立临时或永久关系。
  • 注册绑定： 必须通过链接完成新账号注册才绑定。
  • 首单绑定： 注册后未绑定，直到第一次下单前扫了谁的码，就归属于谁。
• 2. 关系冲突处理：
  • 先入为主： 一旦绑定，终身不变，除非后台手动修改。
  • 末位优先： 每次下单前扫谁的码，这一单的佣金就归谁。
  • 保护期制： 绑定后 30 天内归 A，过期后若扫了 B 的码则转给 B。
• 3. 关系合法性校验：
  • 禁止自我环路： A 不能成为自己的上级（除了自购返佣逻辑外）。
  • 禁止反向绑定： A 是 B 的上级，B 不能通过某种操作变成 A 的上级。

二、 身份与资格逻辑

并不是所有人都能拿佣金，需要分情况讨论，确定谁能拿钱。

• 1. 自购返佣资格：
  • 所有用户均有。
  • 仅限“分销商”等级用户（普通消费者自购不返钱）。
• 2. 拿佣金的身份状态：
  • 正常态： 可正常接收佣金。
  • 冻结态： 因违规被冻结，下级产生的佣金逻辑：
    • 可能性 A： 佣金直接消失（平台留存）。
    • 可能性 B： 佣金向上越级跳过（给到更高级别的上级）。
  • 过期态： 长期未登录或未完成续费，资格失效。
• 3. 门槛达成逻辑：
  • 等级差速： 一级上级是普通分销商，二级上级是高级合伙人，返佣比例是否需要动态调整？

三、 佣金计算逻辑

计算佣金的数量，确定可以拿多少钱。

• 1. 计算模型：
  • 固定比例： 实付金额的比例（如 5%）。
  • 阶梯比例： 当月累计业绩越多，返佣比例越高。
  • 固定金额： 无论商品多少钱，卖出一件固定给 多少 元。
  • 利润分润： （实付金额 – 成本）X %。
• 2. 叠加与排他：
  • 自购与分销叠加： A 买了商品，A 拿自购返佣，A 的上级 B 拿一级佣金，B 的上级 C 拿二级佣金。
  • 自购与分销互斥： A 买了商品，A 拿了自购返佣，B 还能拿一级佣金吗？（通常建议叠加，否则分销商没有动力自购）。
• 3. 特殊商品逻辑：
  • 引流款： 不参与分销返佣。
  • 分销专用款： 高额返佣，但不支持自购返佣。

四、 订单状态与资金流转逻辑

这是最容易出 Bug 的地方，必须考虑异常流转，钱什么时候给。

• 1. 佣金生命周期：
  • 待结算： 用户下单未付款。
  • 已预估： 已付款，等待收货。
  • 已结算： 确认收货且过维权期，佣金进入可提现余额。
  • 已失效： 用户退款、订单取消或触发风控。
• 2. 退款逻辑的深度细分：
  • 全额退款： 回滚所有关联佣金（自购、一级、二级）。
  • 部分退款：
    • 比例扣除： 退多少比例的货款，扣多少比例的佣金。
    • 优先扣除： 只要发生退款，佣金直接清零。
  • 结算后退款： 佣金已提现，用户又找后台退款。
    • 逻辑： 下一笔佣金扣除，或余额变为负数。
• 3. 结算触发条件：
  • 主动触发： 用户点击“确认收货”。
  • 自动触发： 系统 7 天或 14 天自动确认。
  • 延迟触发： 确认收货后再过 $N$ 天（防止职业退款党）。

五、 极端边界情况逻辑（所有意外可能）

• 1. 孤儿单逻辑： 某用户没有上级，他产生的“一级”和“二级”佣金去哪了？（通常进入系统公共账户）。
• 2. 越级逻辑： 如果开启了等级制，下级等级超过上级，佣金是否“烧伤”（即上级拿不到或只能拿很少）？
• 3. 提现上限： 每日/每月提现最高额度，以及单笔提现最小额度。
• 4. 组织架构变动： 如果后台把 A 的上级从 B 改成了 D，那么 A 之前未结算的订单佣金归谁？（建议以订单产生时的快照关系为准）。

逻辑清单表：

上级可以修改的情况

这不仅涉及简单的数据库字段修改，还会引发利益链条的断裂、佣金归属冲突以及财务对账等一系列连锁反应。

一、 修改后的“佣金归属”追溯逻辑

这是最核心的矛盾点：旧订单归谁，新订单归谁？

• 1. 历史订单快照（推荐）：
  • 逻辑： 订单在生成的瞬间，就“快照”记录了当时的一级、二级上级是谁。
  • 结果： 即使修改了上级，修改前的旧订单产生的佣金依然发放给旧上级。这保证了财务的连贯性和旧上级的既得利益。
• 2. 实时跟随逻辑：
  • 逻辑： 佣金结算时才去查询当前最新的上级。
  • 结果： 修改上级后，所有未结算（待定）的佣金会瞬间转移到新上级手中。
  • 风险： 容易导致旧上级投诉，且如果新旧上级佣金比例不同，会导致系统计算溢出。
• 3. 结算截断逻辑：
  • 修改动作发生的瞬间，将所有“待结算”订单强制结算或标记归属。

二、 关系链的“整体平移”与“断裂”

当修改用户 A 的上级时，A 下面的“团队”怎么处理？

• 1. 带着团队走（整体平移）：
  • A 换了上级，A 发展的所有下线（B、C、D…）依然跟着 A。
  • 影响： 这会导致 A 的旧上级损失一整条线的收益，通常需要高级管理员权限操作。
• 2. 净身出户（链条断裂）：
  • 仅 A 换了上级，A 之前的下线与 A 断开，留在旧组织架构中。
  • 影响： 破坏了分销商的利益，容易造成团队动荡，技术实现上也需要大规模重写关系表。

三、 权限与触发机制

谁有权改？怎么改？

• 1. 后台管理员手动修改： 最常见的做法，用于处理纠纷或运营调整。
• 2. 用户自主申请修改：
  • 条件限制： 比如注册 24 小时内允许修改一次；或者当前没有待结算订单时允许修改。
  • 审核机制： 用户修改需经过原上级同意，或经过后台审核。
• 3. 系统自动覆盖（二次扫码）：
  • 如果允许用户通过扫新人的码来更换上级，必须设置冷却期（如 30 天内禁止更换）或硬性门槛（如已下单用户禁止更换）。

四、 财务与风控逻辑

防止利用“修改上级”进行洗钱或薅羊毛。

• 1. 佣金预扣处理：
  • 修改时，系统必须自动冻结该用户关联的所有“预估佣金”。
  • 逻辑：IF (修改上级 == TRUE) { 重新计算待结算订单的佣金流向 }。
• 2. 等级平级处理：
  • 如果新上级的等级比原上级低，是否会导致 A 的返佣比例超过新上级的总拨比？（防止产生负利润）。
• 3. 操作日志存证：
  • 必须记录：修改时间、操作人、原上级 ID、新上级 ID、修改原因。这是解决后期佣金纠纷的唯一证据。

五、 极端情况的可能性清单

• 循环绑定风险： A 想改到 B 名下，而 B 恰好是 A 的孙子辈。系统必须递归检查，禁止修改后形成闭环。
• 分销商等级冲突： A 原本在旧体系里是“高级分销商”，换到新体系后，新上级可能只是个“普通分销商”，这种“下级比上级强”的情况是否允许？
• 正在提现中的订单： 如果用户正在提现，此时修改上级，需确保财务流向不会发生错乱。

逻辑建议方案：