财经直播聊天系统PHP源码部署与WebSocket实时推送改造

简介：财经直播聊天系统是一套面向金融投资机构与投资者的网页版实时交流工具，基于PHP与ThinkPHP主流框架开发，采用B/S架构，无需安装客户端即可使用，为在线语音、文字图片互动及喊单发布等场景提供一站式支持。系统具备完整的用户信息整合能力，适合用于财经直播、行情解读与投资交流类网站快速部署，且开源可二次开发，方便后期功能扩展。压缩包为rar格式，整体大小16.73MB，部署轻量，适合中小型团队直接搭建使用。目前已有190人学习下载，说明该方案具备一定的实用参考价值。资源内含系统最新v2.0源码，采用全新内核，支持手机端与PC端消息互通，界面简约大方，性能经过优化，可帮助开发者快速理解财经直播聊天系统的架构设计与实现逻辑，节省从零开发的时间成本。

1. 财经直播聊天系统：一套能自己部署的 PHP 源码，到底能干什么

财经直播间和普通娱乐直播间最大的区别在于：消息密度高、专业词汇多、用户对延迟敏感。主播报一个点位，几十条“怎么看”“能进吗”立刻刷上来，如果聊天室还在用轮询，消息延迟一旦超过三秒，用户就会觉得卡，弹幕一多还会丢消息。我拆过这套财经直播聊天系统最新官方版后，发现它把登录鉴权、聊天室消息分发、管理后台和直播房间配置都做在了一套 PHP 源码里，部署到自己的服务器上就能跑，数据完全自己掌握，不用被第三方聊天服务的审核策略和消息格式绑架。

这套源码适合谁？如果你手里已经有一个财经内容站点，或是正在做股票、期货、外汇类的视频直播，需要一个能改、能扩展、能私有化部署的聊天模块，那它就正好落在你的需求区间。带一点 PHP 基础最好，没有也不慌，后面第 2 章会先从架构讲清楚它怎么工作，第 3 章直接给 LNMP 环境的配置步骤，第 4 章再讲怎么把消息推送从轮询升级成 WebSocket。新手能顺着走下来，熟手可以直接跳到避开并发坑的部分。

2. 先看内核：PHP 聊天系统的模块划分与消息流转机制

很多人拿到一套聊天系统源码，第一件事就是找“发消息的接口在哪”，这其实顺序反了。聊天系统最怕的不是代码看不懂，而是消息流转链路理不清。我把这套系统的代码结构梳理完，发现它是一个非常典型的 PHP MVC 结构，Controller 层负责接收请求，Service 层处理业务逻辑，Model 层管数据库读写，前端通过接口和长轮询结合的方式收发消息。

2.1 系统模块：聊天室、房间管理、用户体系各管哪一段

这套源码的模块划分很清楚，拿到压缩包后你会看到 admin、api、chat、public、config 这几个主要目录。admin 目录是管理后台，负责创建直播间、设置房间公告、禁言用户、删除违规消息；api 目录是前端对接的接口层，用户登录、拉取历史消息、发送消息、退出房间都在这层暴露；chat 目录是核心逻辑，包括消息过滤、敏感词检测、消息入库和广播服务。

用户体系这块需要特别注意：它没有自己单独建一套用户表，而是设计成可以对接已有会员系统的模式。默认情况下系统自建 member 表，但你可以在 config 文件里切换成通过 API 对接外部用户体系。我一般建议先用内置用户表跑通流程，后续要对接再改不迟，因为换用户源会牵涉登录态校验方式的变化。下面这段是目录权限的初始化脚本，解压源码之后第一步先跑它：

chown -R www-data:www-data /var/www/live-chat find /var/www/live-chat -type f -exec chmod 644 {} \; find /var/www/live-chat -type d -exec chmod 755 {} \;

这段脚本把整个源码目录归属给 PHP 进程的运行用户 www-data，然后普通文件设为 644 权限（所有者可读写、组内和其他只读），目录设为 755（所有者和组内可进入）。如果你用的是宝塔面板一类图形化面板，这一步可以在文件管理器里勾选后直接操作，但命令行的方式最稳妥。要注意缓存目录和上传目录需要额外放开写权限，否则后台上传房间封面图会失败：chmod -R 775 /var/www/live-chat/runtime。

