简介这是一套面向家政服务行业从业者与小程序开发者的柚子家政 wnjz_sun 6.2.6 完整版源码附带分销插件适合需要快速搭建或二次开发家政预约平台的技术人员参考使用。资源包共1196个文件以249个php后端逻辑、207个html页面、198个png与211个gif图片素材、106个js脚本为主另含62个wxss与61个wxml小程序页面文件、66个json配置及sql建表脚本等压缩包约9.88MB目录结构完整前后端与小程序端资源齐备。功能上涵盖后台菜单重新归类、技师分佣支持全局与独立设置、按比例或固定金额核算、技师提现绑定微信号并支持微信、支付宝、银行卡及提现明细、订单新增服务中状态以及技师后台的累计佣金、可提现佣金、累计与今日订单总额等统计数据。目前已有920人学习下载适合希望研究家政小程序分销与佣金结算逻辑的开发者对照参考。1. 家政小程序 6.2.6 版本里分销插件到底解决了谁的燃眉之急家政行业做线上化最头疼的从来不是“有没有小程序”而是“订单来了谁去接、接完怎么分钱”。柚子家政 wnjz_sun 6.2.6 这个版本号背后核心变化就一件事把分销插件揉进了完整版小程序里。这意味着一个做保洁、月嫂、家电清洗的小团队不用再单独买一套分销系统也不用让技术去对接第三方分佣接口开箱就能让老客户带新客户、让阿姨带阿姨按单结算佣金。我见过太多家政老板在这件事上翻车前期用表单收集订单后期用 Excel 算提成订单一多谁是谁推荐的、该拿几个点全成了糊涂账。分销插件要解决的就是这个——把“推荐关系”和“订单金额”在数据库里绑死让每一笔佣金都有据可查。这篇文章适合两类人一是手里已经有一套家政小程序、想加分销但不知道从哪下手的开发者二是准备选型、想搞清楚 6.2.6 这个版本在分销上到底能做到什么程度的运营负责人。下面我按“先讲清逻辑、再动手配置、最后说坑”的顺序把这条链路拆开。2. 分销插件的分佣逻辑与数据库落点先搞懂钱是怎么算的2.1 三级分销在家政场景里为什么通常只用到两级家政服务的利润薄一单保洁可能就一百多块如果真按三级分销去分第一级拿 10%、第二级拿 5%、第三级拿 2%加起来 17% 直接从毛利里切走老板基本白干。所以柚子家政这套分销插件虽然底层支持多级但实际落地时我一般建议只开两级直接推荐人拿大头间接推荐人拿小头或者干脆不给。插件里的层级关系存在两张表一张记录用户之间的推荐绑定关系谁是谁的上级另一张记录每一笔订单产生的佣金明细。绑定关系一旦建立除非后台手动解绑否则长期有效。这里有个关键参数叫“绑定有效期”默认是永久但你可以改成按天算比如 30 天避免一个客户被反复算佣金。2.2 佣金计算的两个触发时机支付成功与订单完成分销插件不是支付一成功就立刻把钱算给推荐人而是分两步走。第一步订单支付成功时生成一条“待结算佣金”记录金额按订单实付金额乘以佣金比例算出来状态是冻结的。第二步订单完成服务结束、客户确认后冻结的佣金才转为“可提现”。这个设计是为了防止客户退款导致佣金已经发出去收不回来。在 6.2.6 版本里这个状态机在代码里体现为status字段的四个值0 待结算、1 已结算、2 已失效、3 已提现。你如果在做二次开发改佣金逻辑一定要围绕这个状态机来别自己另起一套。2.3 分销插件与主小程序的耦合点在哪里完整版小程序和分销插件不是两个独立应用插件是通过钩子挂载到主程序的订单流程里的。具体来说主程序在订单支付成功的回调里会触发一个order_paid事件分销插件监听这个事件然后去查这个下单用户的推荐人是谁再写佣金记录。同理订单完成时触发order_finished插件把冻结佣金解冻。你要排查分销不生效的问题第一个要看的就是这两个钩子有没有被正确注册。常见情况是主程序升级后钩子名称变了插件还在监听旧事件名结果佣金一条都不生成。2.4 用 SQL 直接查佣金流水比后台翻页快十倍后台的佣金列表适合运营看但开发排查问题时直接查数据库更快。下面这条 SQL 能一次性拉出某个订单关联的所有佣金记录包括推荐人、佣金金额和当前状态。-- 查询指定订单号关联的分销佣金明细 SELECT c.id AS commission_id, c.order_id, c.user_id AS 推荐人ID, u.nickname AS 推荐人昵称, c.amount AS 佣金金额, c.level AS 分销层级, CASE c.status WHEN 0 THEN 待结算 WHEN 1 THEN 已结算 WHEN 2 THEN 已失效 WHEN 3 THEN 已提现 END AS 佣金状态, c.created_at AS 生成时间 FROM wnjz_commission c LEFT JOIN wnjz_user u ON c.user_id u.id WHERE c.order_id 你的订单号 ORDER BY c.level ASC;逻辑说明主表是佣金表wnjz_commission通过order_id过滤出目标订单。level字段表示层级1 是直接推荐人2 是间接推荐人。status用 CASE 转成中文方便肉眼判断。参数方面你只需要替换order_id的值。如果查出来是空说明钩子没触发或者推荐关系没绑定上接着去查用户表里的inviter_id字段是否为空。3. 从零配置分销插件后台设置、推荐关系绑定与提现审核3.1 后台分销设置里必须改的四个参数进入后台分销管理页面你会看到一堆开关和输入框但真正影响钱怎么分的就四个。第一个是“分销开关”不开后面全白搭。第二个是“佣金计算基数”可选“订单实付金额”或“订单商品金额”区别在于前者扣掉了优惠券后者没扣。家政订单经常发优惠券我建议选实付金额不然老板会亏。第三个是“一级佣金比例”和“二级佣金比例”单位是百分比支持小数。第四个是“最低提现金额”这个设太低会导致大量小额提现申请财务处理起来很烦一般设 50 或 100。参数名建议值说明分销开关开启总控关闭后所有佣金逻辑停止佣金计算基数订单实付金额避免优惠券部分被算进佣金一级佣金比例5%10%直接推荐人所得二级佣金比例1%3%间接推荐人所得可设 0 关闭最低提现金额50 元减少财务处理频次3.2 推荐关系绑定的三种入口与优先级用户成为推荐人有三种方式一是分享小程序页面给好友好友点进来就自动绑定二是扫推荐人的专属二维码三是手动在个人中心输入邀请码。这三种方式在数据库里最终都写同一个字段inviter_id。优先级上插件默认“首次绑定后不可更改”。也就是说如果 A 先通过 B 的链接进来但没下单后来通过 C 的链接下单了佣金还是算给 B。这个逻辑在代码里是通过检查inviter_id是否为空来判断的不为空就不覆盖。如果你希望“谁最后分享算谁的”需要改插件里的绑定策略把“首次绑定”改成“最后绑定”。3.3 提现审核流程与打款状态回写推荐人申请提现后后台会生成一条提现记录状态是“待审核”。管理员审核通过后状态变成“已通过”但这不代表钱已经打了。真正打款可能是微信零钱、支付宝或银行卡打完款后需要手动把状态改成“已打款”同时把佣金记录里的status从 3 改成已提现。这个流程里最容易出问题的是“审核通过但没打款”推荐人看到状态是已通过就来催其实钱没到。我一般建议在后台加一个备注字段让财务填上打款流水号这样有据可查。3.4 用一段 PHP 代码手动补发漏掉的佣金有时候因为钩子没触发或者队列延迟某笔订单的佣金没生成。这时候不用慌可以写个临时脚本手动补。下面这段代码演示了如何根据订单号补一条一级佣金记录。?php // 手动补发佣金脚本仅限开发排查使用 // 引入主程序数据库配置 require_once __DIR__ . /config/database.php; $orderId 202501010001; // 替换为实际订单号 $db new PDO(mysql:host{$host};dbname{$dbname}, $user, $pass); // 1. 查订单信息 $stmt $db-prepare(SELECT user_id, pay_amount FROM wnjz_order WHERE order_id ?); $stmt-execute([$orderId]); $order $stmt-fetch(PDO::FETCH_ASSOC); if (!$order) { exit(订单不存在\n); } // 2. 查下单用户的推荐人 $stmt $db-prepare(SELECT inviter_id FROM wnjz_user WHERE id ?); $stmt-execute([$order[user_id]]); $user $stmt-fetch(PDO::FETCH_ASSOC); if (empty($user[inviter_id])) { exit(该用户没有推荐人无需补发\n); } // 3. 计算佣金比例从配置读取这里写死 5% $commission $order[pay_amount] * 0.05; // 4. 写入佣金记录 $stmt $db-prepare(INSERT INTO wnjz_commission (order_id, user_id, amount, level, status, created_at) VALUES (?, ?, ?, 1, 0, NOW())); $stmt-execute([$orderId, $user[inviter_id], $commission]); echo 补发成功佣金金额{$commission}\n;逻辑说明先查订单拿到下单用户和实付金额再查这个用户的inviter_id如果为空说明没绑定推荐人直接退出。佣金比例这里写死 5%实际使用时应从后台配置读取。插入时status设为 0表示待结算等订单完成后再改成 1。参数方面$orderId换成你要补的订单号即可。注意这个脚本只能跑一次重复跑会生成多条佣金记录。4. 分销插件跑起来之后最容易翻车的五个地方4.1 佣金比例改了但老订单跟着变现象运营把一级佣金从 5% 调到 8%结果发现之前已经生成的待结算佣金也变成了 8%。原因佣金金额是在订单支付时算好写进数据库的但有些二次开发版本会在展示时动态用当前比例重新算一遍。解决检查佣金列表的查询逻辑确保直接读wnjz_commission表里的amount字段不要在前端或查询时再乘比例。4.2 推荐人自己下单佣金算给了自己现象A 推荐了 BB 没下单A 自己下单了结果佣金算到了 A 的上级。原因插件默认不排除推荐人自己下单的情况而 A 的inviter_id可能是空导致逻辑走错。解决在佣金生成前加一个判断如果下单用户本身就是推荐人跳过或者把佣金给上级。更稳妥的做法是在后台开启“推荐人自购是否分佣”开关6.2.6 版本里这个开关是存在的默认关闭。4.3 订单退款后佣金没退回推荐人已经提现现象客户下单后推荐人立刻申请提现并到账随后客户退款佣金收不回来。原因提现审核太快而订单完成状态还没触发就手动打款了。解决把提现审核和订单完成状态挂钩只有订单完成后佣金才转为可提现。另外在退款逻辑里加一步把关联的佣金记录status改成 2已失效如果已经提现记录到欠款表里下次抵扣。4.4 分销链接在微信里被拦截提示“已停止访问”现象推荐人分享的小程序页面链接在微信里打开提示违规。原因分销链接里带了明显的邀请参数被微信判定为诱导分享。解决不要用短链跳转直接用小程序码。小程序码里带scene参数把推荐人 ID 编码进去微信不会拦截。生成小程序码的接口在 6.2.6 里是现成的后台分销设置里就有入口。4.5 佣金提现时提示“余额不足”但后台显示有余额现象推荐人申请提现系统提示余额不足但后台看可提现余额是够的。原因可提现余额和冻结余额是两个字段提现时扣的是可提现余额但有些版本在计算时把冻结的也算进去了导致实际可提现的比显示的小。解决查wnjz_user表里的commission_frozen和commission_available两个字段确认提现逻辑扣的是commission_available。如果显示不一致写个脚本重算一遍。5. 把分销插件用出复利三个进阶技巧与一个验证习惯第一个技巧是给推荐人打标签。插件本身只记录推荐关系但你可以根据推荐人带来的订单数量和金额在用户表里加一个referrer_level字段手动或自动标记为“普通推荐人”“金牌推荐人”。金牌推荐人的佣金比例可以单独设高一点比如 10%这样能刺激头部推荐人持续带单。实现方式是在佣金计算前查一下推荐人的等级然后从配置表里取对应比例而不是全局写死一个值。第二个技巧是用定时任务清理无效绑定。有些用户绑定了推荐人但一年都没下单这种关系占着数据库还影响统计。可以写个脚本把绑定超过 180 天且没有产生任何订单的推荐关系标记为失效inviter_id置空。这样新分享的人还能重新绑定不会因为“首次绑定不可更改”而卡死。第三个技巧是佣金提现走微信零钱自动打款。6.2.6 版本里提现是手动打款但你可以对接微信商户平台的“企业付款到零钱”接口审核通过后自动打款。需要配置商户号、API 密钥和证书然后在提现审核通过的回调里调用打款接口。打款成功后把提现记录状态改成“已打款”同时更新佣金记录状态。这个改造能把财务从重复劳动里解放出来但要注意商户号需要有足够的余额。验证习惯方面我每次改完分销逻辑都会做一件事用一个测试账号走完整流程——A 分享给 BB 下单B 确认完成A 申请提现后台审核打款。然后查数据库确认wnjz_commission表里那条记录的status从 0 变 1 再变 3金额和比例都对得上。这个习惯帮我拦住了至少三次上线事故因为分销的坑往往不在主流程而在状态流转的边界上。希望帮到你。本文还有配套的精品资源点击获取