简介这是一套基于PHP与WebSocket技术构建的全开源H5聊天室源码面向需要为网站或应用快速集成即时通讯功能的开发者尤其适合具备一定PHP基础、希望省去从零搭建实时通信框架的人群。资源包共19个文件约1.5MB以9个php核心脚本为主涵盖WebSocket服务端、用户与消息模型及上传接口另含4个sql建表脚本、1个db数据库文件、1个css样式、1个js脚本以及搭建文档与说明文件结构紧凑便于二次开发。目前已有126人学习下载。源码同时支持数据库与无数据库两种运行模式可灵活适配不同存储需求并借助WebSocket实现客户端与服务器的全双工实时通信。开发者可自由查看和修改全部代码按需扩展功能、优化界面或提升性能也可参考社区贡献快速定位问题是搭建定制化聊天室的实用起点。1. 一套 PHP 全开源聊天室源码到底能扛住多少人同时在线很多开发者第一次接触 PHP 全开源聊天室源码都是被“H5 聊天室源码、实时消息聊天源码”这几个词吸引进来的——想着拿过来改改就能上线结果一压测就翻车。我最早做的一个模拟项目单机 Apache PHP-FPM 跑轮询方案50 个人同时发消息就开始出现明显延迟消息乱序、重复推送全来了。问题不在 PHP 本身而在于“实时消息”这四个字背后的技术选型你是用 HTTP 轮询、长轮询还是 WebSocket存储用文件、MySQL 还是 Redis这套源码能不能直接商用取决于它把实时链路做在哪一层。这篇文章面向想用 PHP 全开源聊天室源码快速搭一套 H5 聊天室的开发者从选型、部署、核心代码到压测避坑把一条能复现的落地路径讲清楚新手能照着跑通熟手能看到参数边界和性能天花板。2. 先定实时方案轮询、长轮询还是 WebSocket选错后面全白干2.1 三种实时消息方案的延迟与资源账在动手改任何一行 PHP 全开源聊天室源码之前先把实时消息的传输方案定下来这是整个 H5 聊天室的地基。常见做法有三种我按实际压测数据给你算一笔账。第一种是短轮询Polling。前端每隔 N 秒发一次 HTTP 请求问“有没有新消息”。实现最简单任何 PHP 环境都能跑但延迟等于轮询间隔设 3 秒就是平均 1.5 秒延迟设 1 秒服务器请求量直接翻倍。100 人在线、1 秒轮询就是 100 QPS 的空请求其中 95% 是“没有新消息”的无效查询。这种方案只适合演示不适合真实聊天室。第二种是长轮询Long Polling。前端发请求后服务端 hold 住连接有新消息才返回超时再重连。延迟能压到接近实时但每个在线用户会长期占用一个 PHP-FPM 进程。PHP-FPM 默认pm.max_children也就几十到几百意味着同时在线人数直接被进程数卡死。我见过有人把max_children调到 2000结果内存直接爆掉这就是典型的血泪经验。第三种是 WebSocket。一次握手后全双工通信服务端主动推送延迟最低、连接开销最小。但 PHP 本身不擅长常驻进程需要配合 Swoole、Workerman 这类常驻内存的扩展或框架或者用独立的 WebSocket 服务比如 Node.js、Go来扛连接PHP 只负责业务逻辑和存储。方案平均延迟1000 人在线资源占用实现难度适用场景短轮询1~3 秒高大量无效请求低演示、低频通知长轮询0.5~1 秒极高进程被占满中小规模、兼容性优先WebSocket50~200 毫秒低单进程多连接高真实聊天室、生产环境选型结论很明确要做真正的实时消息聊天源码WebSocket 是唯一能规模化的路。如果你的 PHP 全开源聊天室源码里只有 AJAX 轮询那它本质是个“伪实时”Demo别指望直接上线。2.2 用 Workerman 给 PHP 聊天室接上 WebSocket 的最小改造假设你手上这套 PHP 全开源聊天室源码是传统的 PHP MySQL 结构前端用 jQuery 发 AJAX。要把它升级成 WebSocket 实时推送最省事的路径是引入 Workerman——纯 PHP 写的常驻内存框架不需要装额外扩展composer require workerman/workerman就能用。下面是一个最小可跑的 WebSocket 服务端负责接收消息、广播给所有在线连接并把消息落库?php // chat_server.php require_once __DIR__ . /vendor/autoload.php; use Workerman\Worker; use Workerman\Connection\TcpConnection; // 创建 WebSocket 服务监听 0.0.0.0:8282 $ws_worker new Worker(websocket://0.0.0.0:8282); // 启动 4 个进程利用多核 $ws_worker-count 4; // 用连接 id 作为 key 维护在线用户 $ws_worker-onConnect function (TcpConnection $connection) { // 连接建立时先不绑定用户等客户端发登录消息 $connection-uid null; }; $ws_worker-onMessage function (TcpConnection $connection, $data) { $msg json_decode($data, true); if (!$msg || !isset($msg[type])) { return; } // 登录消息绑定 uid if ($msg[type] login) { $connection-uid (int)$msg[uid]; $connection-send(json_encode([type login_ok])); return; } // 聊天消息落库 广播 if ($msg[type] chat $connection-uid) { $content trim($msg[content] ?? ); if ($content ) { return; } // 这里换成你的 PDO 连接写入消息表 $pdo new PDO(mysql:host127.0.0.1;dbnamechat, user, pass); $stmt $pdo-prepare( INSERT INTO messages (uid, content, created_at) VALUES (?, ?, ?) ); $stmt-execute([$connection-uid, $content, time()]); // 广播给所有在线连接 $payload json_encode([ type chat, uid $connection-uid, content $content, time date(H:i:s), ]); foreach ($ws_worker-connections as $conn) { if ($conn-uid ! null) { $conn-send($payload); } } } }; $ws_worker-onClose function (TcpConnection $connection) { $connection-uid null; }; Worker::runAll();逻辑说明onConnect阶段不急着绑定用户因为 WebSocket 握手时拿不到可靠的用户身份必须等客户端发第一条login消息再绑定这是防止身份伪造的基本操作。onMessage里区分消息类型chat类型先落库再广播保证消息不丢。广播时遍历$ws_worker-connections只推给已登录连接。参数说明count 4表示开 4 个进程一般设成 CPU 核数websocket://0.0.0.0:8282里的端口要和前端连接地址一致生产环境记得在前面挂 Nginx 做 TLS 卸载。启动命令是php chat_server.php start调试用start -d后台运行改代码后restart。前端连接就三行核心代码// 前端建立 WebSocket 连接 const ws new WebSocket(ws://your-domain:8282); ws.onopen () { // 连接成功后发送登录消息绑定用户身份 ws.send(JSON.stringify({ type: login, uid: CURRENT_UID })); }; ws.onmessage (e) { const msg JSON.parse(e.data); if (msg.type chat) { // 把消息追加到聊天列表 appendMessage(msg); } };注意生产环境必须用wss://否则浏览器在 HTTPS 页面下会拦截ws://连接。这一步是新手最容易踩的坑本地测试好好的一上线就“连不上”八成是混合内容被拦了。3. 消息存储与历史记录MySQL 表结构怎么设计才不拖慢实时链路3.1 消息表、会话表、用户表的字段与索引实时链路跑通后下一个瓶颈就是存储。很多 PHP 全开源聊天室源码把消息直接写文件单机小规模能用一旦要查历史记录、做分页、支持多房间文件方案立刻崩。正确做法是 MySQL 存消息Redis 做在线状态和最近消息缓存。消息表设计要围绕“按会话查最近 N 条”这个最高频查询来建索引。下面是我一般会用的表结构-- 消息表只增不改按会话 时间查询 CREATE TABLE messages ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, room_id INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 房间/会话 id, uid INT UNSIGNED NOT NULL COMMENT 发送者用户 id, content TEXT NOT NULL COMMENT 消息内容, msg_type TINYINT NOT NULL DEFAULT 1 COMMENT 1文本 2图片 3系统, created_at INT UNSIGNED NOT NULL COMMENT Unix 时间戳, PRIMARY KEY (id), KEY idx_room_time (room_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 在线状态放 Redis不落 MySQL -- key: online:room:{room_id} value: set of uid -- key: user:last_seen:{uid} value: timestamp逻辑说明idx_room_time这个联合索引是关键查询“某房间最近 50 条”时WHERE room_id ? ORDER BY created_at DESC LIMIT 50能直接走索引不用全表扫。content用 TEXT 而不是 VARCHAR(255)因为聊天消息可能带表情、链接长度不可控。created_at用 INT 存时间戳而不是 DATETIME索引体积更小范围查询更快。参数说明如果消息量很大日增百万级单表会越来越慢常见做法是按月分表比如messages_202501查询时根据时间路由到对应表。分表键选room_id还是时间取决于你的查询模式——如果主要是查最近消息按时间分表更合适。3.2 历史消息分页游标分页替代 offset 分页新手写历史消息分页第一反应是LIMIT offset, size。这个写法在消息表上会越翻越慢因为offset很大时 MySQL 要扫描并丢弃前面所有行。100 万条消息翻到第 1000 页查询直接卡死。正确做法是游标分页Cursor Pagination用上一页最后一条的id作为游标?php // 拉取历史消息传入 last_id上一页最后一条的 id首次传 0 function getHistory(PDO $pdo, int $roomId, int $lastId 0, int $size 20): array { if ($lastId 0) { // 有游标查比 last_id 更早的消息 $sql SELECT id, uid, content, created_at FROM messages WHERE room_id ? AND id ? ORDER BY id DESC LIMIT ?; $stmt $pdo-prepare($sql); $stmt-execute([$roomId, $lastId, $size]); } else { // 首次加载查最新消息 $sql SELECT id, uid, content, created_at FROM messages WHERE room_id ? ORDER BY id DESC LIMIT ?; $stmt $pdo-prepare($sql); $stmt-execute([$roomId, $size]); } $rows $stmt-fetchAll(PDO::FETCH_ASSOC); // 返回时反转让前端按时间正序渲染 return array_reverse($rows); }逻辑说明用id last_id代替offset每次查询都从索引定位翻到第几页都是同样的速度。ORDER BY id DESC配合主键索引效率最高。返回前array_reverse是因为查询是倒序取最新但前端渲染要正序。参数说明size建议 20~50太大单次响应体大太小请求频繁。last_id由前端保存每次加载更多时带上。这套分页方式在千万级消息表上依然稳定是实时消息聊天源码必须做对的一环。4. 避坑与排查PHP 聊天室上线后最容易翻车的 5 个点4.1 消息重复推送与乱序现象用户收到两条一样的消息或者后发的消息先显示。原因通常是广播逻辑里对同一连接发了多次或者多进程模式下各进程的connections不共享。Workerman 多进程时每个进程维护自己的连接列表A 进程收到的消息广播时只能推给 A 进程的连接B 进程的连接收不到于是有人收不到、有人收到重复。解决多进程广播必须走进程间通信。Workerman 提供GatewayWorker或Channel组件做跨进程推送。简单做法是把count设为 1 先验证逻辑确认无误后再引入 Channel 组件。乱序问题则要在前端按消息id或时间戳排序后再渲染不能收到就 append。4.2 连接数上不去卡在 1024现象在线人数一到 1000 左右就大量掉线。原因Linux 默认单进程文件描述符限制是 1024WebSocket 每个连接占一个 fd。解决调大ulimit -n在/etc/security/limits.conf里加* soft nofile 65535和* hard nofile 65535重启后ulimit -n确认生效。同时 Workerman 启动时可以设$ws_worker-count配合系统 fd 上限别让单进程扛太多连接。4.3 消息落库拖慢广播现象消息一多广播延迟明显上升。原因onMessage里同步执行了 MySQL 写入写库慢就阻塞广播。解决把落库改成异步用 Redis 队列缓冲后台进程消费入库或者至少把广播放在落库之前先保证实时性落库失败再补偿。我一般会先广播再落库因为聊天场景里“实时看到”比“绝对不丢”优先级更高。4.4 前端断线不重连现象网络抖动后用户收不到消息刷新页面才恢复。原因前端没做 WebSocket 断线重连。解决在onclose里加指数退避重连第一次 1 秒后重连失败则 2 秒、4 秒、8 秒上限 30 秒。重连成功后要重新发login绑定身份并拉取断线期间的历史消息补上。let retry 0; function connect() { const ws new WebSocket(wss://your-domain/ws); ws.onopen () { retry 0; ws.send(JSON.stringify({type:login, uid: CURRENT_UID})); }; ws.onclose () { // 指数退避重连上限 30 秒 const delay Math.min(1000 * Math.pow(2, retry), 30000); retry; setTimeout(connect, delay); }; ws.onmessage handleMessage; } connect();4.5 敏感词与 XSS 没过滤现象用户发script标签别人页面弹窗或者发违规内容没人管。原因消息内容直接渲染到 DOM且没有服务端过滤。解决服务端入库前做敏感词过滤前端渲染用textContent而不是innerHTML或者用 DOMPurify 清洗。这两步缺一不可服务端过滤防存储型 XSS前端转义防即时渲染漏洞。5. 压测与容量估算你的 PHP 聊天室到底能撑多少人5.1 用 websocket-bench 做一次真实压测上线前必须压测别靠猜。我一般用websocket-bench这个工具Node.js 写的能模拟大量并发连接发消息。# 安装 npm install -g websocket-bench # 模拟 2000 个连接每个连接每秒发 1 条消息持续 60 秒 websocket-bench -a 2000 -c 200 -t 60 \ -m {type:chat,content:load test} \ ws://127.0.0.1:8282参数说明-a是总连接数-c是并发建立连接的批次-t是持续秒数-m是发送的消息体。压测时重点看三个指标连接建立成功率、消息平均延迟、服务端 CPU 和内存。如果延迟随连接数线性上升说明广播逻辑有 O(n) 遍历瓶颈需要优化成房间维度广播。5.2 单机容量估算与水平扩展思路基于我的实测经验一台 4 核 8G 的机器Workerman 开 4 进程单机能稳定支撑 5000~8000 个 WebSocket 连接消息广播延迟在 100 毫秒以内。超过这个量级要么升配要么水平扩展。水平扩展的核心是解决“跨机广播”。常见做法是引入 Redis 发布订阅每台机器上的 WebSocket 服务订阅同一个 Redis 频道消息统一发到 Redis各机器收到后推给自己持有的连接。这样加机器就能线性提升容量。存储层 MySQL 可以做主从读走从库写走主库Redis 做集群。这套架构下PHP 全开源聊天室源码的实时消息能力可以做到十万级在线关键看你有没有把广播和存储解耦。我自己的习惯是任何聊天室项目上线前先用 2000 连接压一遍把延迟和错误率记下来作为基线。后面每次改代码都对比这个基线延迟涨了 20% 以上就回头查。这个习惯帮我提前发现过好几次广播逻辑的性能退化。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/9 14:52:37 · 阅读 1.2k PHP全开源聊天室源码实战：WebSocket实时消息与高并发架构
简介这是一套基于PHP与WebSocket技术构建的全开源H5聊天室源码面向需要为网站或应用快速集成即时通讯功能的开发者尤其适合具备一定PHP基础、希望省去从零搭建实时通信框架的人群。资源包共19个文件约1.5MB以9个php核心脚本为主涵盖WebSocket服务端、用户与消息模型及上传接口另含4个sql建表脚本、1个db数据库文件、1个css样式、1个js脚本以及搭建文档与说明文件结构紧凑便于二次开发。目前已有126人学习下载。源码同时支持数据库与无数据库两种运行模式可灵活适配不同存储需求并借助WebSocket实现客户端与服务器的全双工实时通信。开发者可自由查看和修改全部代码按需扩展功能、优化界面或提升性能也可参考社区贡献快速定位问题是搭建定制化聊天室的实用起点。1. 一套 PHP 全开源聊天室源码到底能扛住多少人同时在线很多开发者第一次接触 PHP 全开源聊天室源码都是被“H5 聊天室源码、实时消息聊天源码”这几个词吸引进来的——想着拿过来改改就能上线结果一压测就翻车。我最早做的一个模拟项目单机 Apache PHP-FPM 跑轮询方案50 个人同时发消息就开始出现明显延迟消息乱序、重复推送全来了。问题不在 PHP 本身而在于“实时消息”这四个字背后的技术选型你是用 HTTP 轮询、长轮询还是 WebSocket存储用文件、MySQL 还是 Redis这套源码能不能直接商用取决于它把实时链路做在哪一层。这篇文章面向想用 PHP 全开源聊天室源码快速搭一套 H5 聊天室的开发者从选型、部署、核心代码到压测避坑把一条能复现的落地路径讲清楚新手能照着跑通熟手能看到参数边界和性能天花板。2. 先定实时方案轮询、长轮询还是 WebSocket选错后面全白干2.1 三种实时消息方案的延迟与资源账在动手改任何一行 PHP 全开源聊天室源码之前先把实时消息的传输方案定下来这是整个 H5 聊天室的地基。常见做法有三种我按实际压测数据给你算一笔账。第一种是短轮询Polling。前端每隔 N 秒发一次 HTTP 请求问“有没有新消息”。实现最简单任何 PHP 环境都能跑但延迟等于轮询间隔设 3 秒就是平均 1.5 秒延迟设 1 秒服务器请求量直接翻倍。100 人在线、1 秒轮询就是 100 QPS 的空请求其中 95% 是“没有新消息”的无效查询。这种方案只适合演示不适合真实聊天室。第二种是长轮询Long Polling。前端发请求后服务端 hold 住连接有新消息才返回超时再重连。延迟能压到接近实时但每个在线用户会长期占用一个 PHP-FPM 进程。PHP-FPM 默认pm.max_children也就几十到几百意味着同时在线人数直接被进程数卡死。我见过有人把max_children调到 2000结果内存直接爆掉这就是典型的血泪经验。第三种是 WebSocket。一次握手后全双工通信服务端主动推送延迟最低、连接开销最小。但 PHP 本身不擅长常驻进程需要配合 Swoole、Workerman 这类常驻内存的扩展或框架或者用独立的 WebSocket 服务比如 Node.js、Go来扛连接PHP 只负责业务逻辑和存储。方案平均延迟1000 人在线资源占用实现难度适用场景短轮询1~3 秒高大量无效请求低演示、低频通知长轮询0.5~1 秒极高进程被占满中小规模、兼容性优先WebSocket50~200 毫秒低单进程多连接高真实聊天室、生产环境选型结论很明确要做真正的实时消息聊天源码WebSocket 是唯一能规模化的路。如果你的 PHP 全开源聊天室源码里只有 AJAX 轮询那它本质是个“伪实时”Demo别指望直接上线。2.2 用 Workerman 给 PHP 聊天室接上 WebSocket 的最小改造假设你手上这套 PHP 全开源聊天室源码是传统的 PHP MySQL 结构前端用 jQuery 发 AJAX。要把它升级成 WebSocket 实时推送最省事的路径是引入 Workerman——纯 PHP 写的常驻内存框架不需要装额外扩展composer require workerman/workerman就能用。下面是一个最小可跑的 WebSocket 服务端负责接收消息、广播给所有在线连接并把消息落库?php // chat_server.php require_once __DIR__ . /vendor/autoload.php; use Workerman\Worker; use Workerman\Connection\TcpConnection; // 创建 WebSocket 服务监听 0.0.0.0:8282 $ws_worker new Worker(websocket://0.0.0.0:8282); // 启动 4 个进程利用多核 $ws_worker-count 4; // 用连接 id 作为 key 维护在线用户 $ws_worker-onConnect function (TcpConnection $connection) { // 连接建立时先不绑定用户等客户端发登录消息 $connection-uid null; }; $ws_worker-onMessage function (TcpConnection $connection, $data) { $msg json_decode($data, true); if (!$msg || !isset($msg[type])) { return; } // 登录消息绑定 uid if ($msg[type] login) { $connection-uid (int)$msg[uid]; $connection-send(json_encode([type login_ok])); return; } // 聊天消息落库 广播 if ($msg[type] chat $connection-uid) { $content trim($msg[content] ?? ); if ($content ) { return; } // 这里换成你的 PDO 连接写入消息表 $pdo new PDO(mysql:host127.0.0.1;dbnamechat, user, pass); $stmt $pdo-prepare( INSERT INTO messages (uid, content, created_at) VALUES (?, ?, ?) ); $stmt-execute([$connection-uid, $content, time()]); // 广播给所有在线连接 $payload json_encode([ type chat, uid $connection-uid, content $content, time date(H:i:s), ]); foreach ($ws_worker-connections as $conn) { if ($conn-uid ! null) { $conn-send($payload); } } } }; $ws_worker-onClose function (TcpConnection $connection) { $connection-uid null; }; Worker::runAll();逻辑说明onConnect阶段不急着绑定用户因为 WebSocket 握手时拿不到可靠的用户身份必须等客户端发第一条login消息再绑定这是防止身份伪造的基本操作。onMessage里区分消息类型chat类型先落库再广播保证消息不丢。广播时遍历$ws_worker-connections只推给已登录连接。参数说明count 4表示开 4 个进程一般设成 CPU 核数websocket://0.0.0.0:8282里的端口要和前端连接地址一致生产环境记得在前面挂 Nginx 做 TLS 卸载。启动命令是php chat_server.php start调试用start -d后台运行改代码后restart。前端连接就三行核心代码// 前端建立 WebSocket 连接 const ws new WebSocket(ws://your-domain:8282); ws.onopen () { // 连接成功后发送登录消息绑定用户身份 ws.send(JSON.stringify({ type: login, uid: CURRENT_UID })); }; ws.onmessage (e) { const msg JSON.parse(e.data); if (msg.type chat) { // 把消息追加到聊天列表 appendMessage(msg); } };注意生产环境必须用wss://否则浏览器在 HTTPS 页面下会拦截ws://连接。这一步是新手最容易踩的坑本地测试好好的一上线就“连不上”八成是混合内容被拦了。3. 消息存储与历史记录MySQL 表结构怎么设计才不拖慢实时链路3.1 消息表、会话表、用户表的字段与索引实时链路跑通后下一个瓶颈就是存储。很多 PHP 全开源聊天室源码把消息直接写文件单机小规模能用一旦要查历史记录、做分页、支持多房间文件方案立刻崩。正确做法是 MySQL 存消息Redis 做在线状态和最近消息缓存。消息表设计要围绕“按会话查最近 N 条”这个最高频查询来建索引。下面是我一般会用的表结构-- 消息表只增不改按会话 时间查询 CREATE TABLE messages ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, room_id INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 房间/会话 id, uid INT UNSIGNED NOT NULL COMMENT 发送者用户 id, content TEXT NOT NULL COMMENT 消息内容, msg_type TINYINT NOT NULL DEFAULT 1 COMMENT 1文本 2图片 3系统, created_at INT UNSIGNED NOT NULL COMMENT Unix 时间戳, PRIMARY KEY (id), KEY idx_room_time (room_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 在线状态放 Redis不落 MySQL -- key: online:room:{room_id} value: set of uid -- key: user:last_seen:{uid} value: timestamp逻辑说明idx_room_time这个联合索引是关键查询“某房间最近 50 条”时WHERE room_id ? ORDER BY created_at DESC LIMIT 50能直接走索引不用全表扫。content用 TEXT 而不是 VARCHAR(255)因为聊天消息可能带表情、链接长度不可控。created_at用 INT 存时间戳而不是 DATETIME索引体积更小范围查询更快。参数说明如果消息量很大日增百万级单表会越来越慢常见做法是按月分表比如messages_202501查询时根据时间路由到对应表。分表键选room_id还是时间取决于你的查询模式——如果主要是查最近消息按时间分表更合适。3.2 历史消息分页游标分页替代 offset 分页新手写历史消息分页第一反应是LIMIT offset, size。这个写法在消息表上会越翻越慢因为offset很大时 MySQL 要扫描并丢弃前面所有行。100 万条消息翻到第 1000 页查询直接卡死。正确做法是游标分页Cursor Pagination用上一页最后一条的id作为游标?php // 拉取历史消息传入 last_id上一页最后一条的 id首次传 0 function getHistory(PDO $pdo, int $roomId, int $lastId 0, int $size 20): array { if ($lastId 0) { // 有游标查比 last_id 更早的消息 $sql SELECT id, uid, content, created_at FROM messages WHERE room_id ? AND id ? ORDER BY id DESC LIMIT ?; $stmt $pdo-prepare($sql); $stmt-execute([$roomId, $lastId, $size]); } else { // 首次加载查最新消息 $sql SELECT id, uid, content, created_at FROM messages WHERE room_id ? ORDER BY id DESC LIMIT ?; $stmt $pdo-prepare($sql); $stmt-execute([$roomId, $size]); } $rows $stmt-fetchAll(PDO::FETCH_ASSOC); // 返回时反转让前端按时间正序渲染 return array_reverse($rows); }逻辑说明用id last_id代替offset每次查询都从索引定位翻到第几页都是同样的速度。ORDER BY id DESC配合主键索引效率最高。返回前array_reverse是因为查询是倒序取最新但前端渲染要正序。参数说明size建议 20~50太大单次响应体大太小请求频繁。last_id由前端保存每次加载更多时带上。这套分页方式在千万级消息表上依然稳定是实时消息聊天源码必须做对的一环。4. 避坑与排查PHP 聊天室上线后最容易翻车的 5 个点4.1 消息重复推送与乱序现象用户收到两条一样的消息或者后发的消息先显示。原因通常是广播逻辑里对同一连接发了多次或者多进程模式下各进程的connections不共享。Workerman 多进程时每个进程维护自己的连接列表A 进程收到的消息广播时只能推给 A 进程的连接B 进程的连接收不到于是有人收不到、有人收到重复。解决多进程广播必须走进程间通信。Workerman 提供GatewayWorker或Channel组件做跨进程推送。简单做法是把count设为 1 先验证逻辑确认无误后再引入 Channel 组件。乱序问题则要在前端按消息id或时间戳排序后再渲染不能收到就 append。4.2 连接数上不去卡在 1024现象在线人数一到 1000 左右就大量掉线。原因Linux 默认单进程文件描述符限制是 1024WebSocket 每个连接占一个 fd。解决调大ulimit -n在/etc/security/limits.conf里加* soft nofile 65535和* hard nofile 65535重启后ulimit -n确认生效。同时 Workerman 启动时可以设$ws_worker-count配合系统 fd 上限别让单进程扛太多连接。4.3 消息落库拖慢广播现象消息一多广播延迟明显上升。原因onMessage里同步执行了 MySQL 写入写库慢就阻塞广播。解决把落库改成异步用 Redis 队列缓冲后台进程消费入库或者至少把广播放在落库之前先保证实时性落库失败再补偿。我一般会先广播再落库因为聊天场景里“实时看到”比“绝对不丢”优先级更高。4.4 前端断线不重连现象网络抖动后用户收不到消息刷新页面才恢复。原因前端没做 WebSocket 断线重连。解决在onclose里加指数退避重连第一次 1 秒后重连失败则 2 秒、4 秒、8 秒上限 30 秒。重连成功后要重新发login绑定身份并拉取断线期间的历史消息补上。let retry 0; function connect() { const ws new WebSocket(wss://your-domain/ws); ws.onopen () { retry 0; ws.send(JSON.stringify({type:login, uid: CURRENT_UID})); }; ws.onclose () { // 指数退避重连上限 30 秒 const delay Math.min(1000 * Math.pow(2, retry), 30000); retry; setTimeout(connect, delay); }; ws.onmessage handleMessage; } connect();4.5 敏感词与 XSS 没过滤现象用户发script标签别人页面弹窗或者发违规内容没人管。原因消息内容直接渲染到 DOM且没有服务端过滤。解决服务端入库前做敏感词过滤前端渲染用textContent而不是innerHTML或者用 DOMPurify 清洗。这两步缺一不可服务端过滤防存储型 XSS前端转义防即时渲染漏洞。5. 压测与容量估算你的 PHP 聊天室到底能撑多少人5.1 用 websocket-bench 做一次真实压测上线前必须压测别靠猜。我一般用websocket-bench这个工具Node.js 写的能模拟大量并发连接发消息。# 安装 npm install -g websocket-bench # 模拟 2000 个连接每个连接每秒发 1 条消息持续 60 秒 websocket-bench -a 2000 -c 200 -t 60 \ -m {type:chat,content:load test} \ ws://127.0.0.1:8282参数说明-a是总连接数-c是并发建立连接的批次-t是持续秒数-m是发送的消息体。压测时重点看三个指标连接建立成功率、消息平均延迟、服务端 CPU 和内存。如果延迟随连接数线性上升说明广播逻辑有 O(n) 遍历瓶颈需要优化成房间维度广播。5.2 单机容量估算与水平扩展思路基于我的实测经验一台 4 核 8G 的机器Workerman 开 4 进程单机能稳定支撑 5000~8000 个 WebSocket 连接消息广播延迟在 100 毫秒以内。超过这个量级要么升配要么水平扩展。水平扩展的核心是解决“跨机广播”。常见做法是引入 Redis 发布订阅每台机器上的 WebSocket 服务订阅同一个 Redis 频道消息统一发到 Redis各机器收到后推给自己持有的连接。这样加机器就能线性提升容量。存储层 MySQL 可以做主从读走从库写走主库Redis 做集群。这套架构下PHP 全开源聊天室源码的实时消息能力可以做到十万级在线关键看你有没有把广播和存储解耦。我自己的习惯是任何聊天室项目上线前先用 2000 连接压一遍把延迟和错误率记下来作为基线。后面每次改代码都对比这个基线延迟涨了 20% 以上就回头查。这个习惯帮我提前发现过好几次广播逻辑的性能退化。希望帮到你。本文还有配套的精品资源点击获取