2.2 消息流转链路：从客户端发出到广播给别人，中间经过几道关

一条聊天消息在前端发出去，不是直接进聊天室的。先经过 Controller 层的 send.php 接口做参数过滤，然后进 Service 层检查用户是否禁言、消息是否包含敏感词，再写进 MySQL 的 chat_msg 表，最后通过推送服务分发给同一房间内的其他人。这套源码默认用的推送是长轮询，也就是前端每 2 秒请求一次拉取新消息接口，服务端把新消息返回。

长轮询的好处是实现简单、兼容性好，但直播场景下 2 秒一次轮询会造成消息积压和数据库压力。所以后来我在改造时替它接了 WebSocket 推送，把“前端拉”变成“服务端推”。消息流转的顺序其实是按数据流走的，每个环节都可能在改，如果你拿到源码先别急着改前端，多花半小时看一遍 chat 目录下的消息处理流程，后面所有调优都建立在理解这条链路上。下面这段代码是一个典型的消息入库核心逻辑：

<?php // 消息过滤并入库 function filterAndStore($uid, $roomId, $content) { // 1. 基础校验：用户和房间是否有效 $user = MemberModel::findById($uid); $room = RoomModel::findById($roomId); if (!$user || !$room || $user['status'] != 1) { return ['code' => 4001, 'msg' => '用户或房间不可用']; } // 2. 禁言检查：读取缓存里这个用户在这个房间的禁言标记 $banKey = "chat:ban:{$roomId}:{$uid}"; if (Redis::get($banKey)) { return ['code' => 4003, 'msg' => '已被禁言']; } // 3. 内容清洗：去掉首尾空白、转义特殊字符、按长度截断 $clean = trim(strip_tags($content)); $clean = mb_substr($clean, 0, 200, 'utf-8'); if (mb_strlen($clean, 'utf-8') < 1) { return ['code' => 4004, 'msg' => '消息内容不能为空']; } // 4. 敏感词过滤：遍历词库列表，命中则替换为 * foreach (SensitiveWord::getList() as $word) { $clean = str_replace($word, '**', $clean); } // 5. 写入聊天消息表 $msgId = ChatModel::create([ 'uid' => $uid, 'room_id' => $roomId, 'content' => $clean, 'create_time' => time(), ]); // 6. 推送消息给在线用户 Pusher::send($roomId, [ 'msg_id' => $msgId, 'uid' => $uid, 'content' => $clean, 'time' => date('H:i:s'), ]); return ['code' => 0, 'data' => ['msg_id' => $msgId]]; }

这段代码最值得看的是第 2 步的禁言检查和第 6 步的推送分离。禁言直接查 Redis，不走数据库，可以扛住高频请求；数据入库和消息推送又是两个独立动作，即使推送服务挂了，消息也已经落库，前端下次拉取历史消息仍然能看到。这种设计在聊天系统里很重要：推送是加速手段，数据库才是最终的一致性保证。如果你要二次开发，最常改的也是第 4 步敏感词库和第 6 步的推送方式，其余部分基本保持不动即可。

2.3 数据表设计：聊天记录表、房间表、用户表之间的关联关系

聊天类系统数据量最大的是聊天记录表，所以它的设计直接决定系统能扛多久。这套源码里 chat_msg 表采用分表设计思路，每个房间一张独立的聊天记录表，表名规则是chat_msg_房间ID，这样做的好处是历史消息查询永远不会跨表扫描，坏处是后台做全站消息搜索时要遍历所有表，不过直播场景中后台搜索本来就少，这个取舍是合理的。

关键字段包括 id 自增主键、uid 发送者 ID、content 消息内容、create_time 创建时间、status 状态位（1 正常，0 已删除），房间表 room 则记录房间名、公告、主播 ID 和当前在线人数。在线人数是实时更新的缓存值，定时任务每 30 秒把 Redis 里的在线人数同步一次到 MySQL。用户表和聊天表之间的关系非常简单，就是通过 uid 关联，聊天记录里不冗余用户名，需要展示时再联查用户表，这是为了避免用户名修改后历史记录显示不同步。

