简介：一款PHP在线聊天室源码采用单文件、无数据库的极简设计，面向需要快速搭建临时聊天页面的开发者，也适合刚接触Web编程的初学者理解请求响应与消息轮询机制。压缩包内部仅含1个PHP文件，体积8KB，无需配置数据库或额外依赖，上传至支持PHP5与PHP7的任意服务器环境即可运行，部署成本非常低。源码在服务器端内存中维护聊天记录与在线用户集合，通过轮询方式实现消息的即时传递，同时支持自定义聊天界面字体样式，代码集中在一个文件内，降低了阅读与调试门槛。目前已有1873人学习下载，对想研究PHP会话管理、Ajax轮询通信和轻量级应用组织方式的读者来说，是可以直接运行验证并逐步改造的实用样例。
1. 单文件无数据库的 PHP 聊天室：小场景里的实用方案还是玩具代码
拿到「PHP 在线聊天室源码（单文件无数据库版）.zip」这个包，第一反应大多是好奇：一个 PHP 文件，不连 MySQL，就能做出在线聊天室？实际用下来，这个方案比想象中能扛事。它把消息存进文件，用轮询方式让浏览器定时拉取新内容，没有数据库连接、没有安装依赖、不用 composer，上传到支持 PHP 的虚拟主机就能跑。适合临时讨论组、内网工具、教学演示这类并发不高、不想为一个小功能专门建库的场景。但它的边界也清楚：并发一高、文件一乱，问题就来了。下面从工作方式、部署、改造、排错一步步拆，让你拿到源码后知道怎么用、怎么改、怎么避免翻车。
2. 单文件聊天室的工作方式：文件存储、轮询与并发边界
2.1 为什么无数据库也能聊天：文件当数据库的三种常见形态
无数据库版的聊天室，核心思路是「文件即数据库」。常见做法有三种，源码包里具体用哪种，打开文件看一眼就能判断。
第一种是 JSON 文件存储。整个消息列表存成一个数组，每次有新消息就读取文件、解码、追加、编码、写回。结构清晰，字段可以带用户名、时间、内容，后边做分页和清理都方便。缺点是每次读写都是全量操作，文件到几 MB 后性能明显下降。
第二种是纯文本追加。新消息直接 file_put_contents 以 FILE_APPEND 模式追加到文本末尾，读的时候用 file() 按行读取，取最后 N 行。写入开销最小，但消息里不能带换行符，否则会把一条消息拆成多行，解析时容易错位。
第三种是序列化文件。用 serialize() 把数组存进去，读取时用 unserialize() 还原。性能跟 JSON 方案接近，但文件可读性差，排查问题不方便，而且 unserialize 处理不可信内容时有对象注入风险，不建议在接收用户输入的场合用。
拿到源码后先确认它属于哪种形态。判断方法很简单：打开文件搜索 file_put_contents 和 json_encode / json_decode / unserialize 出现的位置。默认情况下，JSON 方案扩展性最好，我一般会优先把其他形态改成 JSON，后面做多房间、消息滚动和迁移数据库都省事。
存储路径也有讲究。规范的做法是在聊天室 PHP 文件同目录下建一个 data 子目录，消息文件放在里面，并且这个目录要设置成不允许直接通过浏览器访问。很多单文件版源码随手把消息文件存在脚本同目录，扩展名还是 .json，等于把聊天记录直接挂到了公网上。这一点在后续排查那一章会细讲。
2.2 轮询 vs 长轮询：单文件版默认走的路线与参数取舍
单文件无数据库版没有常驻进程，WebSocket 那种长连接方案在纯 PHP-FPM 环境下很难实现，所以绝大多数源码走的是轮询：浏览器定时发 AJAX 请求，问服务器「有没有新消息」。这个方案实现最简单，但有几个参数直接决定体验和服务器负载。
间隔时间是最关键的参数。设成 1000 毫秒，消息延迟不超过 1 秒，但每个在线用户每秒打一个请求；10 个用户同时在线，每秒就是 10 次 PHP 进程启动和文件读取。设成 3000 毫秒，服务器压力小很多，但聊天有明显延迟感，两个人对话会觉得卡。
更聪明的做法是增量拉取。前端把最后一次看到的消息 ID 传给后端，后端只返回 ID 比它大的消息，而不是每次把整个文件读一遍再全量返回。很多原生单文件版没做这一步，每次轮询都返回全部消息，文件一涨，流量和 CPU 一起炸。
单文件版还有一个隐含性能瓶颈：PHP 每次请求都要重新解析整个文件、启动所有函数，没有常驻内存。所以轮询间隔、返回消息条数、消息文件大小这三个参数是互相牵制的，调优时得一起考虑，不能只调一个。下面是我在改造时常用的参数表，可直接抄：
| 参数 | 建议值 | 说明 |
|---|---|---|
| 轮询间隔 | 1500~3000ms | 低于 1000ms 对单文件版压力过大 |
| 单次返回消息数 | 50~100 条 | 超出部分走历史分页，不走轮询 |
| 消息文件上限 | 1~2MB | 超过后触发滚动清理，见第 4 章 |
| last_id 增量拉取 | 必须开启 | 否则文件多大就返回多大，流量白烧 |
LONG POLLING 也是可选路线，但单文件版做长轮询有个现实问题：PHP-FPM 进程会被请求占住，长轮询挂起期间占着 worker 不释放，并发一高很快把进程池打满。我实际测过，10 个长轮询请求就能让一个默认配置的 PHP-FPM 池喘不过气。单文件版优先保证轮询间隔合理，别一上来就追求长轮询。
2.3 单文件版的适用边界：什么场景值得用、什么场景别硬上
聊到边界，先说结论：单文件无数据库版不是生产级聊天方案，但它是特定场景下性价比最高的方案。
适合的场景有三类。第一类是内网临时工具，比如办公室几个人在局域网里开个简单讨论区，没有现成的 IM 工具，又不想为这个需求装一套数据库。第二类是教学演示，给学员讲 AJAX 轮询、文件读写、PHP 基础语法，单文件版代码量小、逻辑直白，比引入框架更容易讲透。第三类是低并发的活动页面，比如在线答疑、直播弹幕的轻量替代，用户量几百以内，消息频率不高，单文件版完全扛得住。
不适合的场景也明确。凡是需要消息不丢失、需要历史记录长期保存、需要多节点部署的，都不要用。文件存储在高并发下有两个硬伤：一是并发写同一文件会互相覆盖或写坏，得靠锁来保护，但加锁又拖慢吞吐；二是文件没法横向扩展，多台服务器共享一个文件系统才能读到同一份聊天记录，部署复杂度直接上升。我的判断标准很简单：同时在线超过 50 人，或者消息峰值超过每秒 5 条，就老老实实换 SQLite 或 MySQL，别再折腾单文件版。单文件版的意义在于「快」和「省」，不在「强」和「稳」。
3. 把聊天室源码跑起来：本地最小命令部署与 Nginx 上线配置
3.1 用 PHP 内置服务器在本地跑通的最小命令
先确认环境里有 PHP，版本建议 7.4 以上。本地调试不用配 Nginx，PHP 自带的内置服务器就够了。解压 zip 后，在源码目录下执行：
cd /path/to/chatroom php -S 0.0.0.0:8080然后浏览器访问http://127.0.0.1:8080，聊天室页面就出来了。如果源码里有 ajax 接口路径写的是相对路径（比如chat.php），内置服务器也能正确处理，因为 PHP 内置服务器会把不存在的文件路径回退到 index.php 或直接执行对应的 .php 文件。
这个命令里几个参数说明一下。0.0.0.0表示监听所有网卡，局域网里其他机器可以用http://你的IP:8080访问，方便拿手机或另一台电脑测真实交互；如果只想本机访问，改成127.0.0.1更安全。8080是端口，被占用就换 8081、8082。内置服务器是单进程模型，性能很弱，只适合本地验证，不要拿它当线上服务跑。
跑通后先看两个东西。一是浏览器控制台有没有报错，重点看 Network 面板里轮询请求的状态码；二是源码目录下有没有自动生成消息文件。正常情况下，发第一条消息后，data 目录（或源码指定的存储目录）会出现一个 .json 或 .txt 文件，里面就是刚发的消息内容。
3.2 让聊天室在 Nginx 上稳定运行：配置与目录权限
本地跑通后上线，最常见的部署方式是 Nginx + PHP-FPM。单文件版不需要 rewrite 规则，但有几个配置要点直接影响能不能跑、跑得稳不稳。
server { listen 80; server_name chat.example.com; root /var/www/chatroom; index index.php; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/run/php/php-fpm.sock; } location ~ /data/ { deny all; return 404; } }location ~ /data/这一段是保命配置，专门把存储消息文件的目录封死。原因前面提过，消息文件是 json 或 txt 格式，如果不做拦截，任何人猜到文件名就能直接下载聊天记录。deny all; return 404;的意思是不管什么请求，只要路径里带 /data/ 就一律拒绝，而且返回 404 而不是 403，避免暴露目录存在的信息。
try_files那行是给单入口准备的。虽然单文件版通常只有一个 index.php，ajax 请求会直接指向chat.php之类的文件名，不需要伪静态，但加上这行能兼容「部分链接写成/结尾」的情况。PHP-FPM 的 sock 路径在不同系统上不一样，Ubuntu 通常是/run/php/php-fpm.sock，CentOS 可能是/run/php-fpm/www.sock，配错了会报 502，这个坑后面单独说。
目录权限方面，给存储目录设置写权限就够了，不要给整个站点目录 777：
chown -R www-data:www-data /var/www/chatroom chmod 755 /var/www/chatroom chmod 775 /var/www/chatroom/data chown www-data:www-data /var/www/chatroom/datachown把站点文件归属改成 PHP-FPM 运行用户（多数是 www-data），PHP 才有权限在 data 目录里创建和修改消息文件。chmod 755保证文件可读，775给 data 目录加写权限。注意：如果 data 目录不存在，PHP 没有权限自主创建它，需要提前建好，否则首次写入消息时会报权限错误，表现成「发消息没反应」。
3.3 跑通后先做的三个验证操作
部署完别急着收工，花两分钟做三个验证，能省掉后面大量排查时间。
第一个验证是双窗口互发。用一个浏览器的普通窗口和隐身窗口分别打开聊天室地址，两个窗口各发一条消息，确认双方都能实时看到。这一步验证的是最基本的读写链路：一个窗口写入文件，另一个窗口通过轮询读到新内容。
第二个验证是确认消息文件的增量内容。发完消息后到服务器上看一眼：
tail -c 500 /var/www/chatroom/data/messages.json正常情况应该是最近几条消息的 JSON 片段，包含用户名、时间和内容。如果文件是空的，说明消息写到了别的位置，检查源码里存储路径是不是相对路径，相对路径在不同入口文件下解析的基准目录不一样，很容易写歪。
第三个验证是直接请求存储文件，确认被拦截。浏览器访问http://你的域名/data/messages.json，应该返回 404。如果能看到 JSON 内容，说明 Nginx 配置里那个location ~ /data/没生效，或者消息文件并不在 data 目录下，得马上调整，这是数据泄露级别的隐患。
三个验证都过了，这个聊天室才算真正立住了。接下来才是让源码变得好用的关键一步：改造。
4. 把单文件源码改造成能上线用的版本：多房间、消息滚动与安全过滤
4.1 多房间支持：用路径参数区分频道的最小改法
单文件版通常只有一个聊天室，所有人挤在一起。要拆成多个房间，最小改动方案是直接用 URL 参数区分频道，消息文件名跟着频道走。
<?php // index.php — 多房间支持的最小实现 $room = isset($_GET['room']) ? preg_replace('/[^a-zA-Z0-9_-]/', '', $_GET['room']) : 'default'; if (strlen($room) > 32) { $room = 'default'; } $dataFile = __DIR__ . '/data/msg_' . $room . '.json';这段代码做了两件事。第一，把房间名限制成字母、数字、下划线和短横线，长度上限 32，防止用户传../../etc/passwd这种路径穿越字符串去读写任意文件。第二，每个房间对应独立的消息文件msg_房间名.json，互不干扰。
在 HTML 端，前端连接时带上房间参数：
const room = new URLSearchParams(window.location.search).get('room') || 'default'; fetch('index.php?room=' + encodeURIComponent(room) + '&action=poll&last_id=' + lastId)核心原则是「房间名必须白名单校验」。正则过滤是底线，不能只做长度限制；encodeURIComponent是前端配合，防止特殊字符把 URL 搞坏。改造后入口链接变成http://你的域名/?room=tech和http://你的域名/?room=life，不同频道数据彻底分开。
这个方案有个天然缺陷：房间多了以后消息文件数量跟着涨，每个文件独立维护，没法做跨房间搜索。但对单文件版这种轻量场景，文件数量控制在几十个以内完全没问题。
4.2 消息文件滚动清理：让文件永远不超过 2MB
消息文件无限增长是单文件版最大的慢性病。文件一大，每次轮询读取全量 JSON 再解析，PHP 处理时间直线上升，最终把 CPU 吃满。解决办法是滚动清理：限制最大消息条数，超出就删最旧的。
<?php // 加载并清理消息 const MAX_MESSAGES = 200; $messages = json_decode(file_get_contents($dataFile), true); if (is_array($messages) && count($messages) > MAX_MESSAGES) { $messages = array_slice($messages, -MAX_MESSAGES); file_put_contents($dataFile, json_encode($messages, JSON_UNESCAPED_UNICODE), LOCK_EX); }这段逻辑放在每次写入新消息之后。array_slice($messages, -200)从数组尾部取最后 200 条，也就是保留最新消息，丢掉最旧的，然后整文件写回。JSON_UNESCAPED_UNICODE参数很关键，不加的话中文会被转成\uXXXX形式，文件体积变大不说，排查问题时光看内容就得先解码，十分痛苦。
滚动清理的执行时机也可以放在轮询拉取时，但放在「写消息后」更合理，因为能保证写入操作总是面对一个不超限的文件。如果担心并发下两个人同时触发清理导致文件写坏，把清理动作放进写入的锁内，见第 5 章的 flock 方案。
2MB 这个值是经验参数。一个 JSON 文件单条消息平均 200 字节，2MB 大约能存 1 万条，对单文件版来说读取和解析还在可接受范围。想再保守一点就设成 1000 条，聊天室满后自动滚动，旧消息丢就丢了，反正单文件版本来就不承诺持久化。
4.3 XSS 与内容过滤、防刷屏的最小安全方案
聊天室是用户输入内容的典型场景，XSS 是必须处理的第一道安全坎。最小方案是输出转义加输入限制，两层同时做。
先看输出端转义。所有从消息文件读出并渲染到页面的内容，一律经过 htmlspecialchars：
<?php // 输出单条消息 function renderMessage($msg) { $name = htmlspecialchars($msg['name'] ?? '', ENT_QUOTES, 'UTF-8'); $text = htmlspecialchars($msg['text'] ?? '', ENT_QUOTES, 'UTF-8'); $time = htmlspecialchars($msg['time'] ?? '', ENT_QUOTES, 'UTF-8'); return "<div class='msg'><strong>{$name}</strong> {$time}<p>{$text}</p></div>"; }ENT_QUOTES会把单引号和双引号都转义，UTF-8指定编码防止编码绕过。这样用户输入<script>或<img onerror>都只会显示成纯文本，不会执行。很多源码只做了输入端的strip_tags就认为安全了，实际上输出端转义才是最后防线，输入过滤只是减少存储脏数据，不能替代输出转义。
再看输入端限制。用户名限制长度 20 字符，消息内容限制 500 字符，超长直接截断或拒绝。防刷屏的最简单实现是记录每个 IP 的最后发言时间，间隔小于 2 秒就拒绝：
<?php $ip = $_SERVER['REMOTE_ADDR']; $lastFile = __DIR__ . '/data/last_' . md5($ip) . '.txt'; if (file_exists($lastFile) && (time() - (int)file_get_contents($lastFile)) < 2) { exit(json_encode(['error' => '发言太快'])); } file_put_contents($lastFile, time(), LOCK_EX);这种按 IP 限流的方案在 NAT 环境下会误伤，比如一个办公室共用同一个出口 IP，两个人同时发言会被拦截。单文件版里这是可以接受的代价，毕竟它的定位本来就是小范围场景，真要精细限流就得引入用户体系了，那已经超出这个标题的边界。
5. 单文件聊天室排查笔记：并发写坏文件、中文乱码与白屏的 5 个坑
5.1 现象：两个用户同时发言，消息文件写坏，聊天记录丢了
多人同时发言时，消息文件偶尔变成空文件，或者 JSON 解析失败，聊天里的消息突然消失。原因很直接：PHP 的「读-改-写」三步不是原子的，两个请求同时读到旧文件，各自追加各自的消息，后写的人把先写的人覆盖了。
解决方法是给整段「读-改-写」加文件锁：
<?php // 写入消息（带锁） $fp = fopen($dataFile, 'c+'); flock($fp, LOCK_EX); $messages = json_decode(stream_get_contents($fp), true) ?: []; $messages[] = ['name' => $name, 'text' => $text, 'time' => date('Y-m-d H:i:s')]; if (count($messages) > MAX_MESSAGES) { $messages = array_slice($messages, -MAX_MESSAGES); } ftruncate($fp, 0); rewind($fp); fwrite($fp, json_encode($messages, JSON_UNESCAPED_UNICODE)); fflush($fp); flock($fp, LOCK_UN); fclose($fp);注意细节：fopen用的是c+模式，文件不存在会自动创建，不会像w+那样一打开就把文件清空。flock的锁必须覆盖「读文件内容 → 修改数组 → 写回文件」的整个过程，很多失败案例是只给最后一步 fwrite 加了锁，前面的读操作没锁住，等于白锁。ftruncate之后必须rewind回文件开头再写，否则写的位置不对，文件尾部会残留旧数据。
5.2 现象：中文消息在聊天窗口里显示成乱码
页面显示ä¸æ–‡之类的乱码，而消息文件里存的内容看起来也怪怪的。原因几乎都是编码不一致：PHP 文件本身是 UTF-8，但页面输出没有声明编码；或者 json_encode 时没加JSON_UNESCAPED_UNICODE，浏览器端又按 GBK 解析了。
解决分三步。第一步确认所有 PHP 文件保存为 UTF-8 无 BOM 编码，排查时用编辑器全部转换一遍。第二步在页面头部加编码声明：
header('Content-Type: text/html; charset=utf-8');第三步在 json_encode 时加上JSON_UNESCAPED_UNICODE，同时在前端 fetch 解析时明确指定 UTF-8。做完这三步，中文乱码基本不会再出现。这个坑的隐蔽之处在于本地开发环境不报错、上线后偶发，多半是编辑器默认编码不是 UTF-8 导致的，属于写代码时留下的慢性病。
5.3 现象：线上部署后访问白屏，浏览器控制台和 PHP 日志什么都没有
页面空白，没有报错输出，轮询请求返回 200 但内容是空。先确认一个最容易被忽略的问题：PHP 配置文件里的short_open_tag是不是 Off。很多单文件版源码为了省代码用了<?短标签，而多数生产环境默认关闭短标签，导致整个文件被当成纯文本输出，就白屏了。
排查命令：
php -i | grep short_open_tag如果显示 Off，两个选择：一是把源码里所有<?改成<?php，一劳永逸；二是在 php.ini 里打开short_open_tag = On，但这会影响服务器上所有站点，不推荐。另外检查 data 目录是否存在且可写，前面部署章节提过，PHP 不会自动建目录，目录不存在时写文件失败，表现也是静默白屏。最后再确认 display_errors 是否关闭，如果关闭了，把 PHP 错误日志打开：
ini_set('display_errors', 0); ini_set('log_errors', 1); error_reporting(E_ALL);然后去/var/log/php-fpm/error.log看具体报错。白屏问题九成是环境配置问题，不是代码问题，先把环境查清楚再动代码。
5.4 现象：浏览器直接访问消息文件，聊天记录全被下载
这是一个数据泄露级别的坑。访问/data/messages.json直接返回完整聊天内容，原因是消息文件放在 Web 根目录下，且 Nginx 没有做拦截，json 文件被当成静态文件直接服务了。
解决分两步走。第一步是 Nginx 配置里加拦截规则，就是第 3 章那段location ~ /data/ { deny all; return 404; }。第二步是调整源码里存储路径，把 data 目录从 Web 根目录移出去，放到 Web 根之外的路径，比如/var/www/chatroom_data/，然后在源码里改成：
$dataDir = '/var/www/chatroom_data';这是根治方案，因为就算 Nginx 配置失效，Web 根目录外路径也无法被 HTTP 直接访问。第二个方案是给消息文件换扩展名，改成.php，文件开头加一段exit;，这样即使被访问也只会执行退出语句，不会泄露内容，但这是兜底方案，不如目录外移干净。
5.5 现象：在线人数一多，服务器 CPU 飙升，页面响应变慢
轮询每 2 秒一次，20 个人在线就是每秒 10 个请求，每个请求都全量读取并解析整个消息文件。文件只要到几百 KB，CPU 就明显扛不住。这是一个典型的「文件越大、每个请求越慢、越慢用户越刷新、刷新越多请求」的恶性循环。
解决有三个抓手。第一个是开增量拉取，前端传last_id，后端只返回自该 ID 之后的新消息，这是降本最明显的一招。第二个是把轮询间隔从 1000ms 调到 2000ms 以上，单文件场景下用户感知不到 1 秒的延迟差异，但服务器负载直接减半。第三个是限制历史消息返回条数，轮询接口默认只返回最近 100 条，更老的消息走独立的 history 接口按需加载。
这三个都做了之后，20 人同时在线对单文件版完全无压力。如果还是扛不住，说明场景已经超出单文件版的边界，下一步不是继续在文件上优化，而是做第 6 章的迁移。
6. 从单文件到可用系统：数据迁移到 SQLite 与轮询升级 SSE
6.1 把文件里的历史消息迁到 SQLite：保留数据的一键脚本
单文件版跑了一段时间后，消息文件里攒了几千条记录，决定升级成 SQLite 方案时，最关心的就是历史数据别丢。迁移脚本不复杂，核心是读 JSON 写库：
<?php // migrate.php — 把 JSON 消息迁移到 SQLite $dataFile = __DIR__ . '/data/msg_default.json'; $messages = json_decode(file_get_contents($dataFile), true); $db = new PDO('sqlite:' . __DIR__ . '/chat.db'); $db->exec('CREATE TABLE IF NOT EXISTS messages ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, text TEXT NOT NULL, time TEXT NOT NULL )'); $stmt = $db->prepare('INSERT INTO messages (name, text, time) VALUES (?, ?, ?)'); foreach ($messages as $msg) { $stmt->execute([$msg['name'], $msg['text'], $msg['time']]); } echo "迁移完成：共迁移 " . count($messages) . " 条消息\n";迁移之前先备份原 JSON 文件，这是规矩。脚本执行完后，验证一下SELECT COUNT(*) FROM messages和原文件条数是否一致。SQLite 相比文件的优势在于并发写有数据库级的锁管理，读多写少的聊天场景下，SQLite 能稳定扛住比纯文件高一个量级的并发。当前端轮询接口改成从这个库里查数据时，增量拉取可以写成SELECT * FROM messages WHERE id > ?，天然支持，不用再维护 last_id 的解析逻辑。
6.2 把轮询改成 SSE：推送延迟降下来的最小改动
如果不想上 WebSocket，又想比轮询实时性更好，Server-Sent Events（SSE）是单文件版最平滑的升级路径。SSE 是 HTTP 长连接，服务端可以主动推消息，前端用 EventSource 接口接收。改造分两端，先说后端：
<?php // sse.php — SSE 推送端点 header('Content-Type: text/event-stream'); header('Cache-Control: no-cache'); header('Connection: keep-alive'); $lastId = isset($_GET['last_id']) ? (int)$_GET['last_id'] : 0; $db = new PDO('sqlite:' . __DIR__ . '/chat.db'); while (true) { $stmt = $db->prepare('SELECT * FROM messages WHERE id > ? ORDER BY id ASC LIMIT 50'); $stmt->execute([$lastId]); $rows = $stmt->fetchAll(PDO::FETCH_ASSOC); foreach ($rows as $row) { echo "id: {$row['id']}\n"; echo "data: " . json_encode($row, JSON_UNESCAPED_UNICODE) . "\n\n"; $lastId = $row['id']; } ob_flush(); flush(); sleep(2); }后端这个while循环每 2 秒查一次数据库，有新消息就立刻推给前端，没有就继续循环。注意sleep(2)不能省，否则会空转把 CPU 烧光。前端改动更小：
const es = new EventSource('/sse.php?last_id=0'); es.onmessage = (e) => { const msg = JSON.parse(e.data); // 追加到聊天窗口 };SSE 省去了每次轮询的 HTTP 请求开销，延迟接近实时，但代价是每个连接会长期占住一个 PHP-FPM worker，并发上限受进程池大小限制。适用场景是 30 人以内的小聊天室，并发再大就得考虑常驻内存方案了。升级完成后，旧的轮询接口可以保留作为兼容降级，前端监测到 EventSource 连接失败时自动切回轮询，这是比较稳妥的做法。
做完这些改造，回头看这个单文件版聊天室，最值得说的经验是：文件存储方案的核心不是文件，而是锁和边界。锁没做好，并发一高就丢数据；边界没认清，场景一变大就崩盘。先用最小方案跑通，再用锁和滚动清理守住稳定性，最后在数据量逼近上限时果断迁移，这条路每一步都有明确依据。希望这篇笔记能把你的聊天室从一个 ZIP 包变成一个真正能用的工具，少走我当年踩过的那些坑。希望帮到你。
本文还有配套的精品资源，点击获取
