CRMEB Pro 二开避坑：删除一个分销身份，为什么会牵动整条团队链路？

CRMEB Pro 二开避坑删除一个分销身份为什么会牵动整条团队链路做商城系统二开时很多人会低估“删除”这个动作。比如在 CRMEB Pro 的团队分销里后台只是删一个团长、代理商或员工身份表面看是一个按钮实际会同时影响团队归属、直推关系、佣金统计、历史订单快照、新旧关系表同步甚至移动端团队页的展示口径。这篇不讲空泛架构直接聊一个更容易出事故的场景团队分销身份删除时为什么要区分“换绑、保留关系、解绑”。一、为什么团队身份不能直接删团队分销里一个用户可能不只是“一个用户”还可能承担三种层级身份团长 division 代理商 agent 员工 staff对应到用户关系上常见字段会包含division_type 当前团队身份团长/代理商/员工/普通用户 division_id 所属团长 agent_id 所属代理商 staff_id 所属员工 spread_uid 当前直推上级 brokerage_price 未提现佣金余额如果只是把division_type改成 0看起来身份没了但下级用户还可能挂在它下面订单快照里还可能记录它新版团队关系表里还可能认为它是有效成员。结果就是后台列表、移动端团队页、佣金统计、订单分佣口径可能同时出现不一致。所以团队身份删除不是“删一行”而是“处理一条链”。二、删除前先做确认弹窗而不是直接提交项目里后台删除团队身份时不是直接调用删除接口而是先取确认信息GET /adminapi/agent/division/delete/info/:uid确认信息至少要告诉运营人员几件事当前删除的是团长、代理商还是员工。这个身份下面还有多少受影响用户。是否存在未提现佣金。允许选择哪些处理方式。如果选择换绑有哪些合法目标。控制器入口可以保持很轻/** * 删除团队身份确认信息 * param $uid * return hinkResponse */publicfunctiongetDeleteDivisionInfo($uid){return$this-success($this-services-getDeleteDivisionInfo((int)$uid));}真正的判断放在 Services身份是否合法、目标是否同层级、是否需要佣金确认都应该在业务层收口。三、三种处理方式含义完全不同删除团队身份时最容易混淆的是这三个词transfer 换绑 keep 保留关系也可以理解为解除当前直接关系 unbind 解绑清空团队链路这三个动作的破坏范围完全不同。1. 换绑 transfer换绑适合“身份被删除但团队关系要延续”的场景。比如删除一个代理商把它下面的员工和买家迁到同团队的另一个代理商下面原代理商 A - 目标代理商 B 原 agent_id A 的用户改为 agent_id B 原直推 A 的用户改为 spread_uid B换绑的重点是“下级不丢只是换上级”。这类动作必须校验目标是否有效比如团长换绑只能换到另一个有效团长。代理商换绑只能换到同团队的有效代理商。员工换绑只能换到同代理商下的有效员工。否则很容易把用户迁到错误层级后面统计就会变形。2. 保留关系 keep保留关系适合“删除中间身份但尽量保留上层团队归属”的场景。比如删除代理商时保留 division_id 团队归属 清空 agent_id / staff_id 清空原来直推该代理商的 spread_uid也就是说用户还留在团长团队里但不再挂这个代理商/员工链路。注意团长一般不支持 keep。因为团长本身就是团队根节点根节点没了就谈不上“保留团队归属”。3. 解绑 unbind解绑是破坏范围最大的处理方式。它表示删除这个身份并清空相关团队链路。比如删除团长并选择解绑所有 division_id 原团长 的用户清空团队链路 原直推该团长的用户 spread_uid 清空 新版团队关系表同步失效这类动作一定要慎用尤其是线上库。它不应该影响历史订单和历史佣金流水但会影响后续团队归属和统计展示。四、提交删除接口应该接收哪些参数提交删除可以设计为一个明确的接口POST /adminapi/agent/division/delete/save核心参数uid 被删除身份用户 UID handle_type transfer / keep / unbind target_uid 换绑目标仅 transfer 必填 confirm_brokerage 有未提现佣金时的二次确认控制器仍然只负责收参和调用/** * 删除团队身份提交 * return hinkResponse */publicfunctiondeleteDivisionSave(){$data$this-request-postMore([[uid,0],[handle_type,unbind],[target_uid,0],[confirm_brokerage,0],]);$this-services-deleteDivision((int)$data[uid],(string)$data[handle_type],(int)$data[target_uid],(int)$data[confirm_brokerage]);return$this-success(删除成功);}这里不要在 Controller 里写复杂分支。因为删除身份会牵涉用户、团队成员、关系表、日志、订单快照等多个模块必须放到 Services 事务里统一编排。五、删除动作为什么要包事务团队身份删除至少会做这些事清空被删用户的团队身份字段。按处理方式调整下级用户的division_id / agent_id / staff_id / spread_uid。同步新版团队关系表。失效团队成员身份记录。写入绑定/解绑日志。保留历史订单和历史佣金流水。任何一步失败都可能造成新旧数据不一致。所以这类逻辑必须走事务。伪代码可以这样理解return$this-transaction(function()use($uid,$handleType,$targetUid){// 1. 校验身份、目标、佣金确认// 2. 根据 transfer / keep / unbind 处理下级链路// 3. 清空被删用户团队身份// 4. 同步关系表与成员表// 5. 写日志returntrue;});不要把这种逻辑拆成多个无事务接口让前端依次调用。前端点到一半失败后端就可能留下半成品关系链。六、新旧关系表要保持一致CRMEB Pro 团队分销二开时常见兼容问题是老字段在用户表新关系在团队关系表。老字段更直观eb_user.division_id eb_user.agent_id eb_user.staff_id eb_user.spread_uid新关系表更适合统计和快照eb_division_member eb_division_user_relation eb_division_bind_log所以删除、换绑、解绑后不能只改eb_user。还要同步新版关系表让团队成员状态、用户归属、绑定日志都能对上。典型同步动作包括// 用户旧字段变化后同步团队归属关系app()-make(DivisionRelationServices::class)-syncUserRelation($uid);// 身份被删除后失效团队成员记录app()-make(DivisionRelationServices::class)-disableMember($uid,$roleType);这样移动端团队页、后台统计、订单快照迁移才不会各看各的。七、历史订单和佣金流水不能乱动这是团队分销二开里的红线。删除身份时要处理的是“未来关系”和“当前归属”不是删除历史。历史订单上的团队快照、历史佣金流水、已返佣和冻结中的记录一般都应该保留。否则运营会遇到两个很难解释的问题为什么以前的订单查不到原来的归属了为什么用户佣金流水突然少了正确做法是当前用户关系按选择方式调整。历史订单快照保留原事实。佣金流水不删除、不清空。未提现佣金需要二次确认但不是直接抹掉。这个边界一定要写进接口说明和测试用例里。八、测试时不要只看接口返回成功这种接口返回“删除成功”不代表真的安全。至少要核对这些点1. 被删用户 division_type 是否清空 2. 被删用户 division_id / agent_id / staff_id 是否清空 3. 下级用户是否按 transfer / keep / unbind 正确变化 4. spread_uid 是否同步调整 5. eb_division_member 是否失效旧身份 6. eb_division_user_relation 是否与旧字段一致 7. eb_division_bind_log 是否有 bind / transfer / unbind 日志 8. 历史订单快照是否保留 9. 历史佣金流水是否保留 10. 后台列表和移动端团队页口径是否一致尤其是换绑和解绑不要拿线上库随便点。测试前做数据库快照用例之间恢复基线才能避免前一个用例污染后一个用例。九、二开建议把“危险动作”显性化团队分销这类模块二开时建议把危险动作设计得更显性删除前必须展示影响人数。有未提现佣金时必须二次确认。换绑目标必须由后端过滤不让前端随便传 UID。不支持的处理方式要在后端拦截比如团长不支持 keep。所有关系变更都写日志方便后续追溯。高风险操作不要绕过后台权限和操作日志中间件。一句话越危险的接口越不能相信“前端不会乱传”。总结CRMEB Pro 团队分销二开里删除身份不是一个 CRUD 删除而是一次关系链重排。真正要想清楚的是换绑下级继续跟人走 保留关系上层团队保留中间关系断开 解绑当前团队链路整体清空只要这三个概念分清楚再配合事务、新旧关系同步、历史订单快照保护和完整测试用例团队分销的二开风险会低很多。