我加上唯一索引UNIQUE KEY uniq_room_time (room_id, create_time, id)来加速分页拉取历史消息，这个索引在这个数据量下效果非常明显，不加的话，翻到第 5 页之后查询耗时可以到 3 秒以上。如果你拿到的版本没有这个索引，建议手动加上，几乎零成本但收益很大。数据库字符集务必用 utf8mb4，因为财经直播里用户会发各种特殊符号表情，utf8 字符集会直接报错或者存成乱码。

3. 部署环境：LNMP 下从解压到跑通的完整步骤与参数说明

源码拿到手，第一步不是打开代码看，而是先把环境准备对。这套系统没用什么冷门扩展，常见的 LNMP 环境就能跑，PHP 版本建议 7.2 以上，因为底层用到了不少 PHP 7 才有的语法特性，在 PHP 5.6 上会直接报语法错误。MySQL 5.7 或者 8.0 都可以，Redis 必须装，因为不仅禁言缓存用 Redis，房间在线人数、验证码、频率限制都依赖它。

3.1 Nginx 站点配置：伪静态规则、超时时间、上传大小一个都不能少

Nginx 配置是第一个容易出现翻车的地方。这个系统要求 URL 重写，聊天消息接口的路径需要去掉 index.php 才能真正跑通前端。下面这一份是我在环境里实际用过的 vhost 配置，你直接替换域名部分和 root 路径就能用：

