简介：一套面向公众号约玩、树洞与陪聊业务场景的开源版源码，适合具有一定PHP和前端基础的开发者或运营者快速搭建属于自己的陪聊服务平台。整个资源包约28.49MB，共2000个文件，其中1291个JavaScript文件、227个HTML页面、150个Markdown文档、146个JSON配置、131个CSS样式等，分别对应前端交互逻辑、页面结构、部署教程、系统配置和界面外观，目录清晰便于按需查阅。功能层面，源码支持钱包预充值、店员收藏、礼物打赏，并内置上下级分销与多分销返点开通制度，可灵活配置推广体系。与市场上加密的流程版本不同，此版本为开源未加密版本，前端采用H5编译形式，更适合学习研究或直接改造上线。包内附带详细Markdown部署教程，能有效降低公众号环境下的搭建难度。目前已有77人浏览学习，适合作为从零部署同类系统的参考。

1. 公众号约玩树洞系统：陪聊源码拆完之后，真正值钱的是“匹配与结算”

公众号约玩树洞系统，说白了就是一套把“倾诉需求”变成“付费陪聊订单”的微信生态业务源码。很多人第一次接触陪聊源码，以为它就是一个聊天窗口，实际拆开这份带教程的源码才发现，它的核心精力全花在用户匹配、订单状态和支付回调这三件事上，聊天反而不复杂。它能解决什么问题？对运营方来说，是把公众号粉丝转成付费用户的完整闭环——用户进公众号匿名倾诉，系统匹配陪聊师，按分钟计费，微信支付自动结算。适合谁？适合手里有公众号流量、想快速上线付费陪聊或树洞业务的技术运营，也适合专门研究微信 JSAPI 支付回调的开发者。这份源码带教程，从公众号后台配置到数据库初始化都有覆盖，下面按我的拆解顺序来讲。

2. 架构拆解：消息路由、数据表与状态机

2.1 微信公众号开发者模式与消息流转链路

先说大框架。微信公众号不是服务器直接收到用户消息，而是用户先给微信服务器发消息，微信再把这条消息 POST 到你在公众号后台配置的 URL 上。URL 一般指向源码里的 index.php，这个文件就是整套系统的入口。整个链路是：

用户发文本 → 微信服务器 → 你的 Nginx → PHP 入口（index.php）→ 业务分发 → 数据库读写 → 被动回复 XML 报文 → 微信服务器 → 用户收到消息

这里最关键的验证是第一次配置 URL 时，微信会带 signature、timestamp、nonce、echostr 四个参数 GET 请求你的 URL。你的程序要把 token、timestamp、nonce 按字典序排序，拼成一个字符串做 SHA1 加密，对比签名一致后才返回 echostr。源码里的 checkSignature() 方法干的就是这件事：

<?php // 入口文件 index.php 里的签名验证 define('TOKEN', 'your_token_here'); // 与公众号后台填写的 Token 必须一致 function checkSignature() { $signature = $_GET['signature'] ?? ''; $timestamp = $_GET['timestamp'] ?? ''; $nonce = $_GET['nonce'] ?? ''; // 微信要求 token、timestamp、nonce 三个参数字典序排序 $tmpArr = [TOKEN, $timestamp, $nonce]; sort($tmpArr, SORT_STRING); $tmpStr = implode($tmpArr); $tmpStr = sha1($tmpStr); return $tmpStr === $signature; } // 只有 echo 验证请求才走这里 if (isset($_GET['echostr'])) { if (checkSignature()) { echo $_GET['echostr']; exit; } exit('signature error'); } // 业务消息从 php://input 读原生 XML $postStr = file_get_contents('php://input');

逻辑说明：TOKEN 常量要和公众号后台“服务器配置”里填的 Token 一字不差，这是签名能对上的前提。排序用的是 SORT_STRING，千万不要用默认的 SORT_REGULAR，否则纯数字场景下排序结果可能不一致。签名验证通过后，echostr 原样返回给微信，验证才能通过。之后的业务消息和事件推送都走 POST，从 php://input 读原始 XML，用 simplexml_load_string 解析。

参数说明里有个细节：很多人一开始会把 $_GET['echostr'] 的判断放在签名验证之前，看起来没毛病，但这样等于把验证逻辑架空了——微信要求是验签通过才回显 echostr，顺序不能反。

