简介一套面向小程序开发者和WiFi运营商的WIFI大师v4.47分销系统源码基于小程序前端与PHP后台独立运行便于快速搭建带流量主广告变现的WiFi分销平台。后台覆盖平台管理、WiFi码导出体验版/正式版、本地存储开关、平台统计、ChatAI模型选择与Token限制、版权设置、公告图标、插件中心显示等完整功能并修复了空码跳转白屏、Tabbar被广告遮挡、ChatAi无法使用等常见问题优化了后台上传小程序、创建WiFi、清除缓存及板块分页等操作。压缩包共1882个文件以php后端逻辑文件为主1487个辅以png图片、js脚本、json配置、css样式等资源整体16.22MB目录结构清晰便于二次开发与部署调试。已有441人学习/下载适合具备PHP和小程序基础、希望快速获得可运营WiFi分销系统的开发者参考学习。1. WIFI大师v4.47到底是什么一句话说清它的赚钱逻辑把一套WIFI大师v4.47独立运行版部署到自己的服务器上本质上是自建一套「上网计费分销结算广告变现」的闭环系统。它面向的场景很具体商铺、酒店、景区、公寓这类有公网WiFi、但希望用WiFi产生收入的地方。用户连上WiFi后不再是免费直连而是被引导到一个认证页面要么按分钟/按流量付费要么看一段激励视频换取上网时长。店铺老板获得网络服务和广告分成代理商通过发展商户拿分润运营方也就是你掌控整条数据链路——这是它叫“分销系统”而不是“无线热点工具”的原因。这套源码最值得关注的是“独立运行版”这四个字它不依赖第三方SaaS平台数据库、支付回调、广告流量主、分销结算全部由自己部署的后端接管。这意味着你有完整的数据主权也能自己调整分润比例和广告策略。本文从商业模型、部署步骤、流量主接入、真实踩坑四个层面把这个项目的落地路径完整拆一遍。2. WIFI分销的账怎么算认证计费、分销分润与流量主三条钱线2.1 认证订单的完整状态机从用户连上WiFi到结算入账WIFI分销系统和普通路由器管理后台最大的区别在于它把每一次WiFi连接变成了一笔“订单”。我在搭建这类系统时第一件事不是写代码而是先把订单的状态机画清楚。因为分润、对账、退款、广告结算全部挂在这个状态机上状态定义错一个后面运营时会非常被动。常见状态流转是待认证 → 认证中 → 已连接 → 计费中 → 已结算 / 已过期。用户连上WiFi后系统把对方重定向到认证页此时订单状态是“待认证”用户完成支付或看完广告认证通过状态变“已连接”认证通过到断网这一段时间里系统按分钟或按流量累计费用订单进入“计费中”会话结束时执行扣费并生成结算记录。注意一个容易被忽略的状态欠费暂停。套餐时间用完后系统应立刻断开用户连接而不是继续累计否则后续对账会差很多。2.2 分销层级与分润参数一级代理和二级代理的配置边界分销是这个项目区别于普通WiFi认证系统的核心卖点。代理商带你拉来商户商户产生上网收入后你按百分比返给代理商。层级设置需要考虑结算的可实现性——层级太多订单拆分和退货回滚会非常复杂。我经手过的配置里两层分销已经够用商户收益先按平台抽成比例扣掉平台部分剩余部分在一级代理和二级代理之间按比例拆分。这里有一个参数配置上的关键点分润基数按“实收金额”计算而不是按“订单金额”计算。如果用户用了优惠券、支付部分退款按订单金额分润会造成代理佣金虚高。我在分润表上会额外存一个字段记录分润基数来源便于审计。分润比例的配置类似这样角色分润比例分润基数结算周期一级代理30%商户实收金额 - 平台技术服务费T1 出账T7 打款二级代理15%一级代理分润后的剩余部分随一级代理同步结算商户55%实收金额扣减两级分润后实时余额手动提现比例只是示例真正上线前要做的第一件事是判断你的支付通道能否支持“订单→分润→打款”的资金链路自动流转。如果不能原路退回至少要在后台做资金流水冻结避免用户退款后代理佣金被多记。2.3 流量主的激励视频与时长解锁广告收益的拆账模型带流量主的小程序源码很多但把流量主和WiFi计费结合的逻辑才是真正的设计难点。常见做法是用户点击“看广告免费上网”小程序前端拉起微信的激励视频广告用户完整看完后触发onClose回调前端拿到结果请求后端发放时长。广告收益的拆账和分销是两套逻辑。广告费由微信广告平台与小程序主体直接结算流量主收益回到你手里再由你按约定比例分给提供WiFi环境的商户。我在实际项目中遇到的头号问题是前端没收到广告回调用户没看广告但也拿到了时长。解决思路是后端发放时长必须依赖广告回调的服务端二次验证而且要区分“广告展示”和“广告完播”两种事件后者的收益单价明显更高。3. 把WIFI大师v4.47装进自己的服务器环境、数据库与最小联调3.1 运行环境选型nginx PHP MySQL Redis 的分工与版本选择独立运行版的意思是“部署环境由你自己掌控”。这类WIFI分销源码最常见的技术栈是PHP后端 MySQL数据库 Redis做会话缓存前台用微信小程序。Nginx负责静态资源和小程序API的HTTPS转发。如果你的业务量在几百个商户以内这个组合性价比最高单台2C4G的云服务器就能扛住成本可控。环境版本的选择比想象中重要。PHP不要去追最新版本优先用7.4或8.0兼容性最好。MySQL用5.7或8.0均可但注意字符集统一utf8mb4否则用户昵称里的emoji会直接写不进去。Redis版本无太多约束只要内存不低于512MB即可。小程序前端的HTTPS证书用免费的三个月证书即可每年手动续几次不要在这个环节多花钱。3.2 建库建表与初始化六张核心表和一个初始化脚本拿到源码包后先别急着部署第一件事是看安装目录下是否有install.sql或db.sql这类初始化文件。没有初始化文件的项目要非常警惕说明作者没考虑过交付的完整性。以下表结构是我的实践版本你可以对照思路调整商户表、代理表、订单表、分佣记录表、套餐表、广告记录表。CREATE TABLE wifi_order ( id bigint(20) unsigned NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号规则日期随机串, merchant_id int(11) NOT NULL COMMENT 商户ID, user_openid varchar(64) NOT NULL COMMENT 用户小程序openid, device_mac varchar(20) DEFAULT NULL COMMENT 路由器MAC地址, package_id int(11) NOT NULL COMMENT 套餐ID, amount decimal(10,2) NOT NULL COMMENT 实付金额单位元, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待认证 1已连接 2计费中 3已结算 4已退款, start_time datetime DEFAULT NULL COMMENT 上网开始时间, end_time datetime DEFAULT NULL COMMENT 上网结束时间, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_order_no (order_no), KEY idx_merchant (merchant_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENTWiFi上网订单表;这里要特别说明device_mac字段它记录的是用户连接的那个WiFi路由器MAC而不是用户手机的MAC。手机MAC在iOS和Android高版本都做了随机化存了也没法用于精准识别。真正用于会话识别的键是order_no前端每次轮询上网状态都带这个订单号服务端通过它来判断套餐是否到期。初始化脚本里还要注意预设一个管理员账号和至少一个平台方的收款配置。不要用源码里写死的admin/123456上线这种弱口令第二天就会被扫描器打穿。3.3 portal 认证接口用户连接WiFi时后端做了什么当用户连上WiFi打开任意网页时路由器会把HTTP请求重定向到认证服务器。这个跳转通常携带三个参数router_id路由器编号、mac路由器MAC、url用户原本要访问的地址。后端认证接口要做的不是“把用户放行”而是做四件事查商户状态、查套餐库存、生成或复用订单、下发认证结果给路由器。// 认证接口核心逻辑入口/api/portal/auth public function auth(Request $request) { $routerId $request-get(router_id); $mac $request-get(mac); $openid $this-getOpenidFromSession($request); // 1. 查路由器对应的商户是否营业中 $merchant MerchantModel::where(router_id, $routerId)-first(); if (!$merchant || $merchant-status ! 1) { return json([code 0, msg 当前WiFi未开放]; } // 2. 在有效期内复用订单否则创建新订单 $activeOrder OrderModel::where(user_openid, $openid) -where(merchant_id, $merchant-id) -whereIn(status, [1, 2]) -orderBy(id, desc)-first(); if (!$activeOrder) { $orderNo $this-generateOrderNo($merchant-id); // 这里查用户是否有未用完的套餐有则直接激活 } // 3. 调用路由器AC接口下发放行规则白名单模式 $result $this-routerApi-addWhitelist($mac, $openid); // 4. 返回认证成功页自动跳转到用户原目标地址 return redirect($request-get(url))-with(auth_ok, $orderNo); }注意第三步addWhitelist是异步操作还是同步操作决定了用户会不会“等了五秒但上不了网”。我建议这里做同步调用并且设置超时重试最多三次。如果路由器接口三次都失败要返回一个明确的失败页提示“认证超时请重试”而不是默默失败让用户误以为网坏了。3.4 小程序认证页与后端的对接wx.request 的完整调用链小程序端的工作相对简单核心就一个页面当用户点“我要上网”时先请求后端获取套餐列表再拉起支付或激励视频。这里有一个体验细节用户连上WiFi后可能没有外网小程序本身加载不了。解决这个问题的常见做法是路由器AC配置中将小程序合法域名的IP和端口临时加入放行列表让用户能加载出认证页但其他流量全部拦截。// 认证页的核心逻辑拉取套餐列表 广告换时长 Page({ data: { packages: [], adUnlocked: false }, onLoad() { const routerId this.getRouterIdFromUrl(); // 拉取当前WiFi可用的套餐列表 wx.request({ url: https://api.example.com/api/portal/packages, method: GET, data: { router_id: routerId }, success: (res) { this.setData({ packages: res.data.data.list }); } }); }, playAdForFree() { // 激励视频只会在用户主动点击时触发 wx.createRewardedVideoAd({ adUnitId: adunit-xxxxxxxxxxxx }).show().catch(() { wx.showToast({ title: 广告加载失败请稍后再试 }); }); } });支付路径和广告路径的触发条件要区分开支付调用wx.requestPayment广告调用wx.createRewardedVideoAd。如果用户没支付成功就跳到广告流程容易让后台出现“未支付但已发放时长”。所以前端逻辑要加一个状态锁用户点击支付按钮后到支付结果回调返回前禁止点击其他任何按钮。3.5 独立运行版最要紧的4个配置参数部署这类源码时间长了我总结出四个上线前必须亲自确认的配置项缺任何一个都会在后期产生连锁麻烦。第一个是PAY_NOTIFY_URL支付异步回调地址。这个地址必须是公网可访问的HTTPS地址而且不能带任何参数因为微信支付回调会把参数POST到这个URL上。很多人部署时把这个地址配成了带?fromxxx的字符结果回调一直失败。第二个是AD_CALLBACK_KEY流量主回调的密钥用于服务端验证广告回调的真实性。这个key不要直接写在代码里放到环境变量或者独立的配置文件里。第三个是REDIS_PREFIX缓存前缀。多个环境共用一台Redis时没有前缀会导致商户数据和用户会话串号。第四个是分销默认比例我一般建议默认关掉二级分润等一级代理稳定了再开因为二级分润的回滚逻辑复杂度不止翻倍。4. 把微信小程序流量主接到认证流程里广告位、回调验签与对账4.1 三个适合WiFi场景的广告位激励视频完播、banner曝光、插屏退出流量主并非所有广告位都适合WiFi认证场景。banner适合挂在认证成功页和套餐列表页底部收益稳定但单价低插屏广告适合在用户完成支付、页面消失时弹出因为此时用户处于等待状态点按概率相对高激励视频是WiFi场景最值钱的广告位它的逻辑是用户看完30秒完整的视频获得1小时或2小时免费时长。我在实际运营中观察到激励视频的填充率大约在70%到85%之间剩余用户会走支付路径因此不会出现完全无法上网的情况。广告位的配置要点在于adUnitId要和自己在流量主后台创建的广告位ID一一对应并且类型不能混用。把banner的adUnitId拿去请求激励视频会直接报错。开发阶段可以用测试广告位但上线前必须替换成正式广告位否则收益归零。4.2 广告播放回调与签名校验服务端二次核验的接口小程序流量主广告有一个关键机制广告完播后前端会收到onClose回调同时微信服务器会向你在流量主后台配置的回调地址发送一条服务端通知。我在最初接入时只信前端回调结果吃过大亏——因为App端存在用户刷机或篡改客户端绕过广告的可能。正确做法是以后端回调为准发放时长前端回调仅作UI提示。// 流量主广告回调验签函数 public function adCallback(Request $request) { $data $request-post(data); // 加密的数据 $sign $request-post(sign); // 签名串 // 1. 校验请求时间戳防止重放攻击 $timestamp $request-post(timestamp); if (abs(time() - $timestamp) 600) { return reject: time out; } // 2. 用AD_CALLBACK_KEY做HMAC-SHA256验签 $calcSign hash_hmac(sha256, $data, env(AD_CALLBACK_KEY)); if ($calcSign ! $sign) { return reject: bad sign; } // 3. 解密数据拿到广告事件详情 $secretKey env(AD_SECRET_KEY); // 与广告后台配置的密钥一致 $aesKey base64_decode($secretKey); $decrypted openssl_decrypt($data, AES-128-CBC, $aesKey, OPENSSL_RAW_DATA, $aesKey); // 4. 解析广告事件并发放对应时长 $event json_decode($decrypted, true); if ($event[action] end $event[ad_type] rewarded_video) { // 给openid发放时长套餐记录流水唯一key防止重复发放 } return success; }这里最关键的一步是第四步的“幂等处理”。广告回调同一事件可能因为网络重试被发送多次如果每次回调都增加时长用户看一次广告白嫖几个小时收益损耗非常严重。在广告记录表里必须用广告事件IDevent[ad_evt_id]做唯一索引重复请求直接返回成功但不再发放。4.3 收益对账的三种口径广告后台、本地流水、分销结算流量主结算有一个隐藏的时间差微信广告平台的收益数据是T1更新的而且存在七天内的补量调整。这意味着你本地看到的广告曝光流水和广告后台的收益金额永远不会完全一致。我一般运营时把数据分成三个口径广告后台的结算金额、本地广告记录表的曝光/完播数、分销结算时实际分给商户的金额。对账时以“广告后台最终结算金额”为准乘以你和商户约定的分成比例得出应分金额再和分销系统里“shop_revenue”表累计出的实际分成金额做差。差异在3%以内属于正常波动超过5%就要排查是不是有广告回调漏记。我之前就遇到过因为服务器时钟不准导致回调时间戳校验失败从而漏记了一整天广告流水的情况。5. 从部署到运营WIFI大师v4.47的7个踩坑记录与排查思路5.1 现象用户连上WiFi后认证页打不开一直转圈原因最常见的是DNS没有正确放行。用户连接WiFi但尚未认证时路由器会把DNS查询劫持到认证服务器但认证服务器本身如果没有正确配置域名解析或使用了CDN导致IP变动用户就无法加载认证页面。解决路由器上把认证域名设置成A记录直连不要接CDN。开发环境下可以先配置本地hosts验证连通性再逐步排查DNS劫持链路。5.2 现象用户认证成功后只能上微信其他网页全都打不开原因AC白名单下发成功但MAC地址大小写不一致。路由器上报的MAC地址是aa:bb:cc:dd:ee:ff小写数据库里存的是AA:BB:CC:DD:EE:FF大写精确匹配失败。解决所有涉及MAC地址的存储和匹配逻辑在入库前统一strtolower()转换涉及openid时则不要修改大小写因为微信openid严格区分大小写。5.3 现象分销佣金金额对不上代理后台的预估收益与实际打款差几百块原因订单退款后佣金没有反向回滚。用户购买套餐后申请退款订单状态改成“已退款”但佣金记录表里这条订单的佣金还静静躺在那里没有生成负数记录。解决在订单状态变更的同一个事务里强制写入一条负数的佣金回滚记录。我在线上环境踩过一次后直接把佣金表设计的经不起这类问题——每次操作都写入记录而不是在原有记录上修改金额。5.4 现象流量主收益与广告后台差距超过10%原因广告回调丢失大多是前端页面销毁太早。用户在看完激励视频的瞬间立刻关闭了小程序页面前端onClose还没触发就已经销毁了WebView。解决在onClose回调里先调后端确认已收到回调再执行页面重定向而不是立即wx.redirectTo。5.5 现象微信审核小程序被驳回理由是“诱导分享”原因认证成功页放了“分享给好友可延长时长”的按钮。微信对诱导分享零容忍而且WiFi工具类小程序本身在类目审核上就比较敏感。解决去掉所有涉及分享、集赞解锁的UI把营销逻辑全部收敛到激励视频和支付两种路径上。5.6 现象服务器负载不高但接口响应经常超过3秒原因MySQL查询没有走索引。运营几天后订单表变大where status 0这种查询全表扫一遍。解决上线前在wifi_order表的(user_openid, status, created_at)上建联合索引在商户流水表的(merchant_id, created_at)上建联合索引。这种问题不会在测试环境暴露只有生产环境数据量上来才发作。5.7 现象一键部署脚本跑完但小程序连不上API原因HTTP强制跳转HTTPS未配置或证书链不完整。小程序的request请求强制要求HTTPS且不能使用IP直连。解决如果用宝塔面板部署确认SSL证书已正确配置并开启“强制HTTPS”。强烈建议用一个本地命令行小程序IDE环境模拟请求看返回的statusCode是200还是500。6. 用三条命令和一个样本验证一套WIFI分销系统是否健康6.1 看订单闭环日志把一次“连接-认证-计费-结算”完整串联起来我每部署完一套独立运行的WIFI分销系统都会做一个最小的闭环验证用真实手机连WiFi走一遍认证、看广告、下线、查分佣的完整路径然后看服务端日志里这次会话的轨迹。grep orderNo20250610A001 /var/log/nginx/access.log | awk {print $4, $7}这条命令把一次订单从认证创建到结算回调的全部请求路径打印出来。正常应该看到/api/portal/auth→/api/ad/callback→/api/order/status→/api/commission/settle四条记录。缺少任何一条说明链路有断裂。6.2 捞广告回调看广告事件是否在5秒内到达服务端广告回调的时效性决定了对账偏差大小。我习惯用日志里ad_evt_id的出现时间减去用户点击广告的前端上报时间来估算延迟。延迟超过30秒的占比超过5%说明回调通路有拥塞风险。6.3 分佣复盘永远先用最小样本试算我会准备一个固定的测试数据商户A、一级代理B分润比例30%套餐售价10元。跑完一次完整流程后按照“10元 × 70% × 30% 2.1元”手算一遍再和系统里commission_record比对。这条验证永远手工执行不写自动化脚本。自动化脚本的误差会和系统本身的误差同源只有手算才能发现逻辑上的隐性缺陷。这个习惯让我避免了好几次大额分润的算错事故希望帮到你。本文还有配套的精品资源点击获取