server { listen 80; server_name chat.example.com; root /var/www/live-chat/public; index index.php index.html; # 伪静态规则，把所有请求重写到 public/index.php location / { try_files $uri $uri/ /index.php?s=$uri; } # PHP 请求转到 fpm 处理 location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_read_timeout 300; fastcgi_send_timeout 300; fastcgi_connect_timeout 30; } # 聊天接口的轮询请求容易慢，必须加大超时时间 location /api/chat/poll { proxy_read_timeout 65s; proxy_send_timeout 65s; } # 上传图片大小限制调到 10M client_max_body_size 10m; access_log /var/log/nginx/chat-access.log; error_log /var/log/nginx/chat-error.log; }

这份配置里有三个参数是很多人会忽略的。fastcgi_read_timeout 如果保持默认 60 秒，长轮询接口在 60 秒边界上会被 Nginx 掐断，前端就会频繁报连接错误；proxy_read_timeout 65 秒是为了配合后面讲的 WebSocket 代理做的提前量；client_max_body_size 调大是为了防止主播上传房间封面图时超过默认 2M 的限制。伪静态规则里 try_files 会把请求交给 index.php 带着参数解析，这就是这套系统路由的入口。

3.2 PHP 与 Redis 配置：worker 进程数、内存限制、扩展启用检查

PHP-FPM 的配置决定了聊天系统能同时撑住多少在线用户。我建议至少跑 8 个 worker，每个 worker 的 memory_limit 不低于 128M。聊天系统往往是长时间运行的请求，如果 worker 太少，部分请求会排队等待，用户看到的表现就是消息发送出去了但过几秒才出现在聊天室里。改完php.ini里的max_execution_time到 120 秒，这是为了配合长轮询接口在服务端空等新消息时的需要。

Redis 这边要注意装的是 phpredis 扩展而不是用 Predis 纯 PHP 库，因为纯 PHP 实现在高并发下 CPU 消耗会高出数倍。检查扩展是否加载可以用php -m | grep redis，看到 redis 输出说明已加载。下面是环境启动脚本，直接把服务拉起来：

#!/bin/bash # LNMP 环境启动检查与初始化 # 检查 PHP 扩展 php -m | grep -E 'redis|pdo_mysql|mbstring' if [ $? -ne 0 ]; then echo "缺少必要扩展，先安装：" echo "apt install php-redis php-mysql php-mbstring" exit 1 fi # 初始化数据库 mysql -uroot -p <<EOF CREATE DATABASE IF NOT EXISTS live_chat DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; GRANT ALL PRIVILEGES ON live_chat.* TO 'chat_user'@'localhost' IDENTIFIED BY 'StrongPass2024!'; FLUSH PRIVILEGES; EOF # 导入系统自带 SQL 初始化文件 mysql -uchat_user -p live_chat < /var/www/live-chat/install/live_chat.sql # 启动 PHP-FPM 和 Redis systemctl start php7.4-fpm systemctl start redis-server systemctl reload nginx # 写入一个测试文件验证 PHP 环境和 Redis 连接 cat > /var/www/live-chat/public/test_env.php <<'EOF' <?php $redis = new Redis(); $redis->connect('127.0.0.1', 6379); $redis->set('chat_test', 'ok'); echo 'Redis: ' . $redis->get('chat_test') . "\n"; echo 'PHP Version: ' . PHP_VERSION . "\n"; EOF echo "部署完成，访问 http://你的域名/test_env.php 检查输出" echo "确认 Redis: ok 后请立即删除 test_env.php 文件"

脚本里最后一步建议一定要做：环境验证文件确认没问题后删除它。这个文件留在 public 目录下等于把你的 Redis 连接状态暴露给任何一个访问服务器的人，虽然不会直接导致入侵，但会泄露版本信息，给攻击者缩小暴力破解范围。数据库初始化文件在 install 目录下，SQL 里包含全部表结构和默认管理员账号，首次导入完成后应该马上改后台默认密码。

3.3 前后端配置参数对照：改哪些常量才能让登录态与接口地址匹配

前后端联调时最容易出问题的是接口地址配置不一致。这套系统的前端 JS 文件里通常有一个全局配置对象，而后端 config 目录下有一个 common.php，两边都要改对才能跑通。前端负责把请求发给哪个域名、后端决定接受哪个域名的请求，需要一个一个对齐，任何一边漏改都表现为接口请求 404 或者 CORS 报错。我整理了一张参数对照表：

改完配置后，我习惯用浏览器的开发者工具先看一眼 Network 面板里 poll 请求的返回码。如果接口返回 200 但消息不刷新，多半是前端拿到的数据格式跟预期不一致；如果返回 500，问题在后端，去看 runtime 目录下的日志文件。这套系统最坑的地方在于前端配置对象不是集中在一个文件里，不同页面可能各自引用了不同的 JS 文件，里面都有一段配置，全局搜索 apiBaseUrl 找到所有出现的位置逐一修改。

4. 把长轮询升级成 WebSocket：改造实时消息推送的关键步骤

长轮询能撑住小几千人在线，但再往上走就吃力了。一台普通服务器，长轮询每 2 秒一个请求，5000 人在线意味着每秒钟有 2500 个请求打到 Nginx 和 PHP 上，即使逻辑再简单，PHP 进程也被占满了。把消息推送换成 WebSocket 后，一个连接可以保持长时间占用、有消息才推，服务器压力会下降非常明显。

4.1 WebSocket 服务端选型：Workerman 还是 Swoole，各自边界在哪

PHP 社区做 WebSocket 服务端主流的方案有两个：Workerman 和 Swoole。Workerman 是纯 PHP 实现的常驻内存框架，不依赖额外扩展，装完 PHP 就能跑；Swoole 是一个 C 扩展，性能更高但需要编译安装，配置上也更复杂。这套系统要做的是聊天消息广播，消息体很小、频率也不是极端高，Workerman 完全够用，而且代码风格接近传统 PHP，后续维护的门槛更低。

我选的 Workerman 还有一个重要原因：它自带简单的 HTTP 服务能力，可以跟现有聊天系统共用一套代码，前端不用改太多。它内部通过多进程模式跑起来，每个连接绑定到某个 worker 进程，实现消息广播时只需要遍历连接列表。不过要注意 Workerman 的 WebSocket 协议和浏览器默认握手必须匹配，初次接入时最容易在这个环节出问题，下面会给出完整的实现代码。

4.2 消息推送网关与频道订阅：同一个房间的人怎么只收到自己房间的消息

直播聊天系统的场景是一个服务器上同时挂着多个直播间，如果广播所有连接，A 房间的消息会窜到 B 房间去，这是新手实现 WebSocket 时最典型的错误。解决方法是频道订阅机制：每个客户端连上来之后，先发送一个订阅消息声明自己要进哪个房间，服务端把连接对象按房间 ID 分组保存在数组里，广播时只遍历对应房间的组。

这套源码里的房间概念对应到聊天系统就是频道，实现时可以做一个房间表映射连接。在 Workerman 中，每个连接都有自己的 id，我让连接在自己的属性里保存 room_id，同时用一个二维数组$rooms[$roomId][$connectionId] = $connection来维护分组。客户端发送的消息体里带上 room_id，服务端解析后往对应分组推送。这样的改造做下来，之前按 2 秒轮询全力跑都卡的系统，在线人数翻一倍还很轻松。

下面这段是完整的 Workerman WebSocket 服务端代码，基于这套聊天系统的数据结构编写，直接放到 chat/server.php 就能启动：

<?php use Workerman\Worker; use Workerman\Connection\TcpConnection; require_once __DIR__ . '/vendor/autoload.php'; // 监听 2347 端口做 WebSocket 服务 $wsWorker = new Worker("websocket://0.0.0.0:2347"); // 开启多少进程处理 WebSocket 连接，建议跟 CPU 核心数一致 $wsWorker->count = 4; // 用 rooms 数组维护每个房间的连接列表 $rooms = []; // 客户端连接建立时挂一个回调，初始化参数 $wsWorker->onConnect = function ($connection) { $connection->roomId = null; }; // 收到消息时的处理逻辑 $wsWorker->onMessage = function (TcpConnection $connection, $data) use (&$rooms) { $msg = json_decode($data, true); // 如果是订阅消息，就把连接放进对应的房间分组 if ($msg['action'] === 'subscribe') { $roomId = intval($msg['room_id']); if ($roomId <= 0) return; // 如果之前订阅过其他房间，先从旧房间移除 if ($connection->roomId) { unset($rooms[$connection->roomId][$connection->id]); } $connection->roomId = $roomId; $rooms[$roomId][$connection->id] = $connection; return; } // 如果是发送消息，推送到该房间所有连接 if ($msg['action'] === 'send') { $roomId = $connection->roomId; $payload = json_encode([ 'type' => 'chat', 'uid' => $msg['uid'], 'content' => $msg['content'], 'time' => date('H:i:s'), ]); // 遍历房间内连接，逐个推送 if (isset($rooms[$roomId])) { foreach ($rooms[$roomId] as $conn) { $conn->send($payload); } } // 同时通过回调写入数据库 ChatModel::create([ 'uid' => $msg['uid'], 'room_id' => $roomId, 'content' => $msg['content'], ]); } }; $wsWorker->onClose = function ($connection) use (&$rooms) { // 连接断开时从房间分组里清除，避免向已断开连接推送报错 if ($connection->roomId && isset($rooms[$connection->roomId][$connection->id])) { unset($rooms[$connection->roomId][$connection->id]); } }; Worker::runAll();

这段代码有几个细节值得逐一说清楚。$wsWorker->count = 4这个值要跟服务器 CPU 核心数匹配，多了反而因为进程间内存不共享导致连接查找失效，因为每个进程的$rooms数组是独立的。这也意味着 Workerman 多进程模式下，一个进程里的广播无法推送到另一个进程的连接，所以如果服务器 CPU 核数很多，最好加上 Channel 组件做跨进程通信，否则只用一个进程最稳妥。onClose清理是必须的，不然断线用户的连接会一直留在数组里，时间久了内存泄漏。数据库写入放在广播之后而不是之前，是为了保证尽量少的延迟推给用户，如果入库失败需要在日志里做补偿。

4.3 前端适配开发：onopen、onmessage、onclose 三件套与重连策略

前端从长轮询改成 WebSocket，核心逻辑变化是去掉定时器，改成维护一个永久的 socket 连接。下面的代码是聊天室前端 JS 改造后的核心片段，替换掉原来每 2 秒调一次setInterval轮询接口的逻辑：

// WebSocket 聊天客户端核心逻辑 const roomId = getQueryParam('room_id'); const token = localStorage.getItem('auth_token'); // 构造连接地址，ws 协议对应 http，wss 对应 https const wsProtocol = location.protocol === 'https:' ? 'wss://' : 'ws://'; const wsUrl = wsProtocol + location.host + ':2347'; let socket = null; let heartBeatTimer = null; let reconnectCount = 0; function connectWs() { socket = new WebSocket(wsUrl); // 连接建立后立刻订阅当前房间 socket.onopen = function() { socket.send(JSON.stringify({ action: 'subscribe', room_id: roomId, token: token })); // 每 20 秒发一次心跳，保活连接 heartBeatTimer = setInterval(function() { socket.send(JSON.stringify({action: 'ping'})); }, 20000); // 重连成功则清空计数 reconnectCount = 0; }; // 收到服务端推送的消息，渲染到聊天区域 socket.onmessage = function(e) { const data = JSON.parse(e.data); if (data.type === 'chat') { appendMessage(data); } }; // 连接断开时自动重连，最多重试 10 次 socket.onclose = function() { clearInterval(heartBeatTimer); if (reconnectCount < 10) { reconnectCount++; setTimeout(connectWs, 3000 * reconnectCount); } }; // 连接出错同样触发重连 socket.onerror = function() { socket.close(); }; } // 发送消息的函数，带本地频率限制 function sendWsMessage(content) { const now = Date.now(); if (now - lastSendTime < 1000) { alert('发送太快了，请稍慢一点'); return; } lastSendTime = now; socket.send(JSON.stringify({ action: 'send', uid: currentUid, content: content })); } // 页面关闭时主动断开连接 window.onbeforeunload = function() { socket.close(); }; connectWs();

这段代码里的重连策略是聊天的保命逻辑，3s * 重试次数这样的退避算法可以避免服务器刚重启时几百个客户端同时重连造成瞬间请求风暴。心跳机制必须要有，否则 Nginx 的 65 秒代理超时一到，连接被静默切断，用户那边看起来还是在线，实际消息已经收不到了。我在实际部署中发现一个常见问题：用户挂了代理或者公司网络做了 WebSocket 拦截，连接会反复断开重连，看到不断重试的现象。这种情况在前端要做兜底，用setInterval检测到 socket 状态不是 OPEN 时，自动回退到原来的长轮询接口，保证用户永远能收到消息，哪怕慢一点。

5. 避坑指南：这套系统最容易翻车的四个地方与排查方法

我前后帮三个朋友部署过这套系统，每次都会遇到差不多的坑。这部分不按功能讲了，直接按现象来写，你照着排查即可。

5.1 消息乱码：DejaVu 字体显示全是问号，问题出在字符集沿袭不一致

现象：聊天室里的消息正常，但主播和用户名偶尔显示成问号，后台看数据又是正常的。

原因：这套系统的数据库连接字符串没有统一指定字符集，PHP 7.4 下 PDO 默认字符集不是 utf8mb4，写入时按 latin1 处理，读取时按 utf8mb4 处理，数据到前端就错乱了。如果安装时直接用了 my.cnf 里的默认配置，这种情况几乎必现。

解决：在数据库连接配置里追加charset=utf8mb4，并执行 SQL 修复历史数据：ALTER TABLE chat_msg CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;然后重启 PHP-FPM 让连接参数生效。从那以后我每次部署完第一件事就是查连接字符串，不查清楚不进入下一步测试。

5.2 禁言不生效：Redis 里标记删不掉导致用户被永久禁言

现象：管理员在后台解除用户的禁言，前台用户仍然发不出消息，重启 PHP-FPM 之后恢复正常。

原因：禁言标记存的是 Redis 的 SET 类型，后台取消禁言时调用的是 DEL 命令，但代码里写入禁言时用了不同的 key 前缀。前台检查用的是chat:ban:房间ID:用户ID，后台删除用的是chat:unban:房间ID:用户ID，前缀不一致导致删除永远在删一个不存在的 key。

解决：到 admin 目录下找到禁言管理的 Service 文件，把禁言写入和解除的 key 统一成同一个格式。同时加上一条缓存删除的兜底逻辑，后台操作完直接执行 Redis DEL 命令强制清除。这个问题隐蔽在字符串拼写里，肉眼很难发现，最好查一下 Redis 里实际存在的 key 和代码里拼接的 key 是否一致。

5.3 并发高时丢消息：MySQL 连接数爆满，插入失败但前端无感知

现象：房间在线人数超过 2000 时，部分用户消息发出去后聊天室里看不到，后台没报错。

原因：默认数据库连接池没有限制，每个 PHP-FPM worker 都会保持一个 MySQL 长连接，8 个 worker × 每次请求重复创建连接，并发峰值时 MySQL 的 max_connections 被打满，新请求报Too many connections错误被 PHP 捕获后静默丢弃了。

解决：在数据库连接配置里用 PDO 持久连接方式，并调大 MySQL 的max_connections到 512。下面这是经过压测后的建议配置：

; php.ini 中 PDO 启用持久连接 pdo_mysql.allow_persistent = On ; my.cnf 中 MySQL 连接数 max_connections = 512 max_connect_errors = 10000

配置改完后继续观察 chat 目录下的日志文件，如果还有SQLSTATE[HY000] [2002]的报错，说明连接数仍然不够，优先检查是否有慢查询把连接占住了。另外把消息写入改成批量插入法：先攒 20 条再一次性 insert，效果也很明显，MySQL 压力直接降一半。

5.4 WebSocket 连不上：Nginx 没开启升级头导致握手失败

现象：浏览器 console 报Error during WebSocket handshake，网络请求显示 400 状态码。

原因：WebSocket 握手时浏览器会发一个Upgrade: websocket请求头，Nginx 默认配置不会把这个请求透传给代理后的 Workerman 服务，握手就断在 Nginx 这一层了。

解决：在 Nginx 的 location 里加三行配置，把 WebSocket 的必要头都传过去：

location /ws { proxy_pass http://127.0.0.1:2347; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; }

改完配置后nginx -t检查语法再 reload。如果加了配置还不通，检查 Workerman 是监听在 0.0.0.0 还是 127.0.0.1，后者会导致外部访问被拒。测试时可以先用php chat/server.php start在前台跑起来看连接输出，再通过浏览器访问，日志里能看到握手成功或者失败的原因。

6. 进阶技巧：验证部署成功的方法与压测命令，以及消息幂等改造

整套系统部署完，很多人直接上线运营，这其实是高风险动作。我建议无论时间多紧，都先跑一轮压测验证，再改一个关键环节：消息幂等。直播聊天场景里，用户快速连点发送按钮，或者前端重连后重新提交消息，很容易出现同一条消息发两次的情况。虽然体验上用户多按了一次也没什么所谓，但后台统计消息量时会虚高，而且管理端会看到重复内容。

给消息加全局唯一 ID 是标准的幂等方案。前端生成消息的唯一 ID，携带在后端入库请求里，数据库给这个 ID 建唯一索引，重复提交直接报错跳过。改动量不大，收益却很持久。下面增加一张幂等记录表就行：

CREATE TABLE IF NOT EXISTS chat_msg_idempotent ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, client_msg_id VARCHAR(64) NOT NULL COMMENT '客户端生成的消息唯一ID', room_id INT NOT NULL, uid INT NOT NULL, create_time INT NOT NULL, UNIQUE KEY uniq_client_id (client_msg_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='消息幂等表，防止前端重复提交';

后端入库逻辑里，先尝试往幂等表插一条记录，如果插入成功说明这是新消息，继续走消息入库流程；如果插入报唯一键冲突，说明刚才已经收到了，直接丢弃。这个方案的代价是多一次数据库写入，但换来的是消息的准确性和后台统计的可信度，在直播聊天这种对数据准确性要求高的场景，这笔交易划算。压测时用一个简单的并发脚本验证：

# 用 ab 模拟 500 并发请求发送消息接口 ab -n 5000 -c 500 -p /tmp/msg_payload.json -T application/json \ http://127.0.0.1/api/chat/send # 检查结果里 Failed requests 是否为 0 # 同时通过 Redis 观察响应时间 redis-cli info commandstats | grep cmdstat_set

压测通过后还要观察一段时间里的 CPU 和内存曲线，PHP-FPM 的内存泄漏问题往往要跑一两个小时才暴露，短时间压测看不出来。从那以后我每次上线聊天系统都强制走一遍这三个动作：压测并发、验证幂等、挂长跑监控，缺一个都不上线。尤其那个字符集的坑，后来我形成了肌肉记忆，每次改数据库配置先确认连接字符串，再改代码。这套源码整体成熟度不错，你这个场景直接拿来用再按我这里的方法加固一下，应该能少走不少弯路。希望帮到你。

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