2.2 数据表设计：三张核心表撑起整个业务

这套源码的数据库一般就三张核心表加几张辅助表。我拆的时候最先看的就是表结构，因为业务逻辑到最后全是查表、改表。按常见版本，把表结构列出来，你会发现在这三张表里，状态字段几乎是全部业务的关键。

用户表 t_user：

树洞帖子表 t_post：

订单表 t_order：

为什么要强调这三张表？因为这套业务的闭环就是“用户 → 树洞帖子 → 陪聊订单 → 结算”。用户先通过树洞表达诉求，系统识别到用户有继续聊的需求后推陪聊师名片，用户下单，陪聊师提供服务，订单从待支付一路走到已完成。做二次开发，改的无非就是这三个状态机。还有一点容易忽略：t_post 的 content 字段在导入数据库前，要把表的默认字符集确认一下，常见做法是统一用 utf8mb4 而不是 utf8，否则用户发个 emoji 表情就直接插入失败，树洞帖子根本存不进去。

2.3 状态机：从匿名倾诉到付费陪聊的完整流程

状态机是这套源码里最值得花时间理解的部分。我从源码里捋出来的完整流程是这样的：

普通用户进来发#树洞开头的文本，t_post 插入一条 status=0 的帖子，系统回复“已匿名丢进树洞”。陪聊师端（通常是另一个公众号或后台）可以捞取帖子，捞取后 t_post.status 变成 1，同时给用户推送一条客服消息，内容是陪聊师的介绍卡片。用户如果想继续，就进入下单流程，创建 t_order 订单，status=0 待支付，用户点击菜单或链接跳转微信支付。支付成功后微信回调你的 URL 更新订单为 1，这时陪聊师就可以和用户正常对话了，服务结束后订单状态置为 3，陪聊师余额按比例增加。

这个流程里最容易写乱的是订单状态。很多没经验的开发者会把“已支付”和“服务中”合并成一个字段，结果退款时根本没法判断到底退到哪一步。源码里把 status 拆成 0 到 4 五个状态，每个状态对应一个时间点，退款逻辑就只在 status 为 0 或者 1 的时候允许，2 表示服务中要双方协商，这个设计是合理的。

提示：不要把服务状态和支付状态混在一个字段里。支付状态关心的是钱，服务状态关心的是时间，两个维度分开才能扛住售后纠纷。

3. 核心代码实战：消息分发、匿名树洞与支付回调

3.1 消息分发：一个 switch 撑起全部业务

公众号源码没有路由框架，业务分发全靠一个文本命令前缀。我拆到的这套源码在 index.php 里维护了一个 dispatchMessage() 方法，所有从微信过来的消息都先进这里，按 MsgType 分一次，再按 Content 的前缀分一次：

<?php // 消息分发器：所有业务从这里进入 function dispatchMessage($postObj) { $openid = $postObj->FromUserName; $msgType = $postObj->MsgType; $content = trim($postObj->Content ?? ''); // 事件消息单独处理：关注、扫描、点击菜单 if ($msgType === 'event') { $eventKey = $postObj->EventKey ?? ''; return handleEvent($postObj, $openid, $eventKey); } // 文本消息按命令前缀分发 if ($msgType === 'text') { // 中文命令前缀，统一先 urldecode，避免微信部分场景传 URL 编码 $content = urldecode($content); if (mb_strpos($content, '#树洞') === 0) { return publishPost($openid, mb_substr($content, 5, null, 'utf-8')); } if (mb_strpos($content, '#捞') === 0) { return fetchPost($openid); } if (mb_strpos($content, '下单') === 0) { return createOrder($openid, $content); } // 默认走陪聊聊天 return chatMessage($openid, $content); } return replyText($openid, '我只能处理文本消息哦'); }

逻辑说明：事件消息和文本消息分开是微信的硬性要求，event 的报文结构跟 text 不一样，没有 Content 字段，所以必须先判断 MsgType 再往下走。命令前缀这套设计很朴素但很稳，树洞、捞帖子、下单各自是独立函数，出问题互不影响。

