简介：这是一套面向家政行业创业者与小程序开发者的柚子家政完整版小程序源码，版本号6.2.6，并附带分销插件，适合需要快速搭建家政服务平台、实现技师管理与佣金结算的技术人员参考使用。压缩包共1196个文件，约9.88MB，以249个php后端逻辑、207个html页面、198个png与211个gif图像资源、106个js脚本及62个wxss、61个wxml小程序样式与结构文件为主，另含json配置、sql数据库脚本与字体图标等，前后端与素材齐备。本次更新重点完善了技师分佣体系，新增全局与技师独自分佣设置，支持按比例或固定金额在订单完成后核算；技师可绑定微信号并配置微信、支付宝、银行卡提现方式，附带提现明细；订单状态新增服务中环节，技师后台补充累计佣金、可提现佣金、累计及今日订单总额等统计数据，后台菜单也做了广告归类整理。目前已有920人学习下载，适合研究家政小程序分销与结算逻辑的开发者借鉴。
1. 家政小程序 6.2.6 版本里，分销插件到底解决了谁的痛点
家政行业做小程序，最尴尬的不是没流量，而是流量来了接不住。一个保洁阿姨的服务半径有限，一个门店的获客成本却年年涨，老板们真正想要的不是又一个展示页，而是让老客户愿意主动拉新、让阿姨愿意帮忙转介绍。柚子家政 wnjz_sun 6.2.6 加上分销插件这套组合，本质上就是冲着这个诉求去的：把「服务预约」和「裂变分佣」塞进同一个微信小程序里，用户下单、分享、拿佣金，门店只管派单和结算。
这套东西适合谁？一是手里有三五个门店、想用私域做复购的中小家政公司；二是接外包单、需要快速交付一套能跑的家政小程序的开发者；三是想研究分销逻辑怎么和本地服务结合的产品经理。它不适合纯小白直接上线商用，因为分销涉及资金结算和合规，你得先跑通再谈运营。下面我按「环境怎么搭 → 分销逻辑怎么落 → 参数怎么调 → 坑在哪」的顺序，把能复现的路径讲清楚。
2. 把 wnjz_sun 6.2.6 在本地跑起来：环境、依赖与首次启动
2.1 先看清这套小程序的技术栈和目录结构
拿到一个 .rar 完整版，别急着解压就往开发者工具里拖。先确认它是什么形态：wnjz_sun 这类家政小程序通常是「微信小程序前端 + 后端服务（PHP 或 Node）+ MySQL」的三段式结构，分销插件一般作为独立模块挂在后端，前端通过接口调用。解压后你会看到类似这样的目录划分：
| 目录/文件 | 作用 | 是否要改 |
|---|---|---|
miniprogram/ | 小程序前端源码 | 改 appid、接口域名 |
server/或api/ | 后端接口服务 | 改数据库配置 |
plugin/distribution/ | 分销插件模块 | 按需开启 |
sql/ | 数据库初始化脚本 | 必须导入 |
config/ | 全局配置 | 改域名、密钥 |
先别动代码，把结构看清楚，能省掉后面一半的返工。常见做法是先用编辑器全局搜一下appid、baseUrl、database这几个关键词，把需要替换的地方列个清单。
2.2 后端环境搭建：PHP 版本、扩展与数据库导入
多数这类家政小程序后端跑在 PHP 7.x 上，依赖 MySQL 5.7 或 8.0。我一般用宝塔或者本地集成环境先把 PHP 和 MySQL 起起来，再导入 SQL。步骤如下：
# 1. 确认 PHP 版本，建议 7.2 ~ 7.4，太高会踩兼容坑 php -v # 2. 检查必要扩展，缺一个都可能白屏 php -m | grep -E "pdo_mysql|curl|gd|mbstring|openssl" # 3. 创建数据库并导入初始化脚本 mysql -u root -p -e "CREATE DATABASE jiazheng DEFAULT CHARSET utf8mb4;" mysql -u root -p jiazheng < sql/install.sql # 4. 修改后端数据库配置 vim config/database.phpconfig/database.php里重点改四个值：hostname、database、username、password。改完先别急着开小程序，用浏览器访问后端入口，看有没有报错。如果返回 JSON 而不是一堆 PHP 错误，说明后端基本活了。
提示：PHP 8 上很多老代码会因为
each()、动态属性等写法直接报致命错误，别硬上，降到 7.4 最稳。
2.3 小程序端配置：appid、合法域名与编译预览
前端这边，打开miniprogram/app.js或project.config.json，把appid换成你自己的测试号，把接口请求的baseUrl指向你本地或服务器的后端地址。
// miniprogram/config.js 常见写法 const config = { // 换成你自己的后端地址，本地调试可用局域网 IP baseUrl: 'https://your-domain.com/api', // 分销插件开关，先关掉跑通主流程再开 distribution: { enable: true, commissionRate: 0.1 // 默认佣金比例，后面细调 } }; export default config;改完在微信开发者工具里点「编译」，先看首页能不能出来。如果首页白屏，八成是baseUrl没配对或者后端没起。这一步跑通，才算真正把 6.2.6 这套东西立起来了。
3. 分销插件的核心逻辑：佣金怎么算、关系怎么绑、钱怎么结
3.1 分销关系绑定：一次点击背后的三级链路
分销插件最核心的不是佣金比例，而是「谁是谁的下线」这个关系怎么存。常见做法是用户首次通过分享链接进入小程序时，把邀请人 ID 写进自己的inviter_id字段，并且只绑一次，防止后期被覆盖。
-- 用户表里通常会有这几个字段 ALTER TABLE `user` ADD COLUMN `inviter_id` INT DEFAULT 0 COMMENT '邀请人ID'; ALTER TABLE `user` ADD COLUMN `bind_time` INT DEFAULT 0 COMMENT '绑定时间'; -- 分销关系表，记录层级，方便算多级佣金 CREATE TABLE `distribution_relation` ( `id` INT AUTO_INCREMENT PRIMARY KEY, `user_id` INT NOT NULL COMMENT '下线用户', `parent_id` INT NOT NULL COMMENT '直接上级', `level` TINYINT DEFAULT 1 COMMENT '层级，1为直接', `create_time` INT NOT NULL );逻辑说明：用户 A 分享给 B，B 首次进入并授权后，后端把 A 记为 B 的inviter_id，同时往distribution_relation插一条 level=1 的记录。如果要做二级分销，再往上查 A 的上级插一条 level=2。参数上，level决定佣金比例，一般一级高、二级低，别设太多级，本地服务没必要。
3.2 佣金计算与结算：订单完成后怎么分钱
佣金不能下单就算，得等订单完成、过了退款期再结。常见做法是订单状态变成「已完成」时，触发佣金计算，写入佣金流水表，状态为「待结算」，等管理员确认后再打款。
// 伪代码：订单完成后计算佣金 function calcCommission($orderId) { $order = getOrder($orderId); if ($order['status'] != 'completed') return false; $user = getUser($order['user_id']); if (!$user['inviter_id']) return false; // 一级佣金 $rate1 = getConfig('commission_rate_1'); // 例如 0.1 $commission1 = $order['amount'] * $rate1; addCommissionLog($user['inviter_id'], $orderId, $commission1, 1); // 二级佣金（如果开启） $parent = getUser($user['inviter_id']); if ($parent['inviter_id']) { $rate2 = getConfig('commission_rate_2'); // 例如 0.05 $commission2 = $order['amount'] * $rate2; addCommissionLog($parent['inviter_id'], $orderId, $commission2, 2); } }参数说明：commission_rate_1和commission_rate_2建议放在后台可配，别写死。一级 8%～12%、二级 3%～5% 是家政行业比较能接受的区间，太高会吃掉门店利润。结算周期建议 T+7 或订单完成后 7 天，给退款留缓冲。
3.3 分销海报与分享链路：让阿姨愿意转发的三个细节
分销能不能跑起来，一半看佣金，一半看分享顺不顺手。插件一般会带海报生成功能，把小程序码和邀请人 ID 合成一张图。这里有三个细节决定转化：海报上的文案要写「找我预约有优惠」而不是「帮我砍一刀」；小程序码要带scene参数，才能识别邀请人；分享路径要直接落到服务详情页，别落首页。
// 生成带邀请人参数的小程序码（后端调微信接口） $scene = 'inviter_' . $userId; $qrUrl = 'https://api.weixin.qq.com/wxa/getwxacodeunlimit?access_token=' . $token; $data = [ 'scene' => $scene, 'page' => 'pages/service/detail?id=' . $serviceId, 'width' => 430 ]; // 拿到图片流后和海报底图合成，返回给前端展示scene参数有长度限制，别塞太多信息，用inviter_123这种短格式，后端解析出用户 ID 即可。海报底图建议做两套，一套给客户看，一套给阿姨看，文案不同。
4. 参数调优与后台配置：佣金比例、结算规则、权限怎么设
4.1 佣金比例与结算门槛的参数表
后台配置项别一股脑全开，先按下面这张表把关键参数定下来，再逐步调。
| 参数 | 建议值 | 说明 |
|---|---|---|
| 一级佣金比例 | 8%～12% | 直接邀请人拿 |
| 二级佣金比例 | 3%～5% | 上级的上级拿，可关 |
| 最低提现金额 | 50 元 | 太低结算成本高 |
| 结算周期 | T+7 | 订单完成后 7 天 |
| 是否自动结算 | 否 | 先人工审核，防刷单 |
| 分销开关 | 按门店 | 不同门店可独立开 |
这些值不是拍脑袋，是踩过坑之后收敛出来的。比例太高，门店做一单亏一单；太低，没人愿意转。50 元提现门槛能过滤掉大量小额提现请求，省掉不少人工。
4.2 后台权限与门店隔离：多门店场景怎么配
如果这套系统要给多个门店用，分销数据必须按门店隔离。常见做法是在佣金流水表和关系表里都加store_id，后台登录时根据账号所属门店过滤数据。
-- 给分销相关表加门店字段 ALTER TABLE `distribution_relation` ADD COLUMN `store_id` INT DEFAULT 0; ALTER TABLE `commission_log` ADD COLUMN `store_id` INT DEFAULT 0; -- 查询某门店的佣金流水 SELECT * FROM `commission_log` WHERE `store_id` = 1 AND `status` = 'pending';权限上，门店管理员只能看自己门店的佣金和提现，平台超管才能看全部。这一步不做，后期多门店一定乱套。
4.3 提现流程与风控：别让分销变成刷单入口
提现是分销里最容易出问题的地方。常见做法是用户申请提现 → 后台审核 → 打款 → 更新状态。风控上至少做三件事：同一设备多账号绑定同一邀请人的，标记异常；订单退款后佣金要能追回；提现频率异常的，进人工审核队列。
// 提现申请时做基础风控 function applyWithdraw($userId, $amount) { if ($amount < getConfig('min_withdraw')) { return ['code' => 400, 'msg' => '低于最低提现金额']; } // 检查是否有未完成的退款订单 if (hasRefundingOrder($userId)) { return ['code' => 400, 'msg' => '有退款中的订单，暂不可提现']; } // 检查近期提现频率 if (getWithdrawCountLastDay($userId) > 3) { return ['code' => 400, 'msg' => '提现过于频繁，请稍后再试']; } return createWithdrawOrder($userId, $amount); }这些判断看着简单，但能挡掉大部分薅羊毛的。血泪经验是：上线前一定要用测试账号把「下单 → 完成 → 佣金到账 → 提现」整条链路走一遍，别等真实用户来帮你测。
5. 避坑与排查：这套家政分销小程序最容易翻车的五个地方
5.1 分销关系被覆盖，佣金给错人
现象：用户 B 明明是通过 A 的链接进来的，最后佣金却算给了 C。原因通常是绑定逻辑没做「只绑一次」，B 后来点了 C 的链接，inviter_id被更新了。解决：在绑定前先查inviter_id是否已存在，存在就直接返回，不覆盖。
5.2 订单退款后佣金没追回，门店白亏
现象：客户下单拿了佣金，后来退款了，佣金却已经结算给邀请人。原因：佣金计算和退款逻辑没联动。解决：在退款成功回调里，把对应订单的佣金流水状态改成「已失效」，如果已打款，从下次提现里扣回或标记欠款。
5.3 小程序码 scene 参数解析失败，邀请人识别不到
现象：海报扫出来进的是首页，邀请关系没绑上。原因：scene参数超长被截断，或者前端没在onLoad里解析。解决：scene控制在 32 字符内，前端在页面onLoad(options)里取options.scene并 decode，再传给后端绑定。
5.4 PHP 版本不兼容，后台白屏或接口 500
现象：环境搭好了，后台一打开就白屏，或者接口返回 500。原因：代码用了 PHP 7.4 以下或 8.0 以上不兼容的写法。解决：先看 PHP 错误日志，定位到具体文件和行号，能降版本就降到 7.4，不能降就改代码。
5.5 提现审核没做二次确认，误点打款
现象：后台管理员手滑点了「已打款」，实际没转账。原因：打款按钮没有二次确认和操作日志。解决：打款操作加确认弹窗，并记录操作人、时间、金额，方便对账。
6. 上线前怎么验证分销链路真的通了：一套自测清单与两个进阶技巧
分销这套东西，最怕的是「看起来通了」。我一般会在上线前用两个测试账号把整条链路跑三遍，每遍都换不同的入口：第一遍从分享链接进，第二遍从海报扫码进，第三遍从历史会话进。三遍都能正确绑定邀请人，才算关系链路没问题。
验证佣金计算时，别只看数字对不对，要看流水表里的记录是否完整。一条完整的佣金流水应该包含：订单号、邀请人 ID、下线 ID、层级、金额、比例、状态、创建时间。缺任何一个字段，后期对账都会出问题。下面这张自测清单可以直接抄：
| 验证项 | 操作 | 预期结果 |
|---|---|---|
| 关系绑定 | A 分享给 B，B 首次进入 | B 的 inviter_id = A |
| 重复绑定 | B 再点 C 的链接 | inviter_id 仍为 A |
| 一级佣金 | B 下单并完成 | A 收到一级佣金流水 |
| 二级佣金 | A 有上级 D | D 收到二级佣金流水 |
| 退款追回 | B 的订单退款 | 对应佣金流水失效 |
| 提现门槛 | A 申请提现低于 50 | 提示低于最低金额 |
| 门店隔离 | 门店 1 管理员登录 | 只看到门店 1 的佣金 |
两个进阶技巧。第一个是佣金比例按服务品类分开配，保洁和月嫂的利润空间不一样，统一比例要么亏要么没人推。做法是在服务表里加commission_rate字段，计算时优先取服务自己的比例，取不到再用全局默认。第二个是给分销数据加一个「模拟结算」按钮，上线前用测试数据跑一遍结算流程，看看打款金额、手续费、余额扣减对不对，别等真实提现才发现算错。
我自己踩过最深的一个坑，是早期没做退款追回，一个月被薅掉小两千的佣金，后来加了失效逻辑才堵住。所以这套东西能不能用，不取决于功能多全，取决于你有没有把「钱」这条线走通、走对。希望帮到你。
本文还有配套的精品资源，点击获取
