简介这是一套基于PHP与WebSocket技术构建的全开源H5聊天室源码面向需要为网站或应用快速集成即时通讯功能的开发者尤其适合具备一定PHP基础、希望深入理解实时通信原理的中级学习者。资源包共19个文件约1.5MB以9个PHP核心脚本为主涵盖WebSocket服务端、用户与消息模型、上传及校验逻辑另含4个SQL脚本与1个db数据库文件用于数据存储配合CSS、JS与PNG完成前端界面并附搭建文档与README说明。源码同时支持数据库与无数据库两种运行模式开发者可依据场景灵活选择并自由查看、修改代码进行功能扩展与界面定制。目前已有126人学习下载借助开源社区经验可加速排错与二次开发是搭建轻量级实时聊天室的实用参考。1. 一套 PHP 全开源聊天室源码到底能扛住多少人同时在线很多团队第一次接触 PHP 全开源聊天室源码都是被全开源三个字吸引代码能改、能部署、能接自己的用户体系看起来比买一套 SaaS 聊天服务划算得多。但真正上线后才发现H5 聊天室源码能不能跑起来是一回事实时消息聊天源码能不能在几百人同时发言时不丢消息、不乱序、不把 MySQL 打满是另一回事。我见过太多项目卡在本地两个人对聊没问题一上压力测试就雪崩这一步。这套东西的本质是一个用 PHP 做业务后端、用 WebSocket 或轮询做消息通道、用 H5 页面做前端的轻量实时通信系统。它适合中小型社群、内部客服、在线教育答疑、活动直播间这类场景——并发量在几百到几千、消息不需要永久强一致、预算有限。如果你要做的是百万级 IM那这套架构从第一天就该放弃别硬撑。下面我按能跑通 → 能扛压 → 不翻车的顺序把选型、部署、参数和坑一条条讲清楚。2. 先想清楚消息通道怎么选轮询、长轮询还是 WebSocket2.1 三种通道的真实成本对比PHP 全开源聊天室源码在市面上主要分两派一派是纯 PHP Ajax 轮询另一派是 PHP 业务层 独立 WebSocket 进程常见是 Workerman 或 Swoole。轮询派的代码最简单一个messages.php接口加个setInterval就能跑但它对服务器的伤害是线性的——1000 人在线、每 2 秒轮询一次就是每秒 500 个请求PHP-FPM 进程瞬间被占满。长轮询Comet是折中方案客户端发一个请求服务端 hold 住最多 30 秒有新消息立刻返回。它比短轮询省 80% 以上的无效请求但每个挂起连接都占一个 PHP-FPM workerpm.max_children设成 50 就只能撑 50 个并发挂起这是硬上限。WebSocket 才是实时消息聊天源码该有的样子。连接建立后是长连接服务端主动推送一个进程用事件循环能扛几千连接。代价是你得额外维护一个常驻进程还要处理进程守护、断线重连、心跳保活。通道类型单机并发上限消息延迟服务器成本代码复杂度短轮询约 200 在线1-3 秒高CPU 密集低长轮询约 500 在线0.5-1 秒中中WebSocket3000 在线50-200 毫秒低内存换 CPU高2.2 用 Workerman 起一个最小可用的 WebSocket 服务我一般会选 Workerman因为它纯 PHP 实现、不依赖扩展、文档够用部署时不用折腾编译。下面是一个能直接跑的最小服务端骨架?php // chat_server.php —— 最小 WebSocket 聊天服务 require_once __DIR__ . /vendor/autoload.php; use Workerman\Worker; use Workerman\Connection\TcpConnection; $ws new Worker(websocket://0.0.0.0:8282); $ws-count 4; // 启动 4 个进程按 CPU 核数调整 $ws-name chat-server; // 用内存表存连接ID 用户信息跨进程共享 $globalUidMap new \Workerman\Protocols\Http\Request(); // 占位实际用 GlobalData $ws-onConnect function (TcpConnection $conn) { $conn-uid null; // 未登录状态 $conn-lastHeartbeat time(); }; $ws-onMessage function (TcpConnection $conn, $data) use ($ws) { $msg json_decode($data, true); if (!$msg || !isset($msg[type])) { return; } switch ($msg[type]) { case login: // 简化示例真实项目必须校验 token $conn-uid (int)$msg[uid]; $conn-send(json_encode([type login_ok, uid $conn-uid])); break; case heartbeat: $conn-lastHeartbeat time(); $conn-send(json_encode([type pong])); break; case chat: // 广播给所有连接生产环境要按房间过滤 $payload json_encode([ type chat, from $conn-uid, content mb_substr($msg[content], 0, 500), ts time(), ]); foreach ($ws-connections as $client) { if ($client-uid ! null) { $client-send($payload); } } break; } }; $ws-onClose function (TcpConnection $conn) { // 清理在线状态真实项目要写回 Redis }; Worker::runAll();这段代码的逻辑很直白onConnect初始化连接状态onMessage按消息类型分发chat类型做广播。几个关键参数必须说清楚$ws-count 4表示开 4 个 worker 进程一般设成 CPU 核数设太多反而增加进程切换开销mb_substr($msg[content], 0, 500)是内容截断防止有人发超长文本把广播包撑爆$conn-lastHeartbeat配合定时器做死连接清理否则断网的客户端会一直占着连接。启动命令就一行php chat_server.php start -d-d是守护模式。调试时去掉-d能看到实时日志。要停就php chat_server.php stop。2.3 前端 H5 怎么接断线重连是必修课H5 聊天室源码的前端部分核心不是 UI是连接管理。移动端切后台、切网络、锁屏都会断连没有重连逻辑的聊天室等于不可用。// chat_client.js —— 带指数退避重连的 WebSocket 客户端 class ChatClient { constructor(url) { this.url url; this.ws null; this.retry 0; this.maxRetry 10; this.heartbeatTimer null; this.connect(); } connect() { this.ws new WebSocket(this.url); this.ws.onopen () { this.retry 0; // 连上就重置退避计数 this.startHeartbeat(); this.send({ type: login, uid: this.uid }); }; this.ws.onmessage (e) { const msg JSON.parse(e.data); if (msg.type pong) return; // 心跳响应不往上抛 this.onMessage this.onMessage(msg); }; this.ws.onclose () { this.stopHeartbeat(); if (this.retry this.maxRetry) { // 指数退避1s, 2s, 4s, 8s... 最多 30s const delay Math.min(1000 * Math.pow(2, this.retry), 30000); this.retry; setTimeout(() this.connect(), delay); } }; } startHeartbeat() { this.heartbeatTimer setInterval(() { this.send({ type: heartbeat }); }, 25000); // 25 秒一次小于服务端 60 秒超时 } stopHeartbeat() { clearInterval(this.heartbeatTimer); } send(obj) { if (this.ws this.ws.readyState WebSocket.OPEN) { this.ws.send(JSON.stringify(obj)); } } }重连用指数退避而不是固定间隔是为了避免服务端刚重启时被所有客户端同时冲击。心跳间隔 25 秒是经验值服务端一般设 60 秒无心跳就断开客户端留一半余量网络抖动一次不至于被误杀。this.retry 0在onopen里重置保证连上后下次断线还是从 1 秒开始退避。3. 把消息落库和广播拆开MySQL 只存历史Redis 管在线3.1 为什么不能每条消息都同步写 MySQL新手最容易犯的错是在onMessage里直接INSERT INTO messages。1000 人在线、每人每分钟发 2 条就是每秒 33 次写入MySQL 单表还能扛但一旦有人刷屏或者广播逻辑里还带着查询数据库连接池立刻见底。实时消息聊天源码的性能瓶颈90% 出在广播路径上做了同步 IO。正确做法是分层Redis 负责在线状态和最近消息MySQL 只做异步落库。广播走内存落库走队列。3.2 用 Redis 维护在线列表和房间成员?php // presence.php —— 在线状态管理 $redis new \Redis(); $redis-connect(127.0.0.1, 6379); $redis-select(1); // 用户上线加入房间集合设置 90 秒过期 function userOnline($redis, $roomId, $uid) { $key room:{$roomId}:online; $redis-sAdd($key, $uid); $redis-expire($key, 90); // 靠心跳续期不续就自动清 $redis-setex(user:{$uid}:room, 90, $roomId); } // 心跳续期 function heartbeat($redis, $roomId, $uid) { $redis-expire(room:{$roomId}:online, 90); $redis-expire(user:{$uid}:room, 90); } // 取房间在线人数 function onlineCount($redis, $roomId) { return $redis-sCard(room:{$roomId}:online); }用 Redis 集合而不是 MySQL 表来存在线状态是因为集合的增删是 O(1)而且expire能自动清理僵尸用户——用户断网没发离线通知时90 秒后自动从在线列表消失。这个 90 秒要和客户端心跳间隔配合客户端 25 秒发一次心跳服务端每次心跳都续期三次心跳没到就判定离线容错够用。3.3 消息异步落库用 Redis List 做缓冲队列?php // 广播时只推 Redis不碰 MySQL $redis-lPush(chat:msg:queue, json_encode([ room_id $roomId, uid $uid, content $content, ts time(), ])); // 独立的落库脚本用 crontab 或常驻进程消费 // persist_worker.php while (true) { $item $redis-brPop(chat:msg:queue, 5); // 阻塞 5 秒 if (!$item) continue; $msg json_decode($item[1], true); $stmt $pdo-prepare( INSERT INTO messages (room_id, uid, content, created_at) VALUES (?, ?, ?, ?) ); $stmt-execute([$msg[room_id], $msg[uid], $msg[content], $msg[ts]]); }brPop的第二个参数是阻塞超时设 5 秒是为了让脚本有机会检查退出信号不至于卡死。落库脚本单独跑广播路径上就只剩一次lPush耗时在毫秒级。MySQL 表建议按room_id加索引并且定期归档——聊天记录表是增长最快的表不做归档半年就能到千万行。提示messages表如果只用于历史查询可以考虑按月分表或者干脆把超过 30 天的记录转到冷存储主表只留近期数据。4. 避坑PHP 聊天室上线后最容易翻车的 5 个地方4.1 现象消息偶尔丢用户说我发的别人看不到原因通常是广播时遍历$ws-connections的过程中有连接正好断开send()抛异常中断了整个循环后面的用户就没收到。解决是把每个send包在 try-catch 里或者先收集连接列表再逐个发$clients []; foreach ($ws-connections as $client) { if ($client-uid ! null) $clients[] $client; } foreach ($clients as $client) { try { $client-send($payload); } catch (\Throwable $e) { /* 忽略单点失败 */ } }4.2 现象服务跑几天就内存暴涨最后被 OOM 杀掉原因是连接对象或消息缓存没释放。Workerman 里如果自己维护了全局数组存用户数据用户断开时忘了unset数组只增不减。血泪经验任何以连接为 key 的全局结构都必须在onClose里清理。另外$ws-connections是框架自己管的别手动去改它。4.3 现象移动端切回前台后收不到消息要刷新页面原因是浏览器切后台会冻结 WebSocket切回来时连接已经死了但readyState还没更新。解决是监听visibilitychange事件切回前台时主动检查连接状态不是 OPEN 就立即重连别等onclose触发document.addEventListener(visibilitychange, () { if (!document.hidden this.ws.readyState ! WebSocket.OPEN) { this.retry 0; this.connect(); } });4.4 现象同一用户开两个标签页消息重复显示原因是服务端按连接广播两个标签页是两个连接各自都收到。如果业务上要按用户去重得在服务端维护uid [连接列表]的映射广播时按 uid 去重只发最新连接或者前端按消息 ID 去重。我一般选前端去重服务端逻辑简单代价是浪费一点带宽。4.5 现象Nginx 反代后 WebSocket 连不上一直 400原因是 Nginx 默认不转发 Upgrade 头。必须在 location 里显式配置location /ws { proxy_pass http://127.0.0.1:8282; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_read_timeout 120s; # 要大于心跳间隔否则会被 Nginx 掐断 }proxy_read_timeout默认 60 秒如果心跳是 25 秒一次没问题但如果客户端网络差导致心跳延迟60 秒就可能被 Nginx 主动断开。设成 120 秒留足余量。5. 压测与调优怎么验证你的聊天室真能扛住 1000 人在线5.1 用脚本模拟并发连接先测连接数再测消息吞吐不要一上来就压消息先确认服务能稳定维持多少连接。用 Node.js 写个压测脚本最省事// bench.js —— 模拟 N 个 WebSocket 连接 const WebSocket require(ws); const N 1000; const URL ws://127.0.0.1:8282; let connected 0; const clients []; for (let i 0; i N; i) { const ws new WebSocket(URL); ws.on(open, () { connected; ws.send(JSON.stringify({ type: login, uid: i 1 })); if (connected N) { console.log(全部 ${N} 个连接建立完成); startChat(); } }); ws.on(message, () { /* 消费消息防止缓冲区堆积 */ }); ws.on(error, (e) console.error(连接 ${i} 出错:, e.message)); clients.push(ws); } function startChat() { // 每秒让 10% 的客户端发一条消息 setInterval(() { const idx Math.floor(Math.random() * N); clients[idx].send(JSON.stringify({ type: chat, content: 压测消息 Date.now(), })); }, 100); }跑之前先调ulimit -n 65535否则单机文件描述符上限会卡在 1024连到 1000 就报EMFILE。观察指标服务端内存增长是否平稳、CPU 是否单核跑满、消息从发出到广播回来的延迟。如果 CPU 单核跑满说明 worker 数不够或者广播逻辑太重先加count再考虑把广播拆到独立进程。5.2 三个必须调的参数参数位置建议值说明$ws-count服务端CPU 核数超过核数收益递减心跳间隔客户端25 秒服务端超时设 60 秒proxy_read_timeoutNginx120 秒必须大于心跳间隔pm.max_childrenPHP-FPM按内存算仅轮询方案需要5.3 一个我常用来验证消息不丢的技巧在压测脚本里给每条消息带一个自增序号客户端收到后记录最大连续序号跑 10 分钟后检查有没有断号。断号说明广播路径上有异常被吞了回去查 4.1 那个 try-catch。这个方法比看日志快得多因为日志在高并发下本身就可能丢。我自己的习惯是任何聊天室上线前先用 500 连接跑 30 分钟再用 1000 连接跑 10 分钟两轮都不断号、内存不涨才敢放真实用户进来。这套 PHP 全开源聊天室源码的价值不在于代码多漂亮而在于你能不能在它翻车之前把上面这些参数和坑都摸清楚。希望帮到你。本文还有配套的精品资源点击获取
简介这是一套基于PHP与WebSocket技术构建的全开源H5聊天室源码面向需要为网站或应用快速集成即时通讯功能的开发者尤其适合具备一定PHP基础、希望深入理解实时通信原理的中级学习者。资源包共19个文件约1.5MB以9个PHP核心脚本为主涵盖WebSocket服务端、用户与消息模型、上传及校验逻辑另含4个SQL脚本与1个db数据库文件用于数据存储配合CSS、JS与PNG完成前端界面并附搭建文档与README说明。源码同时支持数据库与无数据库两种运行模式开发者可依据场景灵活选择并自由查看、修改代码进行功能扩展与界面定制。目前已有126人学习下载借助开源社区经验可加速排错与二次开发是搭建轻量级实时聊天室的实用参考。1. 一套 PHP 全开源聊天室源码到底能扛住多少人同时在线很多团队第一次接触 PHP 全开源聊天室源码都是被全开源三个字吸引代码能改、能部署、能接自己的用户体系看起来比买一套 SaaS 聊天服务划算得多。但真正上线后才发现H5 聊天室源码能不能跑起来是一回事实时消息聊天源码能不能在几百人同时发言时不丢消息、不乱序、不把 MySQL 打满是另一回事。我见过太多项目卡在本地两个人对聊没问题一上压力测试就雪崩这一步。这套东西的本质是一个用 PHP 做业务后端、用 WebSocket 或轮询做消息通道、用 H5 页面做前端的轻量实时通信系统。它适合中小型社群、内部客服、在线教育答疑、活动直播间这类场景——并发量在几百到几千、消息不需要永久强一致、预算有限。如果你要做的是百万级 IM那这套架构从第一天就该放弃别硬撑。下面我按能跑通 → 能扛压 → 不翻车的顺序把选型、部署、参数和坑一条条讲清楚。2. 先想清楚消息通道怎么选轮询、长轮询还是 WebSocket2.1 三种通道的真实成本对比PHP 全开源聊天室源码在市面上主要分两派一派是纯 PHP Ajax 轮询另一派是 PHP 业务层 独立 WebSocket 进程常见是 Workerman 或 Swoole。轮询派的代码最简单一个messages.php接口加个setInterval就能跑但它对服务器的伤害是线性的——1000 人在线、每 2 秒轮询一次就是每秒 500 个请求PHP-FPM 进程瞬间被占满。长轮询Comet是折中方案客户端发一个请求服务端 hold 住最多 30 秒有新消息立刻返回。它比短轮询省 80% 以上的无效请求但每个挂起连接都占一个 PHP-FPM workerpm.max_children设成 50 就只能撑 50 个并发挂起这是硬上限。WebSocket 才是实时消息聊天源码该有的样子。连接建立后是长连接服务端主动推送一个进程用事件循环能扛几千连接。代价是你得额外维护一个常驻进程还要处理进程守护、断线重连、心跳保活。通道类型单机并发上限消息延迟服务器成本代码复杂度短轮询约 200 在线1-3 秒高CPU 密集低长轮询约 500 在线0.5-1 秒中中WebSocket3000 在线50-200 毫秒低内存换 CPU高2.2 用 Workerman 起一个最小可用的 WebSocket 服务我一般会选 Workerman因为它纯 PHP 实现、不依赖扩展、文档够用部署时不用折腾编译。下面是一个能直接跑的最小服务端骨架?php // chat_server.php —— 最小 WebSocket 聊天服务 require_once __DIR__ . /vendor/autoload.php; use Workerman\Worker; use Workerman\Connection\TcpConnection; $ws new Worker(websocket://0.0.0.0:8282); $ws-count 4; // 启动 4 个进程按 CPU 核数调整 $ws-name chat-server; // 用内存表存连接ID 用户信息跨进程共享 $globalUidMap new \Workerman\Protocols\Http\Request(); // 占位实际用 GlobalData $ws-onConnect function (TcpConnection $conn) { $conn-uid null; // 未登录状态 $conn-lastHeartbeat time(); }; $ws-onMessage function (TcpConnection $conn, $data) use ($ws) { $msg json_decode($data, true); if (!$msg || !isset($msg[type])) { return; } switch ($msg[type]) { case login: // 简化示例真实项目必须校验 token $conn-uid (int)$msg[uid]; $conn-send(json_encode([type login_ok, uid $conn-uid])); break; case heartbeat: $conn-lastHeartbeat time(); $conn-send(json_encode([type pong])); break; case chat: // 广播给所有连接生产环境要按房间过滤 $payload json_encode([ type chat, from $conn-uid, content mb_substr($msg[content], 0, 500), ts time(), ]); foreach ($ws-connections as $client) { if ($client-uid ! null) { $client-send($payload); } } break; } }; $ws-onClose function (TcpConnection $conn) { // 清理在线状态真实项目要写回 Redis }; Worker::runAll();这段代码的逻辑很直白onConnect初始化连接状态onMessage按消息类型分发chat类型做广播。几个关键参数必须说清楚$ws-count 4表示开 4 个 worker 进程一般设成 CPU 核数设太多反而增加进程切换开销mb_substr($msg[content], 0, 500)是内容截断防止有人发超长文本把广播包撑爆$conn-lastHeartbeat配合定时器做死连接清理否则断网的客户端会一直占着连接。启动命令就一行php chat_server.php start -d-d是守护模式。调试时去掉-d能看到实时日志。要停就php chat_server.php stop。2.3 前端 H5 怎么接断线重连是必修课H5 聊天室源码的前端部分核心不是 UI是连接管理。移动端切后台、切网络、锁屏都会断连没有重连逻辑的聊天室等于不可用。// chat_client.js —— 带指数退避重连的 WebSocket 客户端 class ChatClient { constructor(url) { this.url url; this.ws null; this.retry 0; this.maxRetry 10; this.heartbeatTimer null; this.connect(); } connect() { this.ws new WebSocket(this.url); this.ws.onopen () { this.retry 0; // 连上就重置退避计数 this.startHeartbeat(); this.send({ type: login, uid: this.uid }); }; this.ws.onmessage (e) { const msg JSON.parse(e.data); if (msg.type pong) return; // 心跳响应不往上抛 this.onMessage this.onMessage(msg); }; this.ws.onclose () { this.stopHeartbeat(); if (this.retry this.maxRetry) { // 指数退避1s, 2s, 4s, 8s... 最多 30s const delay Math.min(1000 * Math.pow(2, this.retry), 30000); this.retry; setTimeout(() this.connect(), delay); } }; } startHeartbeat() { this.heartbeatTimer setInterval(() { this.send({ type: heartbeat }); }, 25000); // 25 秒一次小于服务端 60 秒超时 } stopHeartbeat() { clearInterval(this.heartbeatTimer); } send(obj) { if (this.ws this.ws.readyState WebSocket.OPEN) { this.ws.send(JSON.stringify(obj)); } } }重连用指数退避而不是固定间隔是为了避免服务端刚重启时被所有客户端同时冲击。心跳间隔 25 秒是经验值服务端一般设 60 秒无心跳就断开客户端留一半余量网络抖动一次不至于被误杀。this.retry 0在onopen里重置保证连上后下次断线还是从 1 秒开始退避。3. 把消息落库和广播拆开MySQL 只存历史Redis 管在线3.1 为什么不能每条消息都同步写 MySQL新手最容易犯的错是在onMessage里直接INSERT INTO messages。1000 人在线、每人每分钟发 2 条就是每秒 33 次写入MySQL 单表还能扛但一旦有人刷屏或者广播逻辑里还带着查询数据库连接池立刻见底。实时消息聊天源码的性能瓶颈90% 出在广播路径上做了同步 IO。正确做法是分层Redis 负责在线状态和最近消息MySQL 只做异步落库。广播走内存落库走队列。3.2 用 Redis 维护在线列表和房间成员?php // presence.php —— 在线状态管理 $redis new \Redis(); $redis-connect(127.0.0.1, 6379); $redis-select(1); // 用户上线加入房间集合设置 90 秒过期 function userOnline($redis, $roomId, $uid) { $key room:{$roomId}:online; $redis-sAdd($key, $uid); $redis-expire($key, 90); // 靠心跳续期不续就自动清 $redis-setex(user:{$uid}:room, 90, $roomId); } // 心跳续期 function heartbeat($redis, $roomId, $uid) { $redis-expire(room:{$roomId}:online, 90); $redis-expire(user:{$uid}:room, 90); } // 取房间在线人数 function onlineCount($redis, $roomId) { return $redis-sCard(room:{$roomId}:online); }用 Redis 集合而不是 MySQL 表来存在线状态是因为集合的增删是 O(1)而且expire能自动清理僵尸用户——用户断网没发离线通知时90 秒后自动从在线列表消失。这个 90 秒要和客户端心跳间隔配合客户端 25 秒发一次心跳服务端每次心跳都续期三次心跳没到就判定离线容错够用。3.3 消息异步落库用 Redis List 做缓冲队列?php // 广播时只推 Redis不碰 MySQL $redis-lPush(chat:msg:queue, json_encode([ room_id $roomId, uid $uid, content $content, ts time(), ])); // 独立的落库脚本用 crontab 或常驻进程消费 // persist_worker.php while (true) { $item $redis-brPop(chat:msg:queue, 5); // 阻塞 5 秒 if (!$item) continue; $msg json_decode($item[1], true); $stmt $pdo-prepare( INSERT INTO messages (room_id, uid, content, created_at) VALUES (?, ?, ?, ?) ); $stmt-execute([$msg[room_id], $msg[uid], $msg[content], $msg[ts]]); }brPop的第二个参数是阻塞超时设 5 秒是为了让脚本有机会检查退出信号不至于卡死。落库脚本单独跑广播路径上就只剩一次lPush耗时在毫秒级。MySQL 表建议按room_id加索引并且定期归档——聊天记录表是增长最快的表不做归档半年就能到千万行。提示messages表如果只用于历史查询可以考虑按月分表或者干脆把超过 30 天的记录转到冷存储主表只留近期数据。4. 避坑PHP 聊天室上线后最容易翻车的 5 个地方4.1 现象消息偶尔丢用户说我发的别人看不到原因通常是广播时遍历$ws-connections的过程中有连接正好断开send()抛异常中断了整个循环后面的用户就没收到。解决是把每个send包在 try-catch 里或者先收集连接列表再逐个发$clients []; foreach ($ws-connections as $client) { if ($client-uid ! null) $clients[] $client; } foreach ($clients as $client) { try { $client-send($payload); } catch (\Throwable $e) { /* 忽略单点失败 */ } }4.2 现象服务跑几天就内存暴涨最后被 OOM 杀掉原因是连接对象或消息缓存没释放。Workerman 里如果自己维护了全局数组存用户数据用户断开时忘了unset数组只增不减。血泪经验任何以连接为 key 的全局结构都必须在onClose里清理。另外$ws-connections是框架自己管的别手动去改它。4.3 现象移动端切回前台后收不到消息要刷新页面原因是浏览器切后台会冻结 WebSocket切回来时连接已经死了但readyState还没更新。解决是监听visibilitychange事件切回前台时主动检查连接状态不是 OPEN 就立即重连别等onclose触发document.addEventListener(visibilitychange, () { if (!document.hidden this.ws.readyState ! WebSocket.OPEN) { this.retry 0; this.connect(); } });4.4 现象同一用户开两个标签页消息重复显示原因是服务端按连接广播两个标签页是两个连接各自都收到。如果业务上要按用户去重得在服务端维护uid [连接列表]的映射广播时按 uid 去重只发最新连接或者前端按消息 ID 去重。我一般选前端去重服务端逻辑简单代价是浪费一点带宽。4.5 现象Nginx 反代后 WebSocket 连不上一直 400原因是 Nginx 默认不转发 Upgrade 头。必须在 location 里显式配置location /ws { proxy_pass http://127.0.0.1:8282; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_read_timeout 120s; # 要大于心跳间隔否则会被 Nginx 掐断 }proxy_read_timeout默认 60 秒如果心跳是 25 秒一次没问题但如果客户端网络差导致心跳延迟60 秒就可能被 Nginx 主动断开。设成 120 秒留足余量。5. 压测与调优怎么验证你的聊天室真能扛住 1000 人在线5.1 用脚本模拟并发连接先测连接数再测消息吞吐不要一上来就压消息先确认服务能稳定维持多少连接。用 Node.js 写个压测脚本最省事// bench.js —— 模拟 N 个 WebSocket 连接 const WebSocket require(ws); const N 1000; const URL ws://127.0.0.1:8282; let connected 0; const clients []; for (let i 0; i N; i) { const ws new WebSocket(URL); ws.on(open, () { connected; ws.send(JSON.stringify({ type: login, uid: i 1 })); if (connected N) { console.log(全部 ${N} 个连接建立完成); startChat(); } }); ws.on(message, () { /* 消费消息防止缓冲区堆积 */ }); ws.on(error, (e) console.error(连接 ${i} 出错:, e.message)); clients.push(ws); } function startChat() { // 每秒让 10% 的客户端发一条消息 setInterval(() { const idx Math.floor(Math.random() * N); clients[idx].send(JSON.stringify({ type: chat, content: 压测消息 Date.now(), })); }, 100); }跑之前先调ulimit -n 65535否则单机文件描述符上限会卡在 1024连到 1000 就报EMFILE。观察指标服务端内存增长是否平稳、CPU 是否单核跑满、消息从发出到广播回来的延迟。如果 CPU 单核跑满说明 worker 数不够或者广播逻辑太重先加count再考虑把广播拆到独立进程。5.2 三个必须调的参数参数位置建议值说明$ws-count服务端CPU 核数超过核数收益递减心跳间隔客户端25 秒服务端超时设 60 秒proxy_read_timeoutNginx120 秒必须大于心跳间隔pm.max_childrenPHP-FPM按内存算仅轮询方案需要5.3 一个我常用来验证消息不丢的技巧在压测脚本里给每条消息带一个自增序号客户端收到后记录最大连续序号跑 10 分钟后检查有没有断号。断号说明广播路径上有异常被吞了回去查 4.1 那个 try-catch。这个方法比看日志快得多因为日志在高并发下本身就可能丢。我自己的习惯是任何聊天室上线前先用 500 连接跑 30 分钟再用 1000 连接跑 10 分钟两轮都不断号、内存不涨才敢放真实用户进来。这套 PHP 全开源聊天室源码的价值不在于代码多漂亮而在于你能不能在它翻车之前把上面这些参数和坑都摸清楚。希望帮到你。本文还有配套的精品资源点击获取
