简介这份 PHP 在线聊天室源码面向想快速搭建轻量聊天页面的开发者与 PHP 初学者采用单文件、无数据库设计省去建库建表与环境配置上传到支持 PHP 的服务器即可运行适合临时交流、课堂演示或测试环境使用。压缩包仅 8KB共 1 个文件即核心 chat.php属于纯 PHP 源码集中承载请求处理、聊天记录暂存、在线用户展示与页面输出结构紧凑便于通读。源码通过轮询等方式实现消息即时传递聊天内容可借助服务端内存或文件暂存并提供在线用户列表与字体样式自定义且声明兼容 PHP5 与 PHP7。已有 1879 人学习读者可从中理解无数据库会话状态维护、前后端消息更新与单文件应用的取舍也能参考其实现思路改造成小型临时聊天工具单文件结构对后续扩展和维护的限制也值得注意。1. 从临时活动页到内网值班室单文件聊天室能扛住什么PHP 在线聊天室源码 单文件 无数据库版听起来像是把聊天功能塞进一个 index.php 就完事真正拿到压缩包第一反应往往是——这东西到底能不能在普通虚拟主机上跑起来。它解决的不是“做一个大型 IM”而是短周期、小范围、低运维的实时文字沟通临时活动页挂一个聊天窗口、内网培训时让学员提问、值班室放一个不用登录的留言板。资源形态决定了它适合谁只有一个 PHP 文件、消息落盘、不用建库上传即用也决定了它不适合谁高并发、强一致、长期归档、需要审计和权限分级的场景别硬扛。单文件版的优势是部署路径短代价是存储、并发和安全边界都压在同一个入口里。拿到包后先别急着发链接先把请求分流、数据文件位置和写锁方式看清楚再决定把它放在哪台机器上。2. 拆开单文件请求分流、JSON 落盘与 flock 的协作方式单文件不等于简单。所有逻辑挤在一个入口文件里读源码的第一件事不是从上往下逐行看而是先找请求分流页面请求走哪条分支发消息走哪条分支拉消息走哪条分支。无数据库也不等于没有存储消息最终一定会落到某个可写文件里常见的是 JSON 数组、NDJSON 行文本或者一个被改造成“伪数据库”的文本文件。先把这个存储位置和读写方式找出来后面的部署、权限、并发排查才有落脚点。2.1 一个 index.php 里的三段式请求分流常见单文件聊天室会在入口顶部读$_GET[action]或$_POST[action]把请求分成三类默认输出 HTML 页面、send写消息、fetch读消息。有的包用?actsend有的用?dopost名字不同结构差不多。拿到源码后先搜action、messages、file_put_contents这三个词基本能定位接口名和数据文件路径。下面这段是典型骨架action 名称要以你包里的分支为准不要直接照搬覆盖原文件。?php // 典型单文件聊天室的入口骨架action 名称以你包里的分支为准 $dataFile __DIR__ . /data/messages.json; $maxMessages 200; $action $_GET[action] ?? ; if ($action send) { // 只接受 POST减少被随意刷接口的概率 if ($_SERVER[REQUEST_METHOD] ! POST) { http_response_code(405); exit(json_encode([ok false, error method])); } // 写消息逻辑放在 2.3 exit; } if ($action fetch) { // 读消息逻辑放在 4.2 exit; } // 没有 action 时输出聊天室页面 header(Content-Type: text/html; charsetutf-8); readfile(__DIR__ . /chat.html); // 有些包直接内联 HTML没有这个文件这段骨架的价值在于把“页面”和“接口”分开看。$dataFile是消息落盘位置必须可写$maxMessages控制保留条数直接决定 JSON 文件会不会无限膨胀action是前端和 PHP 之间的约定改名前端请求也要同步改。readfile只是示例很多单文件版会把 HTML 直接写在?后面这种情况下页面和接口共用一个入口改代码时更要小心别把输出头弄乱。json_encode在出错时返回false如果接口没有检查前端会收到空响应看起来像“聊天室死了”实际是数据文件里出现了非法 UTF-8 或半截 JSON。注意先搜action、messages、file_put_contents三个词能快速判断包里的接口名和存储路径。请求分流还要看一个细节发消息是 GET 还是 POST。单文件版为了省事常见 GET 拼参数浏览器地址栏会留下消息内容刷新还可能重复发送。能改就改成 POST前端用fetch的body传FormData或URLSearchParams。如果不想动源码至少在前端发送后清空输入框并在服务端加一个最小间隔限制比如同一 IP 两秒内只接受一条。这个限制不需要数据库用 session 或临时文件都能做但会增加一点复杂度。我的建议是小范围用先保证消息不丢、不乱码、不被注入再考虑限流。2.2 无数据库存储选型JSON 数组、NDJSON 与 SQLite 的边界单文件聊天室常见的存储方式有三种选型时不要只看“能不能用”要看“读多还是写多、消息保留多少、并发有多高”。JSON 数组适合消息量几百到几千条、读多写少的小房间NDJSON 每行一条 JSON追加写很舒服但删除旧消息和按 id 过滤要全量扫SQLite 是单文件数据库部署也简单但它依赖pdo_sqlite扩展严格说已经不是“无数据库版”。下面这张表是我核对这类源码时常用的判断依据。存储方式写入动作读取动作适合场景主要坑JSON 数组全量读、改、重写全量解码后过滤消息几百条、单人维护并发写必须加锁文件会越写越大NDJSON 行文本追加一行逐行解析写多读少、只追加删除旧消息麻烦半行写入会坏SQLite 单文件事务插入SQL 查询需要分页、检索需要扩展不能算纯无数据库分隔符文本追加或重写按分隔符切极简演示消息里出现分隔符就乱JSON 数组的好处是可读、可备份、可直接用编辑器打开看结构适合单文件版“上传即用”的定位。它的边界也很清楚每次发消息都要把整个文件读进内存改完再写回去。消息到几万条时单次请求的 I/O 和 JSON 解码成本会明显上升前端轮询也会变慢。常见做法是保留最近 200 到 500 条旧消息定期备份后删掉如果确实需要长期归档应该把消息按天拆文件或者换成 SQLite而不是继续往一个 JSON 里塞。NDJSON 的追加写性能更好但读的时候要处理“最后一行可能写了一半”的情况单文件版如果没有flock翻车概率不低。2.3 写锁与读锁flock 放在读改写里面消息写丢是这类单文件聊天室最容易出的问题。两个人同时发消息A 读到 10 条B 也读到 10 条A 写回 11 条B 再写回 11 条最后只剩一条。根因不是 PHP 性能差而是“读—改—写”没有放在同一个排他锁里。正确做法是用fopen($dataFile, c)打开文件先flock($fp, LOCK_EX)在锁内读完、改完、重写再flock($fp, LOCK_UN)。注意c不会截断文件写之前要ftruncate加rewind否则旧内容会残留。$fp fopen($dataFile, c); if (!$fp) { http_response_code(500); exit(data file not writable); } flock($fp, LOCK_EX); $raw stream_get_contents($fp); $list json_decode($raw, true); if (!is_array($list)) { $list []; } $maxId 0; foreach ($list as $item) { $maxId max($maxId, (int)($item[id] ?? 0)); } $text trim((string)($_POST[text] ?? )); $user trim((string)($_POST[user] ?? 匿名)); $msg [ id $maxId 1, user mb_substr($user, 0, 20, UTF-8), text mb_substr($text, 0, 500, UTF-8), time time(), ]; $list[] $msg; $list array_slice($list, -$maxMessages); ftruncate($fp, 0); rewind($fp); fwrite($fp, json_encode($list, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES)); fflush($fp); flock($fp, LOCK_UN); fclose($fp); header(Content-Type: application/json; charsetutf-8); echo json_encode([ok true, id $msg[id]], JSON_UNESCAPED_UNICODE);这段代码里LOCK_EX是排他锁写的时候别人不能同时写stream_get_contents从当前指针读fopen后指针在开头所以能读到全量ftruncate($fp, 0)清空旧内容rewind把指针拉回开头再写fflush让内容尽快落盘array_slice($list, -$maxMessages)只保留尾部若干条。参数上昵称截 20 个字符、消息截 500 个字符是为了防止有人粘贴一大段文本把 JSON 撑爆mb_substr依赖mbstring没装这个扩展时用substr会把中文切坏出现半个字符json_encode直接失败。读端也要加LOCK_SH共享锁避免读到写了一半的文件。锁不是玄学关键是位置先锁再读读完再改改完再写最后释放。3. 上传后先别发链接PHP 环境、目录权限与四步首跑单文件聊天室最容易让人放松警惕的地方是“只有一个文件传上去就能用”。实际部署时PHP 版本、扩展、目录权限、数据文件位置任何一个不对页面都能打开但消息就是发不出去。更麻烦的是有些包把数据文件放在 Web 根目录下浏览器直接访问data/messages.json就能看到全部聊天记录。上传后先别发链接按环境、权限、首跑验证三步走一遍能省掉很多事后排查。3.1 PHP 版本与扩展核对这类源码通常不会声明太高的版本要求PHP 7.4 以上一般能跑PHP 8.x 更稳但要注意each()、create_function()这类老函数在 8.x 已经移除。拿到包后先在本地或目标机器上跑一遍php -v再看json、mbstring、session三个扩展。json现在是内置的但老环境可能被禁用mbstring影响中文截断session有些包用来存昵称或限流。命令行检查很快php -v php -m | grep -E json|mbstring|session # 本地起一个临时服务确认单文件能独立跑 php -S 127.0.0.1:8080 -t /path/to/chat-roomphp -v看版本php -m看扩展php -S起内置服务器。-t指定项目目录访问http://127.0.0.1:8080/index.php。如果页面能打开但发消息返回 500先看 PHP 错误日志不要猜。常见原因是data目录不存在、不可写或者json_encode遇到非法 UTF-8 返回false。本地验证通过后再上传能排除一大半环境差异。线上如果用的是虚拟主机确认它允许fopen、flock、file_put_contents有些主机禁用了这些函数单文件版会直接失效。3.2 数据目录权限不要 777 整站Linux 下最常见的错误是把整个站点目录设成 777图省事结果任何脚本都能改任何文件。正确做法是只给数据目录写权限站点目录 755数据目录 775消息文件 664属主是 Web 用户或 Web 用户所在组。假设 Web 用户是www-data项目在/var/www/chat可以这样收权限# 站点代码只读数据目录给 Web 用户写 chown -R root:www-data /var/www/chat find /var/www/chat -type d -exec chmod 755 {} \; find /var/www/chat -type f -exec chmod 644 {} \; mkdir -p /var/www/chat/data chown www-data:www-data /var/www/chat/data chmod 775 /var/www/chat/data # 如果消息文件已经存在单独给它写权限 touch /var/www/chat/data/messages.json chown www-data:www-data /var/www/chat/data/messages.json chmod 664 /var/www/chat/data/messages.jsonchown把属主和属组分清find批量收权限data目录单独放开。775和664的意思是属主和同组可写其他用户只读比 777 安全。Windows 下没有chmod要在站点目录的安全设置里给应用程序池身份或IUSR加“修改”权限只加data目录不要给整个盘。还有一种情况主机面板把 PHP 运行在 CGI 模式文件属主和 Web 用户不一致这时chown后仍然写不进去需要看面板的“文件所有者”设置。权限问题不要靠“全开 777”解决那是给自己留后悔药。3.3 四步首跑验证静态页、写入、读取、清理首跑不要只用浏览器点两下浏览器缓存和前端脚本会掩盖接口问题。用curl按四步走页面返回 200、发送接口返回 JSON、读取接口能看到刚发的消息、清理数据文件后能重新创建。下面命令里的action和参数名要换成你包里的实际命名last_id如果源码没有就删掉。# 1. 页面是否正常 curl -i http://127.0.0.1:8080/index.php # 2. 发一条消息注意中文用 --data-urlencode curl -i -X POST http://127.0.0.1:8080/index.php?actionsend \ --data-urlencode user测试员 \ --data-urlencode text第一条消息 # 3. 读消息last_id0 表示全量 curl -s http://127.0.0.1:8080/index.php?actionfetchlast_id0 # 4. 备份后清空数据文件再发一条确认能自动重建 cp data/messages.json data/messages.json.bak : data/messages.json curl -s -X POST http://127.0.0.1:8080/index.php?actionsend \ --data-urlencode user测试员 \ --data-urlencode text重建测试第一步看响应头里的Content-Type和状态码页面正常不代表接口正常。第二步看返回体是不是 JSON如果返回 HTML 错误页说明action分支没进对或者写文件失败。第三步看消息数组里有没有刚发的记录last_id过滤是否生效。第四步验证“空文件也能写”很多源码在文件为空时json_decode返回null如果没有做is_array兜底第一条消息就会写不进去。清理测试数据前先备份尤其是线上已经有聊天记录的时候。四步都过了再把链接发出去。提示如果主机不允许php -S本地可以用任意 PHP 环境跑一遍重点看数据文件是否自动创建、权限是否匹配。4. 轮询的细账last_id 增量、间隔参数与消息上限单文件聊天室没有 WebSocket 服务端前端拿新消息基本靠轮询。轮询不是越勤越好间隔太短请求把主机打满间隔太长聊天像留言板。更常见的问题是每次全量拉取消息文件越大页面越卡。把last_id增量、超时控制和消息上限三件事配好单文件版在小范围场景里完全够用。4.1 前端 fetch 轮询的最小闭环前端轮询要解决四个问题多久拉一次、拉不到怎么办、请求超时怎么停、页面切到后台要不要继续。下面这段是常见的fetch闭环用setTimeout递归而不是setInterval避免上一次请求没回来又发下一次造成请求堆积。lastId是游标只拉比它新的消息AbortController控制单次超时页面隐藏时暂停回来再拉。const state { lastId: 0, timer: null, interval: 2000, timeout: 5000, running: false, }; async function pull() { if (!state.running) return; const url ?actionfetchlast_id${encodeURIComponent(state.lastId)}; const ctrl new AbortController(); const timer setTimeout(() ctrl.abort(), state.timeout); try { const res await fetch(url, { signal: ctrl.signal, cache: no-store }); if (!res.ok) throw new Error(HTTP ${res.status}); const data await res.json(); (data.messages || []).forEach(renderMessage); if (typeof data.last_id number) { state.lastId data.last_id; } } catch (err) { // 网络抖动或服务端 500 时下一轮继续不阻塞页面 console.warn(poll failed, err.message); } finally { clearTimeout(timer); if (state.running) { state.timer setTimeout(pull, state.interval); } } } function startPolling() { if (state.running) return; state.running true; pull(); } document.addEventListener(visibilitychange, () { if (document.hidden) { state.running false; clearTimeout(state.timer); } else { startPolling(); } });state.interval是两轮请求之间的间隔state.timeout是单次请求超时cache: no-store防止浏览器缓存旧消息data.last_id由服务端返回前端不要自己猜。renderMessage里要用textContent写文本不要用innerHTML这一点在第 5 章会展开。页面隐藏时停掉轮询能明显减少后台标签页的请求量。如果聊天室要支持多人同时在线间隔可以放到 3000 到 5000 毫秒文字聊天不需要毫秒级同步。4.2 用 last_id 做增量拉取别每次全量读 JSON服务端读消息也要加共享锁并且只返回比last_id大的记录。下面这段 PHP 是读端示例$dataFile和$maxMessages沿用前面的配置。last_id从查询串取整过滤时用(int)$m[id] $lastId返回last_id给前端做下一次游标。如果消息列表为空就返回前端传上来的last_id避免游标回退。$fp fopen($dataFile, c); if (!$fp) { http_response_code(500); exit(json_encode([ok false, error data])); } flock($fp, LOCK_SH); $raw stream_get_contents($fp); flock($fp, LOCK_UN); fclose($fp); $list json_decode($raw, true); if (!is_array($list)) { $list []; } $lastId (int)($_GET[last_id] ?? 0); $new array_values(array_filter($list, function ($m) use ($lastId) { return (int)($m[id] ?? 0) $lastId; })); $nextId $lastId; if (count($list) 0) { $tail end($list); $nextId (int)($tail[id] ?? $lastId); } header(Content-Type: application/json; charsetutf-8); echo json_encode([ messages $new, last_id $nextId, ], JSON_UNESCAPED_UNICODE);LOCK_SH是共享锁多个读请求可以同时读但写请求会等读完立刻释放不要拿着锁做 JSON 解码和输出。array_filter过滤旧消息array_values重置索引避免json_encode输出成对象。end($list)取最后一条的 id 作为下一次游标前提是消息按 id 递增追加。如果源码没有last_id机制前端每次全量拉消息一多就会慢可以按这个思路补但要注意前后端字段名一致。参数上last_id0表示全量适合首次加载后续只传上次返回的last_id。4.3 间隔、超时与保留条数的参数表轮询参数没有统一标准要看在线人数和主机能力。下面这张表是我在小范围场景里常用的起点不是硬性规定。消息保留条数太少新进来的人看不到上下文太多JSON 文件变大每次写都要全量重写。间隔太短请求数上去了太长对话不连贯。先按中间值跑一天再看访问日志和文件大小调整。参数常用起点调小的后果调大的后果轮询间隔2000 到 3000 毫秒请求数上升主机 CPU 吃紧消息延迟明显像留言板单次超时5000 毫秒网络稍慢就中断重试变多异常请求挂太久堆积消息保留200 到 500 条上下文太短新人看不到前文JSON 变大写入变慢单条长度500 字符长消息被截断文件膨胀前端渲染卡昵称长度20 字符重名多辨识度低布局被撑坏这些参数要一起看。比如把间隔调到 1000 毫秒但保留 5000 条消息每次读都全量解码主机很快会吃不消。反过来保留 50 条、间隔 5000 毫秒聊天体验又太差。我的习惯是先把保留条数压到 200间隔 3000 毫秒跑一天看messages.json大小和访问日志里的fetch次数再决定要不要调。单文件版的容量边界不在 PHP而在文件 I/O 和轮询请求数。注意轮询接口不要输出 HTML 错误页。前端res.json()解析失败时页面会表现为“消息不更新”实际是服务端报了警告。5. 避坑排查写丢消息、中文乱码、XSS 与轮询堆积单文件聊天室的问题大多不是“功能不会写”而是边界没处理并发写、编码、输出转义、轮询堆积、时间显示。下面五条是这类源码里出现频率最高的翻车点每条按“现象、原因、解决”拆开。排查时先看数据文件本身再看接口返回最后看前端渲染顺序不要反。5.1 消息写丢flock 加在哪一步现象两个人几乎同时发消息刷新后只剩一条或者消息 id 重复前端列表里出现两条相同记录。原因通常有两种一是“先读后锁”代码先file_get_contents读消息再file_put_contents写回锁只加在写那一下两个请求都读到了旧列表二是没有ftruncate新内容比旧内容短时文件尾部残留旧 JSON解码直接失败。解决方式是把fopen、flock(LOCK_EX)、读、改、ftruncate、rewind、写、fflush、释放锁放在同一个代码块里中间不要提前fclose。读端用LOCK_SH避免读到写了一半的文件。如果源码用的是file_put_contents($file, $json, LOCK_EX)它只能保证单次写不交错不能保证“读—改—写”整体原子并发下仍然会丢。遇到这种写法要么改成fopen加锁要么在写之前重新读一遍并合并。5.2 中文变问号JSON_UNESCAPED_UNICODE 与响应头现象页面能发英文中文发出去变成\u4f60\u597d或者直接显示问号更严重的接口返回空白前端报 JSON 解析错误。原因有三类json_encode默认把中文转成 Unicode 转义虽然浏览器能解析但直接看文件不直观响应头缺少charsetutf-8浏览器按默认编码猜数据文件带 BOM 或被编辑器保存成 GBKjson_decode返回null。解决方式是输出时加JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES响应头写Content-Type: application/json; charsetutf-8数据文件用无 BOM 的 UTF-8 保存。如果json_encode返回false用json_last_error_msg()看原因常见是非法 UTF-8。昵称和消息入库前用mb_substr截断不要用substr切中文。还有一个小坑前端fetch没设置headers时POST 表单默认编码可能不是 UTF-8用FormData或URLSearchParams更稳。5.3 聊天室变成弹窗工厂输出转义与 CSP 底线现象有人把昵称改成带onerror的图片标签或者消息里塞一段脚本页面开始弹窗、跳转甚至读取本地存储。原因很直接前端用innerHTML拼接消息服务端也没有做输出转义。单文件版经常为了“支持简单表情”保留 HTML这就把 XSS 口子留大了。解决分两层前端渲染用textContent写昵称和消息不要拼 HTML服务端在存入和输出时做长度限制必要时用htmlspecialchars($text, ENT_QUOTES, UTF-8)转义。CSP 可以作为底线在 PHP 入口加响应头限制脚本来源header(Content-Security-Policy: default-src self; script-src self unsafe-inline; style-src self unsafe-inline; img-src self data:; connect-src self; object-src none; base-uri none);default-src self限制外部资源object-src none禁掉插件base-uri none防止 base 标签劫持。单文件版通常内联脚本所以script-src里带unsafe-inline防护有限真正管用的还是textContent和输入长度限制。不要为了“支持富文本”把消息直接塞进innerHTML那是给自己挖坑。如果必须支持链接单独做白名单解析只允许http、https并且加relnoopener noreferrer。5.4 轮询把 CPU 打满看访问日志和文件大小现象页面开着不动主机 CPU 却一直高访问日志里全是fetch请求消息文件越来越大打开聊天室要等好几秒。原因通常是setInterval间隔太短、上一次请求没回来就发下一次、每次全量读 JSON、消息没有保留上限。解决方式前端改成递归setTimeout等响应回来再排下一轮页面隐藏时暂停服务端加last_id增量过滤写端用array_slice保留最近 N 条。排查时先看数据文件大小超过几 MB 就说明保留条数没生效再看访问日志里同一 IP 的请求频率如果一秒好几次前端定时器肯定写错了。单文件版不要追求“秒级同步”文字聊天 2 到 5 秒拉一次足够。主机性能有限时把轮询间隔调大比换服务器更直接。5.5 时间对不上时区与时间戳存储现象消息时间比本地时间差 8 小时或者不同人看到的时间不一样。原因通常是服务端用date(H:i:s)存了格式化字符串而 PHP 时区没设前端又用本地时间显示两边基准不一致。解决方式是统一存 Unix 时间戳写端用time()前端用Intl.DateTimeFormat按浏览器本地时区格式化。PHP 入口可以显式设date_default_timezone_set(Asia/Shanghai)但存储仍然建议用时间戳展示层再转换。这样换服务器、换时区都不会把历史消息时间弄乱。如果源码已经存了格式化字符串迁移时用strtotime转一遍别直接混用。时间问题不影响聊天功能但排查起来很烦尤其是跨时区协作时。提示排查顺序固定为“数据文件是否合法 JSON → 接口返回状态和响应头 → 前端控制台报错”不要一上来就改前端。6. 把单文件当小系统维护并发验证、备份与迁移检查单文件聊天室上线后最容易被忽略的是维护动作。消息文件既是数据又是配置改错一行就可能让整个房间静默。我的习惯是每次改完代码先做两件事并发写入验证和备份恢复验证。并发验证不用复杂工具二十个请求同时打进去看 id 是否连续、消息有没有丢备份验证则是复制一份数据文件清空原文件再恢复确认页面能正常读出历史。下面这段命令用xargs并发发消息跑完直接检查 JSON 里的 id。# 20 个并发请求观察是否有 500 和消息丢失 seq 1 20 | xargs -P 20 -I{} curl -s -o /dev/null -w %{http_code}\n \ http://127.0.0.1:8080/index.php?actionsend \ --data-urlencode user压测{} \ --data-urlencode texthello-{} # 检查消息条数、最大 id 和 JSON 是否合法 php -r $l json_decode(file_get_contents(data/messages.json), true); if (!is_array($l)) { fwrite(STDERR, invalid json\n); exit(1); } $ids array_map(fn($m) (int)$m[id], $l); printf(count%d max%d unique%d\n, count($l), max($ids), count(array_unique($ids))); -P 20控制并发数--data-urlencode处理中文和空格-w %{http_code}只看状态码。跑完看输出里有没有非 200再看count、max、unique三个数是否对得上。如果count小于请求数说明写锁没覆盖读改写如果unique小于count说明 id 生成有并发问题。备份时不要直接cp正在写的文件先读锁复制或者低峰期操作。迁移检查我一般看四项PHP 版本、data目录权限、消息文件 JSON 合法性、轮询接口返回的last_id是否连续。这四项过了再换机器或升级环境心里才有底。血泪经验是只改前端轮询间隔、不改服务端保留条数JSON 会越读越大页面首屏从一秒变成三秒。从那以后我每次部署这类单文件聊天室都先跑一遍并发写入和文件大小检查再开页面。希望帮到你。本文还有配套的精品资源点击获取
简介这份 PHP 在线聊天室源码面向想快速搭建轻量聊天页面的开发者与 PHP 初学者采用单文件、无数据库设计省去建库建表与环境配置上传到支持 PHP 的服务器即可运行适合临时交流、课堂演示或测试环境使用。压缩包仅 8KB共 1 个文件即核心 chat.php属于纯 PHP 源码集中承载请求处理、聊天记录暂存、在线用户展示与页面输出结构紧凑便于通读。源码通过轮询等方式实现消息即时传递聊天内容可借助服务端内存或文件暂存并提供在线用户列表与字体样式自定义且声明兼容 PHP5 与 PHP7。已有 1879 人学习读者可从中理解无数据库会话状态维护、前后端消息更新与单文件应用的取舍也能参考其实现思路改造成小型临时聊天工具单文件结构对后续扩展和维护的限制也值得注意。1. 从临时活动页到内网值班室单文件聊天室能扛住什么PHP 在线聊天室源码 单文件 无数据库版听起来像是把聊天功能塞进一个 index.php 就完事真正拿到压缩包第一反应往往是——这东西到底能不能在普通虚拟主机上跑起来。它解决的不是“做一个大型 IM”而是短周期、小范围、低运维的实时文字沟通临时活动页挂一个聊天窗口、内网培训时让学员提问、值班室放一个不用登录的留言板。资源形态决定了它适合谁只有一个 PHP 文件、消息落盘、不用建库上传即用也决定了它不适合谁高并发、强一致、长期归档、需要审计和权限分级的场景别硬扛。单文件版的优势是部署路径短代价是存储、并发和安全边界都压在同一个入口里。拿到包后先别急着发链接先把请求分流、数据文件位置和写锁方式看清楚再决定把它放在哪台机器上。2. 拆开单文件请求分流、JSON 落盘与 flock 的协作方式单文件不等于简单。所有逻辑挤在一个入口文件里读源码的第一件事不是从上往下逐行看而是先找请求分流页面请求走哪条分支发消息走哪条分支拉消息走哪条分支。无数据库也不等于没有存储消息最终一定会落到某个可写文件里常见的是 JSON 数组、NDJSON 行文本或者一个被改造成“伪数据库”的文本文件。先把这个存储位置和读写方式找出来后面的部署、权限、并发排查才有落脚点。2.1 一个 index.php 里的三段式请求分流常见单文件聊天室会在入口顶部读$_GET[action]或$_POST[action]把请求分成三类默认输出 HTML 页面、send写消息、fetch读消息。有的包用?actsend有的用?dopost名字不同结构差不多。拿到源码后先搜action、messages、file_put_contents这三个词基本能定位接口名和数据文件路径。下面这段是典型骨架action 名称要以你包里的分支为准不要直接照搬覆盖原文件。?php // 典型单文件聊天室的入口骨架action 名称以你包里的分支为准 $dataFile __DIR__ . /data/messages.json; $maxMessages 200; $action $_GET[action] ?? ; if ($action send) { // 只接受 POST减少被随意刷接口的概率 if ($_SERVER[REQUEST_METHOD] ! POST) { http_response_code(405); exit(json_encode([ok false, error method])); } // 写消息逻辑放在 2.3 exit; } if ($action fetch) { // 读消息逻辑放在 4.2 exit; } // 没有 action 时输出聊天室页面 header(Content-Type: text/html; charsetutf-8); readfile(__DIR__ . /chat.html); // 有些包直接内联 HTML没有这个文件这段骨架的价值在于把“页面”和“接口”分开看。$dataFile是消息落盘位置必须可写$maxMessages控制保留条数直接决定 JSON 文件会不会无限膨胀action是前端和 PHP 之间的约定改名前端请求也要同步改。readfile只是示例很多单文件版会把 HTML 直接写在?后面这种情况下页面和接口共用一个入口改代码时更要小心别把输出头弄乱。json_encode在出错时返回false如果接口没有检查前端会收到空响应看起来像“聊天室死了”实际是数据文件里出现了非法 UTF-8 或半截 JSON。注意先搜action、messages、file_put_contents三个词能快速判断包里的接口名和存储路径。请求分流还要看一个细节发消息是 GET 还是 POST。单文件版为了省事常见 GET 拼参数浏览器地址栏会留下消息内容刷新还可能重复发送。能改就改成 POST前端用fetch的body传FormData或URLSearchParams。如果不想动源码至少在前端发送后清空输入框并在服务端加一个最小间隔限制比如同一 IP 两秒内只接受一条。这个限制不需要数据库用 session 或临时文件都能做但会增加一点复杂度。我的建议是小范围用先保证消息不丢、不乱码、不被注入再考虑限流。2.2 无数据库存储选型JSON 数组、NDJSON 与 SQLite 的边界单文件聊天室常见的存储方式有三种选型时不要只看“能不能用”要看“读多还是写多、消息保留多少、并发有多高”。JSON 数组适合消息量几百到几千条、读多写少的小房间NDJSON 每行一条 JSON追加写很舒服但删除旧消息和按 id 过滤要全量扫SQLite 是单文件数据库部署也简单但它依赖pdo_sqlite扩展严格说已经不是“无数据库版”。下面这张表是我核对这类源码时常用的判断依据。存储方式写入动作读取动作适合场景主要坑JSON 数组全量读、改、重写全量解码后过滤消息几百条、单人维护并发写必须加锁文件会越写越大NDJSON 行文本追加一行逐行解析写多读少、只追加删除旧消息麻烦半行写入会坏SQLite 单文件事务插入SQL 查询需要分页、检索需要扩展不能算纯无数据库分隔符文本追加或重写按分隔符切极简演示消息里出现分隔符就乱JSON 数组的好处是可读、可备份、可直接用编辑器打开看结构适合单文件版“上传即用”的定位。它的边界也很清楚每次发消息都要把整个文件读进内存改完再写回去。消息到几万条时单次请求的 I/O 和 JSON 解码成本会明显上升前端轮询也会变慢。常见做法是保留最近 200 到 500 条旧消息定期备份后删掉如果确实需要长期归档应该把消息按天拆文件或者换成 SQLite而不是继续往一个 JSON 里塞。NDJSON 的追加写性能更好但读的时候要处理“最后一行可能写了一半”的情况单文件版如果没有flock翻车概率不低。2.3 写锁与读锁flock 放在读改写里面消息写丢是这类单文件聊天室最容易出的问题。两个人同时发消息A 读到 10 条B 也读到 10 条A 写回 11 条B 再写回 11 条最后只剩一条。根因不是 PHP 性能差而是“读—改—写”没有放在同一个排他锁里。正确做法是用fopen($dataFile, c)打开文件先flock($fp, LOCK_EX)在锁内读完、改完、重写再flock($fp, LOCK_UN)。注意c不会截断文件写之前要ftruncate加rewind否则旧内容会残留。$fp fopen($dataFile, c); if (!$fp) { http_response_code(500); exit(data file not writable); } flock($fp, LOCK_EX); $raw stream_get_contents($fp); $list json_decode($raw, true); if (!is_array($list)) { $list []; } $maxId 0; foreach ($list as $item) { $maxId max($maxId, (int)($item[id] ?? 0)); } $text trim((string)($_POST[text] ?? )); $user trim((string)($_POST[user] ?? 匿名)); $msg [ id $maxId 1, user mb_substr($user, 0, 20, UTF-8), text mb_substr($text, 0, 500, UTF-8), time time(), ]; $list[] $msg; $list array_slice($list, -$maxMessages); ftruncate($fp, 0); rewind($fp); fwrite($fp, json_encode($list, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES)); fflush($fp); flock($fp, LOCK_UN); fclose($fp); header(Content-Type: application/json; charsetutf-8); echo json_encode([ok true, id $msg[id]], JSON_UNESCAPED_UNICODE);这段代码里LOCK_EX是排他锁写的时候别人不能同时写stream_get_contents从当前指针读fopen后指针在开头所以能读到全量ftruncate($fp, 0)清空旧内容rewind把指针拉回开头再写fflush让内容尽快落盘array_slice($list, -$maxMessages)只保留尾部若干条。参数上昵称截 20 个字符、消息截 500 个字符是为了防止有人粘贴一大段文本把 JSON 撑爆mb_substr依赖mbstring没装这个扩展时用substr会把中文切坏出现半个字符json_encode直接失败。读端也要加LOCK_SH共享锁避免读到写了一半的文件。锁不是玄学关键是位置先锁再读读完再改改完再写最后释放。3. 上传后先别发链接PHP 环境、目录权限与四步首跑单文件聊天室最容易让人放松警惕的地方是“只有一个文件传上去就能用”。实际部署时PHP 版本、扩展、目录权限、数据文件位置任何一个不对页面都能打开但消息就是发不出去。更麻烦的是有些包把数据文件放在 Web 根目录下浏览器直接访问data/messages.json就能看到全部聊天记录。上传后先别发链接按环境、权限、首跑验证三步走一遍能省掉很多事后排查。3.1 PHP 版本与扩展核对这类源码通常不会声明太高的版本要求PHP 7.4 以上一般能跑PHP 8.x 更稳但要注意each()、create_function()这类老函数在 8.x 已经移除。拿到包后先在本地或目标机器上跑一遍php -v再看json、mbstring、session三个扩展。json现在是内置的但老环境可能被禁用mbstring影响中文截断session有些包用来存昵称或限流。命令行检查很快php -v php -m | grep -E json|mbstring|session # 本地起一个临时服务确认单文件能独立跑 php -S 127.0.0.1:8080 -t /path/to/chat-roomphp -v看版本php -m看扩展php -S起内置服务器。-t指定项目目录访问http://127.0.0.1:8080/index.php。如果页面能打开但发消息返回 500先看 PHP 错误日志不要猜。常见原因是data目录不存在、不可写或者json_encode遇到非法 UTF-8 返回false。本地验证通过后再上传能排除一大半环境差异。线上如果用的是虚拟主机确认它允许fopen、flock、file_put_contents有些主机禁用了这些函数单文件版会直接失效。3.2 数据目录权限不要 777 整站Linux 下最常见的错误是把整个站点目录设成 777图省事结果任何脚本都能改任何文件。正确做法是只给数据目录写权限站点目录 755数据目录 775消息文件 664属主是 Web 用户或 Web 用户所在组。假设 Web 用户是www-data项目在/var/www/chat可以这样收权限# 站点代码只读数据目录给 Web 用户写 chown -R root:www-data /var/www/chat find /var/www/chat -type d -exec chmod 755 {} \; find /var/www/chat -type f -exec chmod 644 {} \; mkdir -p /var/www/chat/data chown www-data:www-data /var/www/chat/data chmod 775 /var/www/chat/data # 如果消息文件已经存在单独给它写权限 touch /var/www/chat/data/messages.json chown www-data:www-data /var/www/chat/data/messages.json chmod 664 /var/www/chat/data/messages.jsonchown把属主和属组分清find批量收权限data目录单独放开。775和664的意思是属主和同组可写其他用户只读比 777 安全。Windows 下没有chmod要在站点目录的安全设置里给应用程序池身份或IUSR加“修改”权限只加data目录不要给整个盘。还有一种情况主机面板把 PHP 运行在 CGI 模式文件属主和 Web 用户不一致这时chown后仍然写不进去需要看面板的“文件所有者”设置。权限问题不要靠“全开 777”解决那是给自己留后悔药。3.3 四步首跑验证静态页、写入、读取、清理首跑不要只用浏览器点两下浏览器缓存和前端脚本会掩盖接口问题。用curl按四步走页面返回 200、发送接口返回 JSON、读取接口能看到刚发的消息、清理数据文件后能重新创建。下面命令里的action和参数名要换成你包里的实际命名last_id如果源码没有就删掉。# 1. 页面是否正常 curl -i http://127.0.0.1:8080/index.php # 2. 发一条消息注意中文用 --data-urlencode curl -i -X POST http://127.0.0.1:8080/index.php?actionsend \ --data-urlencode user测试员 \ --data-urlencode text第一条消息 # 3. 读消息last_id0 表示全量 curl -s http://127.0.0.1:8080/index.php?actionfetchlast_id0 # 4. 备份后清空数据文件再发一条确认能自动重建 cp data/messages.json data/messages.json.bak : data/messages.json curl -s -X POST http://127.0.0.1:8080/index.php?actionsend \ --data-urlencode user测试员 \ --data-urlencode text重建测试第一步看响应头里的Content-Type和状态码页面正常不代表接口正常。第二步看返回体是不是 JSON如果返回 HTML 错误页说明action分支没进对或者写文件失败。第三步看消息数组里有没有刚发的记录last_id过滤是否生效。第四步验证“空文件也能写”很多源码在文件为空时json_decode返回null如果没有做is_array兜底第一条消息就会写不进去。清理测试数据前先备份尤其是线上已经有聊天记录的时候。四步都过了再把链接发出去。提示如果主机不允许php -S本地可以用任意 PHP 环境跑一遍重点看数据文件是否自动创建、权限是否匹配。4. 轮询的细账last_id 增量、间隔参数与消息上限单文件聊天室没有 WebSocket 服务端前端拿新消息基本靠轮询。轮询不是越勤越好间隔太短请求把主机打满间隔太长聊天像留言板。更常见的问题是每次全量拉取消息文件越大页面越卡。把last_id增量、超时控制和消息上限三件事配好单文件版在小范围场景里完全够用。4.1 前端 fetch 轮询的最小闭环前端轮询要解决四个问题多久拉一次、拉不到怎么办、请求超时怎么停、页面切到后台要不要继续。下面这段是常见的fetch闭环用setTimeout递归而不是setInterval避免上一次请求没回来又发下一次造成请求堆积。lastId是游标只拉比它新的消息AbortController控制单次超时页面隐藏时暂停回来再拉。const state { lastId: 0, timer: null, interval: 2000, timeout: 5000, running: false, }; async function pull() { if (!state.running) return; const url ?actionfetchlast_id${encodeURIComponent(state.lastId)}; const ctrl new AbortController(); const timer setTimeout(() ctrl.abort(), state.timeout); try { const res await fetch(url, { signal: ctrl.signal, cache: no-store }); if (!res.ok) throw new Error(HTTP ${res.status}); const data await res.json(); (data.messages || []).forEach(renderMessage); if (typeof data.last_id number) { state.lastId data.last_id; } } catch (err) { // 网络抖动或服务端 500 时下一轮继续不阻塞页面 console.warn(poll failed, err.message); } finally { clearTimeout(timer); if (state.running) { state.timer setTimeout(pull, state.interval); } } } function startPolling() { if (state.running) return; state.running true; pull(); } document.addEventListener(visibilitychange, () { if (document.hidden) { state.running false; clearTimeout(state.timer); } else { startPolling(); } });state.interval是两轮请求之间的间隔state.timeout是单次请求超时cache: no-store防止浏览器缓存旧消息data.last_id由服务端返回前端不要自己猜。renderMessage里要用textContent写文本不要用innerHTML这一点在第 5 章会展开。页面隐藏时停掉轮询能明显减少后台标签页的请求量。如果聊天室要支持多人同时在线间隔可以放到 3000 到 5000 毫秒文字聊天不需要毫秒级同步。4.2 用 last_id 做增量拉取别每次全量读 JSON服务端读消息也要加共享锁并且只返回比last_id大的记录。下面这段 PHP 是读端示例$dataFile和$maxMessages沿用前面的配置。last_id从查询串取整过滤时用(int)$m[id] $lastId返回last_id给前端做下一次游标。如果消息列表为空就返回前端传上来的last_id避免游标回退。$fp fopen($dataFile, c); if (!$fp) { http_response_code(500); exit(json_encode([ok false, error data])); } flock($fp, LOCK_SH); $raw stream_get_contents($fp); flock($fp, LOCK_UN); fclose($fp); $list json_decode($raw, true); if (!is_array($list)) { $list []; } $lastId (int)($_GET[last_id] ?? 0); $new array_values(array_filter($list, function ($m) use ($lastId) { return (int)($m[id] ?? 0) $lastId; })); $nextId $lastId; if (count($list) 0) { $tail end($list); $nextId (int)($tail[id] ?? $lastId); } header(Content-Type: application/json; charsetutf-8); echo json_encode([ messages $new, last_id $nextId, ], JSON_UNESCAPED_UNICODE);LOCK_SH是共享锁多个读请求可以同时读但写请求会等读完立刻释放不要拿着锁做 JSON 解码和输出。array_filter过滤旧消息array_values重置索引避免json_encode输出成对象。end($list)取最后一条的 id 作为下一次游标前提是消息按 id 递增追加。如果源码没有last_id机制前端每次全量拉消息一多就会慢可以按这个思路补但要注意前后端字段名一致。参数上last_id0表示全量适合首次加载后续只传上次返回的last_id。4.3 间隔、超时与保留条数的参数表轮询参数没有统一标准要看在线人数和主机能力。下面这张表是我在小范围场景里常用的起点不是硬性规定。消息保留条数太少新进来的人看不到上下文太多JSON 文件变大每次写都要全量重写。间隔太短请求数上去了太长对话不连贯。先按中间值跑一天再看访问日志和文件大小调整。参数常用起点调小的后果调大的后果轮询间隔2000 到 3000 毫秒请求数上升主机 CPU 吃紧消息延迟明显像留言板单次超时5000 毫秒网络稍慢就中断重试变多异常请求挂太久堆积消息保留200 到 500 条上下文太短新人看不到前文JSON 变大写入变慢单条长度500 字符长消息被截断文件膨胀前端渲染卡昵称长度20 字符重名多辨识度低布局被撑坏这些参数要一起看。比如把间隔调到 1000 毫秒但保留 5000 条消息每次读都全量解码主机很快会吃不消。反过来保留 50 条、间隔 5000 毫秒聊天体验又太差。我的习惯是先把保留条数压到 200间隔 3000 毫秒跑一天看messages.json大小和访问日志里的fetch次数再决定要不要调。单文件版的容量边界不在 PHP而在文件 I/O 和轮询请求数。注意轮询接口不要输出 HTML 错误页。前端res.json()解析失败时页面会表现为“消息不更新”实际是服务端报了警告。5. 避坑排查写丢消息、中文乱码、XSS 与轮询堆积单文件聊天室的问题大多不是“功能不会写”而是边界没处理并发写、编码、输出转义、轮询堆积、时间显示。下面五条是这类源码里出现频率最高的翻车点每条按“现象、原因、解决”拆开。排查时先看数据文件本身再看接口返回最后看前端渲染顺序不要反。5.1 消息写丢flock 加在哪一步现象两个人几乎同时发消息刷新后只剩一条或者消息 id 重复前端列表里出现两条相同记录。原因通常有两种一是“先读后锁”代码先file_get_contents读消息再file_put_contents写回锁只加在写那一下两个请求都读到了旧列表二是没有ftruncate新内容比旧内容短时文件尾部残留旧 JSON解码直接失败。解决方式是把fopen、flock(LOCK_EX)、读、改、ftruncate、rewind、写、fflush、释放锁放在同一个代码块里中间不要提前fclose。读端用LOCK_SH避免读到写了一半的文件。如果源码用的是file_put_contents($file, $json, LOCK_EX)它只能保证单次写不交错不能保证“读—改—写”整体原子并发下仍然会丢。遇到这种写法要么改成fopen加锁要么在写之前重新读一遍并合并。5.2 中文变问号JSON_UNESCAPED_UNICODE 与响应头现象页面能发英文中文发出去变成\u4f60\u597d或者直接显示问号更严重的接口返回空白前端报 JSON 解析错误。原因有三类json_encode默认把中文转成 Unicode 转义虽然浏览器能解析但直接看文件不直观响应头缺少charsetutf-8浏览器按默认编码猜数据文件带 BOM 或被编辑器保存成 GBKjson_decode返回null。解决方式是输出时加JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES响应头写Content-Type: application/json; charsetutf-8数据文件用无 BOM 的 UTF-8 保存。如果json_encode返回false用json_last_error_msg()看原因常见是非法 UTF-8。昵称和消息入库前用mb_substr截断不要用substr切中文。还有一个小坑前端fetch没设置headers时POST 表单默认编码可能不是 UTF-8用FormData或URLSearchParams更稳。5.3 聊天室变成弹窗工厂输出转义与 CSP 底线现象有人把昵称改成带onerror的图片标签或者消息里塞一段脚本页面开始弹窗、跳转甚至读取本地存储。原因很直接前端用innerHTML拼接消息服务端也没有做输出转义。单文件版经常为了“支持简单表情”保留 HTML这就把 XSS 口子留大了。解决分两层前端渲染用textContent写昵称和消息不要拼 HTML服务端在存入和输出时做长度限制必要时用htmlspecialchars($text, ENT_QUOTES, UTF-8)转义。CSP 可以作为底线在 PHP 入口加响应头限制脚本来源header(Content-Security-Policy: default-src self; script-src self unsafe-inline; style-src self unsafe-inline; img-src self data:; connect-src self; object-src none; base-uri none);default-src self限制外部资源object-src none禁掉插件base-uri none防止 base 标签劫持。单文件版通常内联脚本所以script-src里带unsafe-inline防护有限真正管用的还是textContent和输入长度限制。不要为了“支持富文本”把消息直接塞进innerHTML那是给自己挖坑。如果必须支持链接单独做白名单解析只允许http、https并且加relnoopener noreferrer。5.4 轮询把 CPU 打满看访问日志和文件大小现象页面开着不动主机 CPU 却一直高访问日志里全是fetch请求消息文件越来越大打开聊天室要等好几秒。原因通常是setInterval间隔太短、上一次请求没回来就发下一次、每次全量读 JSON、消息没有保留上限。解决方式前端改成递归setTimeout等响应回来再排下一轮页面隐藏时暂停服务端加last_id增量过滤写端用array_slice保留最近 N 条。排查时先看数据文件大小超过几 MB 就说明保留条数没生效再看访问日志里同一 IP 的请求频率如果一秒好几次前端定时器肯定写错了。单文件版不要追求“秒级同步”文字聊天 2 到 5 秒拉一次足够。主机性能有限时把轮询间隔调大比换服务器更直接。5.5 时间对不上时区与时间戳存储现象消息时间比本地时间差 8 小时或者不同人看到的时间不一样。原因通常是服务端用date(H:i:s)存了格式化字符串而 PHP 时区没设前端又用本地时间显示两边基准不一致。解决方式是统一存 Unix 时间戳写端用time()前端用Intl.DateTimeFormat按浏览器本地时区格式化。PHP 入口可以显式设date_default_timezone_set(Asia/Shanghai)但存储仍然建议用时间戳展示层再转换。这样换服务器、换时区都不会把历史消息时间弄乱。如果源码已经存了格式化字符串迁移时用strtotime转一遍别直接混用。时间问题不影响聊天功能但排查起来很烦尤其是跨时区协作时。提示排查顺序固定为“数据文件是否合法 JSON → 接口返回状态和响应头 → 前端控制台报错”不要一上来就改前端。6. 把单文件当小系统维护并发验证、备份与迁移检查单文件聊天室上线后最容易被忽略的是维护动作。消息文件既是数据又是配置改错一行就可能让整个房间静默。我的习惯是每次改完代码先做两件事并发写入验证和备份恢复验证。并发验证不用复杂工具二十个请求同时打进去看 id 是否连续、消息有没有丢备份验证则是复制一份数据文件清空原文件再恢复确认页面能正常读出历史。下面这段命令用xargs并发发消息跑完直接检查 JSON 里的 id。# 20 个并发请求观察是否有 500 和消息丢失 seq 1 20 | xargs -P 20 -I{} curl -s -o /dev/null -w %{http_code}\n \ http://127.0.0.1:8080/index.php?actionsend \ --data-urlencode user压测{} \ --data-urlencode texthello-{} # 检查消息条数、最大 id 和 JSON 是否合法 php -r $l json_decode(file_get_contents(data/messages.json), true); if (!is_array($l)) { fwrite(STDERR, invalid json\n); exit(1); } $ids array_map(fn($m) (int)$m[id], $l); printf(count%d max%d unique%d\n, count($l), max($ids), count(array_unique($ids))); -P 20控制并发数--data-urlencode处理中文和空格-w %{http_code}只看状态码。跑完看输出里有没有非 200再看count、max、unique三个数是否对得上。如果count小于请求数说明写锁没覆盖读改写如果unique小于count说明 id 生成有并发问题。备份时不要直接cp正在写的文件先读锁复制或者低峰期操作。迁移检查我一般看四项PHP 版本、data目录权限、消息文件 JSON 合法性、轮询接口返回的last_id是否连续。这四项过了再换机器或升级环境心里才有底。血泪经验是只改前端轮询间隔、不改服务端保留条数JSON 会越读越大页面首屏从一秒变成三秒。从那以后我每次部署这类单文件聊天室都先跑一遍并发写入和文件大小检查再开页面。希望帮到你。本文还有配套的精品资源点击获取