参数说明：这里必须用 mb_* 系列函数，mb_substr($content, 5, null, 'utf-8')的 offset 是按字符数算的，“#树洞”加一个空格正好 5 个字符，截出来就是正文。如果换成 PHP 原生的 substr，'#树洞' 在 UTF-8 下占 7 个字节，offset=5 会把“树”字截掉一半，后面做长度判断必挂。这个细节对应避坑章节 5.4，是这种中文命令源码最常见的翻车点。

3.2 匿名树洞：发布、捞取与回复

树洞的核心是匿名。源码里发布帖子的函数只存 openid 不存昵称，对外展示时统一用“树洞用户”加 ID 尾巴，这是保护隐私最基本的一层。发布代码如下：

<?php // 发布树洞帖子 function publishPost($openid, $content) { // 最少 2 个字符，防刷屏 if (mb_strlen($content, 'utf-8') < 2) { return replyText($openid, '多说一点嘛，至少 2 个字'); } // 插入帖子表，openid 只用于后台追溯，前端匿名 $sql = "INSERT INTO t_post (openid, content, create_time, status) VALUES ('$openid', '" . addslashes($content) . "', " . time() . ", 0)"; $db->exec($sql); // 把自增 ID 回给用户，后续可用来被捞取 return replyText($openid, '已匿名丢进树洞 ID:' . $db->lastInsertId() . '，等有缘人来捞'); }

逻辑说明：2 个字的下限判断是防止刷屏，这个阈值可以在 config.php 里改成 5 或者 10。addslashes 是简单转义，生产环境建议改成 PDO 预处理，树洞这种 UGC 场景防注入和防 XSS 一样重要。插入成功后把自增 ID 回给用户，用户后续说“捞 123”，就是捞取这个 ID 的帖子。

捞取的功能在陪聊师端触发。陪聊师发送#捞 123，系统把帖子 status 置为 1，并把陪聊师信息推给发帖用户。这里要注意，捞取不是直接把两个用户拉到一个群里，而是通过微信的客服消息接口给发帖用户推一条带链接的消息，链接指向陪聊师的介绍页，用户点进去决定要不要下单。为什么这么设计？因为直接推送好友名片在微信规范里是受限的，而且用户隐私也保不住。

3.3 陪聊订单：JSAPI 支付与回调验签

这是整套源码含金量最高的部分。微信 JSAPI 支付要求在公众号内通过网页授权拿到用户 openid，然后用 openid 发起统一下单。源码里的创建订单逻辑大致是这样的：

<?php // 创建陪聊订单，统一下单后返回 JSAPI 参数 function createOrder($openid, $duration) { // 1. 组装订单号：日期 + 6 位随机数 $orderSn = date('YmdHis') . rand(100000, 999999); // 2. 按单价计算金额，比如 5 元/分钟 $amount = intval($duration) * 5 * 100; // 单位：分 // 3. 写入待支付订单 $sql = "INSERT INTO t_order (order_sn, openid, amount, status, create_time) VALUES ('$orderSn', '$openid', $amount, 0, " . time() . ")"; $db->exec($sql); // 4. 组装统一下单参数，签名后 POST 到微信支付 $params = [ 'appid' => APPID, 'mch_id' => MCH_ID, 'nonce_str' => generateNonceStr(), 'body' => '陪聊服务', 'out_trade_no' => $orderSn, 'total_fee' => $amount, 'spbill_create_ip' => $_SERVER['REMOTE_ADDR'], 'notify_url' => 'https://你的域名/pay_notify.php', 'trade_type' => 'JSAPI', 'openid' => $openid ]; // 生成支付签名并 POST 到微信 $params['sign'] = makeSign($params, API_KEY); $result = postXml('https://api.mch.weixin.qq.com/pay/unifiedorder', $params); // 5. 返回给前端 JS 用的调起支付参数 return json_encode([ 'order_sn' => $orderSn, 'js_params' => buildJsApiParams($result['prepay_id']) ]); }

逻辑说明：金额在数据库里存的是元，但微信支付接口要求单位是分，intval($duration) * 5 * 100这个乘了 100 的细节最容易漏，漏了就是下单金额差一百倍，属于经典翻车点。out_trade_no 用订单号，回调时靠它反查订单。notify_url 必须是公网 HTTPS 地址，而且域名要有 ICP 备案，否则微信支付平台不会往这个地址推送回调。

