企业官网建设流程全解析

简介：这是一套面向家政服务行业从业者与小程序开发者的柚子家政 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。

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 推荐了 B，B 没下单，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 分享给 B，B 下单，B 确认完成，A 申请提现，后台审核打款。然后查数据库，确认wnjz_commission表里那条记录的status从 0 变 1 再变 3，金额和比例都对得上。这个习惯帮我拦住了至少三次上线事故，因为分销的坑往往不在主流程，而在状态流转的边界上。希望帮到你。

本文还有配套的精品资源，点击获取