简介这是一套面向房地产行业社交营销场景的微信全民经纪人系统V3.0商业版源码适合开发商、中介平台及有意搭建全民营销渠道的运营者使用。系统围绕微信生态实现了用户授权、房源发布、经纪人推广、佣金结算等核心链路后台入口与前端展示分离并包含安装引导、数据目录及模板资源便于二次开发与部署。压缩包共565个文件以146个php后台逻辑、102个html页面及大量jpg/gif/png图片资源为主辅以js交互脚本和css样式文件整体大小仅5.78MB结构紧凑。内容涵盖微信接口集成、用户角色权限、房源审核、社交分享追踪、佣金自动结算及安全防护等关键模块同时提供sql数据库文件、字体图标与模板样式可帮助开发者快速理解商业分销系统的完整实现思路。目前已有483人学习下载适合具备一定PHP开发基础、希望参考或搭建全民经纪人系统项目的技术人员。1. 微信全民经纪人系统V3.0到底在做一件什么事售楼处做老带新传统做法是让销售挨个打电话效率低、转化也难追踪。微信全民经纪人系统V3.0的做法是把推荐动作压缩成一次转发老业主把海报或链接发到朋友圈新客户点开完成微信授权登录推荐关系当场落库后续的报备、带看、成交、佣金计提全部挂在这条关系链上跟踪。这套微信全民经纪人系统V3.0完整纯净商业版不是租一个SaaS账号而是一套能直接部署到你自己服务器的源码包经纪人端是H5页面运营端是PC后台V3.0在佣金分级、结算权限和渠道统计上做了收敛。适合接私活的PHP工程师也适合想低成本搭建一套私域推荐场景的房产渠道公司技术人员。2. 全民经纪人的核心业务链路关系绑定、报备保护期和佣金状态机不看业务直接碰代码最容易把一套V3.0改成一堆互相矛盾的功能点。这个系统的业务核心其实只有三张表经纪人关系表、客户报备表、结算表。把这三张表的设计逻辑吃透后面的部署和二次开发都是在往这个骨架上添肉。2.1 关系绑定模型平级推荐和两级分佣怎么选在动手搭系统之前先决定关系怎么绑因为后面所有的佣金计算都建立在这张关系表上。V3.0商业版里常见的模型有两种平级推荐和两级分佣。平级推荐的意思是新经纪人只认一个直接推荐人不管推荐人的上级是谁分成比例只算一层两级分佣则是允许推荐人的上级也参与分成但一般不会超过两级。三级以上的模式在微信生态里容易触碰平台规则而且结算时只要有一环资料对不上整条链路就会被卡住所以大多数商业版会把它做成后台开关默认是关闭的。我一般建议先按平级推荐上线等运营数据证明确实需要多级激励再打开二级开关。“全民经纪人”本质是全民推荐人不是分销层级体系关系表只需要一个父级ID字段就够不要一上来就设计成树形结构后面维护成本会涨得很快。下面这张表是V3.0常见的结构CREATE TABLE broker_relation ( id int(11) NOT NULL AUTO_INCREMENT, broker_id int(11) NOT NULL COMMENT 被绑定的经纪人用户ID, parent_id int(11) DEFAULT NULL COMMENT 推荐人用户ID, bind_channel varchar(20) DEFAULT h5_share COMMENT 绑定渠道h5_share/h5_poster/miniapp, bind_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_parent (parent_id), KEY idx_broker (broker_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT经纪人推荐关系表;这里的broker_id是被推荐来的经纪人parent_id是邀请人的用户ID。bind_channel字段平时容易被忽略但它直接对应V3.0后台“渠道统计”菜单里的数据来源——海报带来的注册量和链接带来的注册量是分开算的也决定了渠道佣金能不能单独配置。绑定关系写入时只认openid先不校验手机号因为客户在授权登录那一刻还没填手机号等到首次报备时再补全手机号信息。2.2 客户报备与保护期为什么手机号必须是唯一键报备是经纪人把客户信息提交给项目方的动作也是佣金归属的依据这张表是整个系统里最容易算不清账的地方。V3.0的报备表核心字段就这些CREATE TABLE customer_report ( id int(11) NOT NULL AUTO_INCREMENT, broker_id int(11) NOT NULL COMMENT 经纪人用户ID, project_id int(11) NOT NULL COMMENT 楼盘项目ID, customer_phone varchar(20) NOT NULL COMMENT 客户手机号, customer_name varchar(50) DEFAULT NULL COMMENT 客户姓名, status tinyint(1) NOT NULL DEFAULT 1 COMMENT 1待审核 2审核通过 3保护期失效 4成交锁定 5作废, report_time datetime NOT NULL COMMENT 报备成功时间, protect_deadline datetime DEFAULT NULL COMMENT 保护期截止时间, PRIMARY KEY (id), UNIQUE KEY uk_project_phone (project_id,customer_phone) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT客户报备表;手机号加项目ID联合唯一索引是整个表设计里最关键的一个约束。业务规则通常是“同一楼盘同一个手机号谁先报备成功客户归属就锁定给谁”。如果不加这个唯一索引两个经纪人同时提交同一个手机号应用层先查再插的逻辑在并发下会双双通过后台就会出现两条报备记录后续审核人员根本不知道佣金该给谁。保护期的逻辑同样落在这张表上从报备成功到客户首次到访一般给7到30天保护期内其他经纪人不能抢报。V3.0的做法是存一个protect_deadline截止时间字段而不是只存report_time然后在SQL里算间隔。原因是运营后台可能手动给重点客户延长保护期存截止时间字段可以让每次比较都走索引也方便管理端直接修改。失效动作用定时任务跑UPDATE customer_report SET status 3 WHERE status IN (1, 2) AND protect_deadline NOW();这个定时任务每天凌晨跑一次注意WHERE条件里的status范围别漏了“审核通过但还没到访”的记录否则保护期失效流程会漏掉一整批客户。如果发现失效记录总是晚一天检查定时任务的执行时间是不是设在了凌晨之外。2.3 佣金结算状态机从待审核到已打款的字段设计结算模块是这套系统里流程最长的部分横跨报备表、回款表和打款表。V3.0用状态机控制整条链路把每个阶段拆成常量比在代码里写死数字要安全得多?php // config/settlement.php // 结算状态机的阶段顺序成交审核 - 待回款 - 已结算 - 已打款 - 已驳回 return [ PENDING_AUDIT 1, // 客户成交后待运营确认对应 customer_report.status 4 WAIT_PAYBACK 2, // 开发商回款前佣金暂挂不进入打款流程 SETTLED 3, // 回款到账生成结算账单 PAID 4, // 财务打款完成回填转账单号 REJECTED 9, // 驳回佣金终止 ];四个核心阶段的业务含义要理清。PENDING_AUDIT是销售在后台录入客户成交信息后运营人员核实报备记录、到访记录和成交合同确认无误才推进到下一步。WAIT_PAYBACK这个节点最容易被外包团队漏掉它的意思是佣金虽然已经确认但开发商还没把钱打给项目方绝不能先垫资给经纪人否则回款延迟时账目会直接对不上。SETTLED表示回款到账、可以生成结算单了这时后台会按比例自动算出一笔佣金。PAID是财务打款后把转账单号回填进系统这一步是后续对账的唯一凭证。所以结算表里两个字段必须保留customer_report_id用来关联报备记录transfer_sn用来记录转账单号。财务如果只改状态不回填单号月底对账时这笔钱就成了黑匣子全凭财务口头解释。V3.0的权限设计里这两个字段通常只有财务角色能写其他后台角色只有只读权限部署后别把这两个字段的编辑权限放开这是很多人改权限时容易顺手犯的错。3. 部署V3.0源码包LNMP初始化、数据库导入与微信参数配置拿到“完整纯净商业版”源码包后最容易犯的错是直接丢到服务器上就跑安装向导。这个标题里的“纯净”一般只代表没有演示数据、没有上家遗留的敏感配置、没有授权域名绑定不代表目录权限、PHP版本、伪静态规则都替你调好了。部署要按目录、环境、微信参数三步走。3.1 先看懂源码目录哪些目录能写、哪些目录上线前要删一套基于ThinkPHP 6或同代框架的V3.0目录结构基本是下面这个骨架/var/www/broker ├── app │ ├── controller # 前台接口login/report/commission │ ├── admin # 管理后台控制器 │ └── model # 数据模型 ├── config │ ├── database.php # 数据库连接 │ └── wechat.php # 公众号/支付参数统一配置 ├── public # Nginx 站点根目录 │ └── index.php ├── install # 安装向导部署完成后建议删除 ├── runtime # 缓存和日志必须可写 ├── route # 路由定义 └── extend # 第三方扩展拿到源码先做两件事第一看install目录还在不在如果向导存在可以先浏览一遍确认只是写配置和导数据没有不明来源的远程请求再使用用完后删掉或改成不可访问。第二看runtime目录是否存在并且权限可写用ls -ld runtime确认owner是php-fpm的运行用户通常是www-data。很多后台能打开但一登录就500原因就是runtime缓存目录写不进去。另外做一次全目录搜索找有没有残留的调试代码和硬编码链接grep -rn var_dump\|print_r\|127.0.0.1\|localhost /var/www/broker/app --include*.php这一步在“纯净商业版”上做一次能确认这套代码是真的干净。如果搜出敏感数据连接串或调试输出上线前全部清掉别指望后续再补。3.2 LNMP环境安装与数据库导入PHP版本和字符集的坑V3.0这类商业源码包对运行环境有明确偏好在Debian/Ubuntu系的Linux服务器上常见做法是装好NGINX、MySQL 5.7、PHP 7.4并启用一套基础扩展apt install nginx mysql-server php-fpm \ php-mysql php-gd php-curl php-redis php-zip php-mbstring php-xml systemctl start nginx mysql php7.4-fpm # 确认 MySQL 能连通后再导入 mysql -uroot -p -e SELECT VERSION();PHP版本这里要特别说明很多V3.0源码基于ThinkPHP 6在7.4下兼容性最好升到PHP 8后部分老扩展和方法会被废弃报错。如果源码包里使用了老式mysql_函数那这套代码实际是PHP 5时代的产物不要强行配PHP 7.4以上直接换一套维护更新的商业版更划算。创建数据库时字符集必须用utf8mb4客户姓名里如果有生僻字或emojiutf8会直接存不进去变成问号。导入SQL时把库名和路径写对mysql -uroot -p -e CREATE DATABASE broker DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; mysql -uroot -p broker /var/www/broker/install/broker_v3.0.sql导入完成后打开config/database.php把host、database、username、password四个值按服务器实际信息修改。这里最容易翻车的是账号权限如果创建MySQL用户时只授权了localhost权限而代码里填的是127.0.0.1部分环境会报连接拒绝直接都用localhost或者都用127.0.0.1保持一致。3.3 公众号与微信支付接口参数按这个顺序配才不会翻车微信生态的参数配置是整个部署过程里最磨人的一环报错信息往往只给一句“参数错误”具体哪里错要靠自己排查。先看一份完整的wechat.php配置// config/wechat.php return [ appid wx1234567890abcdef, secret abcdefghijklmnopqrstuvwxyz123456, token brokerV3, // 网页授权回调必须在公众号后台配置同样的域名 oauth_redirect https://broker.example.com/h5/login, mch_id 1600000000, api_key 32位商户密钥, apiclient_cert /var/www/broker/cert/apiclient_cert.pem, apiclient_key /var/www/broker/cert/apiclient_key.pem, ];AppID和AppSecret在公众号后台的“开发-基本配置”里拿Token是自己定的字符串用于服务器URL验证。这里的关键是配置顺序先保证网站能通过HTTPS访问再到公众号后台配置“网页授权域名”填成broker.example.com不带http://前缀然后配“JS接口安全域名”如果系统需要调用微信JSSDK上传图片或分享这个域名必须配最后才是微信支付接口的商户号和证书。支付部分的坑集中在两个点上一是证书路径要用绝对路径且apiclient_cert.pem和apiclient_key.pem两个文件不能被放在站点根目录下否则会被别人直接下载二是证书文件权限要设为600owner必须是php-fpm的运行用户。文件权限不对时接口会报“certificate not found”或莫名其妙的签名错误。注意config/wechat.php修改后如果服务器开了OPcachephp-fpm需要reload一次否则改完配置还是走旧值容易看着改对了实际没生效。4. 二次开发落点海报裂变、微信消息推送和佣金规则后台化V3.0拿来直接用没问题但多数部署方真正需要的不是原样功能而是针对具体楼盘和运营策略做改造。改得最多的三个点裂变海报的生成方式、消息通知的通道选择、佣金比例的灵活配置。4.1 裂变海报生成把推荐人ID压缩进二维码的短码方案老业主转发海报新客户扫码后要能自动绑定关系这个动作的核心是二维码内容的设计。最常见的翻车方法是直接把推荐人的openid拼进URL结果二维码图案又密又难扫还暴露了用户标识。更合理的做法是把经纪人ID压缩成一个短码再拼成链接?php // 生成经纪人专属推广二维码内容 $bindCode base_convert($brokerId, 10, 36); // 把ID转成36进制短码 $qrContent https://broker.example.com/h5/login?bind . $bindCode; // 调用二维码SDK生成png再用GD把二维码贴到海报底图上 $qrPng \Wechat\Qrcode::generate($qrContent, 300, 300); $poster imagecreatefromjpeg(poster_bg.jpg); imagecopy($poster, $qrPng, 280, 820, 0, 0, 300, 300); imagejpeg($poster, poster_ . $brokerId . .jpg, 90);这里两个参数值得说base_convert($brokerId, 10, 36)把十进制的经纪人ID转成36进制一位数字能表示的数值范围大很多二维码内容短一截识别率会明显提升二维码拼接位置(280, 820)要配合海报底图的尺寸来调常见的海报底图是750×1334像素二维码放在下方三分之一处留白区域别压到文字或人脸上。短码方案的另一个好处是后续接微信小程序开发版时能无缝复用。小程序码的scene参数有32字符的长度限制openid本身就有28位左右再加其他参数很容易超限而36进制短码通常只有3到4位塞进去绰绰有余。如果团队考虑用uniapp开发微信小程序版的经纪人端这套短码生成和解析逻辑可以直接搬过去。4.2 微信消息推送模板消息到期后通知模块怎么改V3.0早期版本的消息通知大多走公众号模板消息但微信平台已经逐步收紧模板消息的申请和下发规则。现在新部署的系统更建议直接切到订阅消息方案小程序端用订阅消息H5端看情况保留公众号模板消息或走一次性订阅。接口调用结构是下面这样?php // 发送订阅消息的请求结构 $payload [ touser $openid, template_id TMP1234567890, page pages/commission/detail, data [ thing1 [value 客户到访提醒], time2 [value date(Y-m-d H:i)], ], miniprogram_state formal, ]; // 通过 cURL 调用微信接口access_token 统一走缓存 $result curl_post( https://api.weixin.qq.com/cgi-bin/message/subscribe/send?access_token . $accessToken, json_encode($payload, JSON_UNESCAPED_UNICODE) );订阅消息和模板消息最大的差异是授权机制模板消息是用户关注公众号后就能定期收到订阅消息必须由用户主动触发一次订阅动作而且大部分模板只能下发一次。所以改造通知模块时要在经纪人完成报备或成交动作后弹窗引导授权否则后续通知根本发不出去。如果前端是H5页面page字段没有小程序页面对应可以直接去掉但这也意味着H5端能用的订阅能力更弱得评估是否保留公众号模板消息作为替代。用微信开发者工具调试时还有个细节miniprogram_state字段在开发版环境要填trial正式版才填formal填错会直接报错。开发阶段习惯性填了formal上线前忘了改回trial的情况很常见两个值都不难记但切换环境时别漏改。4.3 佣金比例后台可配置从写死常量到数据库规则原始V3.0里佣金比例如果写死在PHP代码里运营每次调整都要找开发改文件再发版这在楼盘营销场景里完全不可接受。最常见的改造方案是把比例抽成一张独立规则表CREATE TABLE commission_rule ( id int(11) NOT NULL AUTO_INCREMENT, project_id int(11) NOT NULL COMMENT 楼盘项目ID, broker_level tinyint(1) NOT NULL DEFAULT 1 COMMENT 1普通推荐 2超级经纪人, percent decimal(5,2) NOT NULL COMMENT 佣金比例(%), enabled tinyint(1) NOT NULL DEFAULT 1, create_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_project (project_id, broker_level) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT佣金规则表;读取规则时加一层缓存能避免每次计算佣金都查一次数据库?php function getCommissionPercent($projectId, $brokerLevel) { $key commission:{$projectId}:{$brokerLevel}; $percent Cache::get($key); if ($percent false) { $percent CommissionRule::where(project_id, $projectId) -where(broker_level, $brokerLevel) -where(enabled, 1) -value(percent); Cache::set($key, $percent, 3600); } return $percent; }缓存键设计成项目ID加经纪人等级避免全量规则表被反复读取修改规则后要主动清理对应键否则运营后台改了比例前台要等一个小时后才生效会被误认为系统坏了。percent字段用decimal(5,2)而不是float是因为浮点数在PHP里算佣金会留下精度误差——0.1加0.2的结果不是0.3这对钱来说是不能接受的。用decimal存储计算时再用bcmath扩展处理佣金金额做到分级别准确。5. 微信全民经纪人系统V3.0的避坑记录授权、支付、并发与数据安全这一章的每一条都是实际操作中反复遇到的写出来基本按“现象→原因→解决”的顺序照着排查能省半天时间。5.1 授权登录失败“redirect_uri参数错误”的三种原因现象新客户打开推广链接跳转微信授权页时直接报“redirect_uri参数错误”完全进不了登录流程。第一个原因是公众号后台的“网页授权域名”没配或配错。后台填的是不带http://的域名比如broker.example.com如果填成https://broker.example.com或者直接填了IP地址微信会拒绝回调。第二个原因是回调地址里的参数没有做URL编码。H5登录路径如果写成/h5/login?bindabcchannelh5_share符会被微信当成参数分隔符吃掉回调后bind参数就丢了微信校验回调地址时发现和后台配置不一致直接报错。第三个原因是这个域名没有ICP备案微信要求网页授权域名必须是已备案域名。解决方式也对应三条确认公众号后台网页授权域名填的是纯域名把回调URL整体用urlencode处理后再拼到授权链接里域名备案通过后再配置开发阶段不要用IP直连测试授权流程。V3.0的H5登录代码里redirect_uri参数基本都是拼好的排查时先看这个值最终落在微信链接里是什么样再跟公众号后台对比九成的报错都能在这一步找到。5.2 微信支付签名报错本地能跑线上却报错的排查思路现象在本地环境测试支付一切正常部署到服务器后第一次支付就报“签名错误请检查参数是否合法”而且不是每次都错是某些请求偶尔正常某些请求报错。这类问题属于支付对接里的玄学问题但其实都有明确原因。最常见的原因是证书文件和密钥文件权限问题。apiclient_key.pem通常要求权限600owner是运行PHP的www-data用户。如果上传时用了root账号文件权限是644PHP进程能读但微信支付SDK在验证文件所有权时会报错。第二个原因是apiclient_key.pem文件被文本编辑器打开过保存时加了额外的换行或BOM头密钥内容变了。第三个原因是公众号AppID和商户号没有在商户平台完成关联绑定这会导致部分接口调用时签名校验通过率时好时坏。解决时按顺序做先把证书目录权限改成700、文件权限改成600并确认owner再用命令行工具对比本机和线上的证书SHA1值是否完全一致最后登录商户平台在“产品中心-AppID账号管理”里确认AppID和商户号已经绑定。这套排查做完签名报错基本能定位到具体环节。要注意支付调试时别反复用同一笔订单号测试微信对相同订单号的重复请求会直接拒绝容易被误判成签名问题。5.3 并发报备同一客户唯一索引和重复插入的处理现象两个经纪人几乎同时提交同一个手机号的报备后台出现了两条记录运营人员审核时发现同一客户被锁定在两个人名下佣金归属直接纠纷。原因是报备接口的代码写成了先select再insert两个请求在同一时刻都查不到已有记录于是都顺利执行了插入。这种竞态在低并发下几乎不会出现一搞活动流量上来就爆发。解决方式就是前面2.2那张表里的唯一索引但索引建完之后代码也要跟着调整?php try { DB::table(customer_report)-insert($reportData); } catch (\Exception $e) { // 捕获 Duplicate entry 异常返回“该客户已被报备” if ($e-getCode() 23000) { return json([code 1001, msg 该手机号已被其他经纪人报备]); } throw $e; }注意这里要给用户明确的业务提示而不是直接抛500。业务规则上“先报备先锁定”意味着第二个提交的人必须知道自己没抢到否则他会一直重复提交并把问题归到系统头上。如果想支持一个客户同时被多人报备比如老带新和渠道各算各的就把唯一索引改成(project_id, customer_phone, report_type)用类型区分场景不要直接去掉唯一性约束否则同样的并发问题会换个形式重新出现。5.4 后台页面404伪静态规则没生效导致的翻车现象后台首页能打开但点击菜单进入列表页时URL变成了老式?madmincreportaindex风格还能访问一旦切换到PATH_INFO风格就404或者更极端的后台首页正常任何二级页面的接口调用全部404。原因是Nginx没有配置框架的伪静态规则所有请求都被送去了静态文件查找找不到就返回404。ThinkPHP 6这类框架需要把所有不存在的路径重写到index.phplocation / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } }配置完以后nginx -t先检查语法然后nginx -s reload。这里要特别确认server块里的root指向的是public目录比如/var/www/broker/public而不是项目根目录。很多部署把root指到了/var/www/broker结果index.php找不到报错信息却很模糊一会是404一会是空白页实际都是root路径的问题。如果用的是Apache则检查public/.htaccess是否存在以及AllowOverride是否开启V3.0源码包里一般自带这个文件不要自己去网上抄一段风马牛不相及的规则贴进去。注意改完Nginx配置后用curl -I http://127.0.0.1/h5/login测试一下返回码。如果还是404先看error.log里记录的实际路径别在rewrite规则上反复试错浪费时间。6. 上线前把V3.0当生产系统验收自检脚本、并发压测与三个指标源码部署完、功能都点过一遍不代表可以上线。V3.0这种源码包最容易在环境差异上翻车上线前用最小成本做一轮验收能挡住大部分低级事故。6.1 一条命令完成环境自检# 上线前最小自检数据库连接、runtime写权限、伪静态是否生效 mysql -uroot -pbroker -e SELECT COUNT(*) FROM customer_report; broker test -w /var/www/broker/runtime echo runtime ok curl -I http://127.0.0.1/h5/login | head -5第一条命令验证数据库账号密码和库名没错第二条验证runtime目录可写第三条验证伪静态规则生效。三条都过环境层面基本就位。如果mysql命令本身报错去config/database.php里核对账号权限不要改代码绕过去。6.2 用10个并发请求验证报备接口的唯一约束# 模拟10个经纪人同时报备同一个手机号观察是否只插入一条 for i in $(seq 1 10); do curl -s -X POST http://127.0.0.1/api/report \ -d broker_id$iphone13800138000project_id1 done wait # 然后去数据库查这个手机号的记录数量 mysql -ubroker -pbroker -e SELECT COUNT(*) FROM customer_report WHERE phone13800138000 AND project_id1; broker正确结果是10个请求中只有1条成功写入其余返回“已被报备”的业务提示。如果查出来数量大于1说明唯一索引还没建或者事务没按预期提交上线前必须修掉。这个测试做完再把测试数据删干净避免污染正式库。6.3 上线第一周盯住三个核心指标上线不是终点第一周每天看三个指标报备成功到审核完成的平均时长、保护期自然失效的比例、打款单的转账单号回填率。第一个指标反映运营审核效率超过24小时说明后台审核流程卡住了第二个指标反映保护期设置是否合理失效比例过高说明客户到访转化跟不上第三个指标直接反映财务是否按流程操作回填率低于100%说明有人在打款后没录单号月底对账必出问题。我接手这类源码包最深的教训是别急着加功能先把状态机、唯一索引、定时任务这三根基础桩打牢。V3.0只是把代码凑齐了真正决定上线后省不省心的是部署时有没有把规则想清楚。就拿状态机来说漏掉任何一个中间状态后面每一笔佣金都可能算错。把这条业务链路完整跑通一遍比多写十个接口都管用。希望帮到你。本文还有配套的精品资源点击获取