回调验签的代码通常写在独立的 pay_notify.php 里，核心是验签和数据一致性：

<?php // 支付结果回调 $xml = file_get_contents('php://input'); $data = json_decode(json_encode(simplexml_load_string($xml, 'SimpleXMLElement', LIBXML_NOCDATA)), true); if ($data['return_code'] !== 'SUCCESS') { // 微信要求：不管成功失败都得回 ACK，否则会一直重推 echo '<xml><return_code><![CDATA[FAIL]]></return_code></xml>'; exit; } // 第一步：校验签名 $sign = $data['sign']; unset($data['sign']); if (makeSign($data, API_KEY) !== $sign) { // 签名不一致，回复 FAIL 让微信重新推送 echo '<xml><return_code><![CDATA[FAIL]]></return_code></xml>'; exit; } // 第二步：校验金额，防篡改 $orderSn = $data['out_trade_no']; $row = queryOrder($orderSn); if ($row && $row['amount'] == $data['total_fee'] && $row['status'] == 0) { // 金额一致且订单未支付，更新状态为已支付 $sql = "UPDATE t_order SET status=1, pay_time=" . time() . " WHERE order_sn='$orderSn'"; $db->exec($sql); } // 第三步：给微信回 SUCCESS ACK echo '<xml><return_code><![CDATA[SUCCESS]]></return_code></xml>'; exit;

参数说明：这里必须两步都通过才更新订单状态——签名校验保证消息来自微信支付，金额校验保证订单号没有被串改。很多人在回调里只验签不校验金额，结果线上被刷单的事常有。还有个细节：如果订单早已是已支付状态，第二次回调过来要直接返回 SUCCESS，不要重复更新，否则会把已开始服务的订单状态覆盖掉。

4. 部署上线：从本地环境到公众号后台

4.1 服务器环境准备：Nginx + PHP + MySQL

这套源码是传统 PHP 项目，不需要 Composer，不需要框架，解压到 Web 目录就能跑。我一般建议的环境是 CentOS 7 或 Ubuntu 20.04 + Nginx 1.18 + PHP 7.4 + MySQL 5.7。PHP 需要装 fileinfo、openssl、pdo_mysql、curl 这几个扩展，用宝塔面板操作的话，安装 PHP 时勾选这几个扩展就行。MySQL 里手动建一个库，导入源码附带的 .sql 文件，再改 config.php 里的数据库连接和公众号参数：

<?php // config.php define('APPID', 'wx你的appid'); // 公众号的 AppID define('APPSECRET', '你的appsecret'); // 公众号的 AppSecret define('TOKEN', '自定义token'); // 与公众号后台一致 define('MCH_ID', '微信支付商户号'); define('API_KEY', '支付API密钥'); define('DB_HOST', '127.0.0.1'); define('DB_NAME', 'treesystem'); define('DB_USER', 'tree_user'); define('DB_PASS', '数据库密码');

这里有个容易被忽略的地方：APPID 和 APPSECRET 是公众号的，MCH_ID 和 API_KEY 是微信支付商户平台的，两者不是一个账号体系，很多人第一次配的时候把商户号填到公众号配置里，导致 access_token 能拿到但支付永远报商户号不存在。如果遇到《链接内容不属于当前公众号》这种提示，多半是公众号主体和网页授权域名对不上，这个放到避坑章节细说。

Nginx 侧需要配置一个 HTTPS 站点，伪静态规则可以按 ThinkPHP 那套写，但更简单的方式是让所有请求都走 index.php：

server { listen 443 ssl; server_name treesystem.cn; ssl_certificate /path/ssl.pem; ssl_certificate_key /path/ssl.key; root /www/wwwroot/treesystem; index index.php; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/tmp/php-cgi-74.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }

这段配置里 try_files 的作用是：如果请求的不是真实文件（比如异常路径），就把请求重写到 index.php，由 PHP 侧再做路由判断。fastcgi_pass 指向的 socket 路径要和你安装的 PHP 版本对应，宝塔默认是 /tmp/php-cgi-74.sock，如果你装的是 8.0，路径就得改成 80 结尾。证书有效期一般是一年，建议在续期提醒里设个日历提醒，不然过期那天整个系统静默挂掉，用户看到的只是公众号无响应。

4.2 公众号后台配置：URL、Token 与消息加解密

Nginx 配好后，公众号后台的配置路径是「设置与开发」→「基本配置」→「服务器配置」。URL 填 https://你的域名/index.php，Token 填 config.php 里的 TOKEN，消息加解密方式选「明文模式」最省事，生产环境再改「安全模式」。点提交时微信会发一个 GET 请求验证你的 URL，这时候就要确保 index.php 能正常响应，如果提示“验证失败”，99% 是签名逻辑或者 Token 不一致。

配置完成后还要做一件事：在公众号后台「IP 白名单」里把服务器的公网 IP 加进去，否则调用微信接口时 access_token 会被拒。这一步是源码教程里最容易漏的，漏了的典型现象是树洞功能能收发消息，但一旦触发获取用户信息或者发送模板消息就报 40164。

4.3 公众号迁移与环境切换：从测试号到认证服务号

很多人先用微信测试号调通源码，测试号的好处是接口权限全开，不用备案也能配，但测试号的 appid 和正式号的完全不一样。切换到正式号时，除了改 config.php 里的 APPID、APPSECRET，还要注意这几个联动项：网页授权域名、JS 接口安全域名、支付授权目录。如果你把源码从一个主体迁移到另一个主体，也就是遇到公众号迁移的情况，原来的 appid 会作废，需要把迁移后的新 appid 全部替换，同时微信支付那边也要重新绑定商户号和公众号的关联关系。

公众号迁移这个操作很多人不知道会连带影响支付：迁移完成后公众号主体变了，JSAPI 支付里 appid 和新主体必须一致，否则调起支付直接报“当前页面 URL 未注册”。我的习惯是每次环境切换后用一张旧的测试单走一遍全流程，确认下单、回调、退款三个环节都能跑通再放量。

注意：测试号能调通的接口，切到正式号不一定全部默认可用，尤其是支付相关权限需要单独申请，不是迁移完就自动带过去。

5. 避坑排查：微信公众号开发的高频翻车现场

5.1 服务器配置验证失败，signature error

现象：在公众号后台点提交服务器配置，微信提示“验证失败”。

原因：最常见的是 Token 不一致，其次是 checkSignature() 里排序方式写错。很多人习惯用 sort($tmpArr) 不传第二个参数，微信要求按字符串排序，如果 token 或时间戳是纯数字，默认排序可能得到不同结果。

解决：把 define('TOKEN', ...) 和后台填写的值逐字符比一遍，然后给 sort 传入 SORT_STRING。改完先在浏览器直接访问 https://你的域名/index.php?signature=xx&timestamp=xx&nonce=xx&echostr=hello 手动验一遍，能回显 hello 再回后台提交。

5.2 链接内容不属于当前公众号

现象：用户点击菜单跳转 H5 页面时，微信提示“链接内容不属于当前公众号”。

原因：公众号的“网页授权域名”只支持配置一个域名，而你的树洞 H5 页面部署在另一个域名上，或者当前访问的 URL 有端口号，微信要求域名完全一致，端口、路径前缀都不能差。另外域名必须完成 ICP 备案并经过微信校验文件验证。

解决：把网页授权域名改成 H5 页面对应的主域名，比如 h5.treesystem.cn，然后下载微信校验文件放到该域名的根目录。发布失败也是同一个套路——如果你用未备案域名做支付跳转页，微信会直接拦截，用户根本到不了下单页。

5.3 支付回调收不到，订单一直是待支付

现象：用户微信里钱已经扣了，但后台订单状态还是待支付。

原因：notify_url 写成了 http 或者域名没备案；或者回调地址返回报错导致微信支付重推失败；还有一种常见情况是回调代码里没有在 return_code 为 SUCCESS 时立即回 ACK，微信认为回调超时。

解决：先看微信支付商户平台的“交易通知”日志，确认通知是否发出以及返回码是什么。代码里必须保证最开头就回应 ACK，即便验签失败也要回应 FAIL 而不是不回应。其次确认服务器公网 IP 能访问 https://你的域名/pay_notify.php，在回调脚本开头写一行 file_put_contents 记录原始报文，是最快的排错方式。

5.4 中文命令前缀截断，树洞发布乱码

现象：用户发 “#树洞 今天好累”，结果系统提示“多说一点嘛，至少 2 个字”。

原因：PHP 的 substr() 按字节截取，“#树洞”在 UTF-8 下是 1 + 3 + 3 = 7 个字节，代码里如果写 substr($content, 5) 就把“树”字截成了半个，后续判断长度自然失败。

解决：所有中文字符串操作统一用 mb_substr($content, $offset, null, 'utf-8')，并且在文件头部声明 mb_internal_encoding('utf-8')。这个坑在 3.1 里已经说过，它就是典型的“本地不回显、线上必炸”的玄学问题，本地用英文内容测不出问题，一上中文必现。

5.5 获取不到用户 openid，一直停在下单页

现象：点下单按钮，JSAPI 调起支付时报“缺少参数 openid”。

原因：网页授权没走通。snsapi_base 静默授权返回 openid 的前提是当前页面 URL 的域名在“网页授权域名”白名单里，而且授权回调地址 code 是一次性的，用两次就会报错。另一个坑是本地调试用内网 IP，微信回调根本无法到达。

解决：检查授权回调地址 redirect_uri 是否做了 urlencode，确认链接不带端口。后端拿到 code 后请求 https://api.weixin.qq.com/sns/oauth2/access_token 换取 openid，这个接口返回的 openid 和消息回调里的 FromUserName 是同一个，但和当前用户的 unionid 不一定相同，不要混用。

6. 进阶：内容安全检测与全流程验证

6.1 接入微信内容安全接口

树洞是 UGC 场景，用户说什么你都拦不住，但微信对公众号的 UGC 内容管控很严，涉政、涉黄、广告引流一旦被举报，轻则接口封禁，重则公众号封号。我拿到任何源码都会先给发布内容加一道微信内容安全检测，用的就是微信官方 msg_sec_check 接口：

<?php // 发布前先过内容安全检测 function checkContent($content, $openid) { $accessToken = getAccessToken(); // 缓存的 access_token $url = "https://api.weixin.qq.com/wxa/msg_sec_check?access_token=" . $accessToken; // 新版接口用 version=2，检测更准 $response = httpPost($url, json_encode([ 'content' => $content, 'version' => 2, 'openid' => $openid ], JSON_UNESCAPED_UNICODE)); $result = json_decode($response, true); // errcode 为 0 表示通过，87014 表示内容违规 return ($result['errcode'] ?? -1) === 0; }

这个接口免费，但需要提前获取并缓存 access_token。我的做法是写一个内存缓存函数，access_token 有效期 7200 秒，每次取的时候先查缓存，过期再请求，避免频繁调用触达频率限制。content 参数直接传用户原文，不要做任何转义，接口内部会做分词和命中规则。发布树洞帖子前先过这道检测，违规内容直接丢弃并提示用户。

6.2 用日志和完整链路验证系统健康度

支付订单还有一个兜底逻辑必须做：待支付订单如果用户一直不付，会在数据库里堆积。我习惯在订单表加一个 expires_time 字段，下单时写入当前时间加 30 分钟，用一个定时任务每分钟扫一次，把超过 expire 且 status=0 的订单置为已关闭状态，这比到了月底看到几百条脏数据再手工清理强得多。

验证系统是否稳定，我有一个固定动作：每周手动下一笔 1 分钟陪聊订单，从下单、支付、回调、服务结束、退款五个环节各走一遍，记录每一步耗时。这套体系的健康度就看订单状态流转有没有卡点，卡在哪里日志里一定有线索。树洞源码最怕的就是业务流程黑匣子化，所以我常态会在入口文件第一行记一条日志，把每次收到微信消息的 MsgType、FromUserName、时间戳写进文件，排查问题时直接 grep 这个文件，比在浏览器里猜快得多。

从这个项目之后我就养成了习惯：每次改配置、改环境，先强制自己走一遍“发布 → 捞取 → 下单 → 支付 → 回调”的完整链路，跑不通就回看日志，直到全流程零手动介入通过再上线。这套陪聊源码本身的逻辑不复杂，复杂的是微信生态的各种审核和外链限制，希望这篇拆解能帮你在部署时少踩几个坑。

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