简介这是一套开源、可私有化部署的PHP在线客服IM系统源码面向中小网站开发者、独立站长及需要定制化客服能力的技术团队解决第三方客服工具年费高、功能受限、数据不自主等痛点。资源包共2000个文件涵盖418个JavaScript交互逻辑、280个HTML前端页面、165个XML配置与接口定义、155个CSS样式文件、114个PHP后端核心模块以及PNG/GIF图标资源和SQL数据库脚本等整体压缩包27.38MB结构完整支持PC网页、手机移动端及微信公众号多端接入。已有404人学习下载资源附带安装搭建教程适配Linux环境推荐2核4G5M带宽内置自动刷新、智能自动回复、弹窗嵌入、手机版管理后台等实用功能所有代码支持二次开发便于按业务需求扩展工单、会话存档、数据分析等模块。1. 用 PHP 搭建网页在线客服 IM 系统不是套模板而是理清「连接—消息—状态」三层骨架你下载了一套标着“PHP 客服在线 IM 源码”的压缩包解压后看到index.php、chat.php、admin/和一堆.sql文件但一运行就卡在“用户不在线”或“消息发不出去”——这不是代码有 bug而是这套源码默认假设你已理解三个底层契约HTTP 请求无法维持长连接客服与访客需独立会话标识消息投递必须绕过页面刷新延迟。它本质是一套基于 PHPMySQL 的轻量级轮询式 IM 架构适合日均咨询量 500 以内、无需实时音视频、强调快速嵌入现有网站的中小业务场景。如果你正为官网加客服入口、电商详情页嵌入咨询浮窗、或需要可二次开发的私有化部署方案这套 PHP 实现比 SaaS 工具更可控但若追求万级并发或端到端加密它需要配合 WebSocket 或消息队列重构。本文不讲“如何安装”而是带你从数据库设计开始重走一遍真实上线前必调的 7 处关键逻辑。2. 数据库结构与会话模型为什么chat_session表必须带visitor_id和operator_id双主键一套能跑通的 PHP 在线客服系统其数据表设计直接决定扩展上限。常见错误是把所有聊天记录堆进一张messages表用from_user和to_user字段硬编码区分角色结果客服切换时消息错乱、历史记录无法按会话归档。正确做法是分层建模会话Session→ 消息Message→ 状态Status三者通过外键强约束。2.1 核心四张表字段与索引策略以下为生产环境验证过的最小可行结构MySQL 5.7所有VARCHAR长度按实际需求收紧避免TEXT类型滥用表名关键字段必建索引说明chat_visitorsid,ip,user_agent,created_atINDEX(ip)、INDEX(created_at)访客非登录态唯一标识ipuser_agent组合可防重复创建chat_operatorsid,username,status,last_activeINDEX(status)、INDEX(last_active)客服账号表status用 TINYINT(1) 存 0离线/1在线/2忙碌chat_sessionsid,visitor_id,operator_id,started_at,ended_at,statusUNIQUE(visitor_id, operator_id)、INDEX(status)会话主表status区分 0未分配/1进行中/2已结束UNIQUE确保同一访客同一客服不重复建会话chat_messagesid,session_id,sender_type,sender_id,content,sent_atINDEX(session_id)、INDEX(sent_at)sender_type用 ENUM(visitor,operator)sender_id对应chat_visitors.id或chat_operators.id提示chat_sessions表的UNIQUE(visitor_id, operator_id)是防止客服重复接入同一访客的关键。若去掉此约束当访客刷新页面后重新请求客服系统可能生成新会话而非复用旧会话导致消息断连。2.2 初始化 SQL 脚本与字段含义详解-- 创建访客表不依赖用户登录 CREATE TABLE chat_visitors ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, ip VARCHAR(45) NOT NULL COMMENT IPv4/IPv6, user_agent VARCHAR(255) NOT NULL COMMENT 浏览器标识, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), INDEX idx_ip (ip), INDEX idx_created (created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 创建客服表需后台管理 CREATE TABLE chat_operators ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password_hash VARCHAR(255) NOT NULL, status TINYINT(1) NOT NULL DEFAULT 0 COMMENT 0离线,1在线,2忙碌, last_active DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), INDEX idx_status (status), INDEX idx_last_active (last_active) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 创建会话表核心枢纽 CREATE TABLE chat_sessions ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, visitor_id INT UNSIGNED NOT NULL, operator_id INT UNSIGNED DEFAULT NULL, started_at DATETIME DEFAULT CURRENT_TIMESTAMP, ended_at DATETIME DEFAULT NULL, status TINYINT(1) NOT NULL DEFAULT 0 COMMENT 0待分配,1进行中,2已结束, PRIMARY KEY (id), UNIQUE KEY uk_visitor_operator (visitor_id, operator_id), INDEX idx_status (status), FOREIGN KEY (visitor_id) REFERENCES chat_visitors(id) ON DELETE CASCADE, FOREIGN KEY (operator_id) REFERENCES chat_operators(id) ON DELETE SET NULL ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 创建消息表按会话归档 CREATE TABLE chat_messages ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, session_id INT UNSIGNED NOT NULL, sender_type ENUM(visitor,operator) NOT NULL, sender_id INT UNSIGNED NOT NULL, content TEXT NOT NULL COMMENT JSON 或纯文本建议限制长度, sent_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), INDEX idx_session_sent (session_id, sent_at), FOREIGN KEY (session_id) REFERENCES chat_sessions(id) ON DELETE CASCADE ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字段设计逻辑说明chat_visitors.ip存储完整 IP支持 IPv6不依赖 Cookie 或 Session ID因访客可能禁用 Cookie 或使用无痕模式chat_operators.status与last_active联动后台定时脚本每 30 秒扫描last_active超过 120 秒的记录自动设status0chat_sessions.status的0待分配状态由分配逻辑触发不是前端点击“找客服”就立即写入1进行中而是先置为0再由分配器选择空闲客服后更新chat_messages.content建议用TEXT但加应用层长度校验如 PHP 中mb_strlen($content) 2000则截断避免单条消息撑爆日志。2.3 会话分配逻辑为什么不能用ORDER BY RAND()选客服很多开源 PHP 客服源码在分配客服时直接写SELECT id FROM chat_operators WHERE status 1 ORDER BY RAND() LIMIT 1这在 10 人以内可用但并发稍高即锁表。真实场景应采用权重轮询 空闲时长优先// 分配函数返回 operator_id 或 null无空闲客服 function assignOperatorToVisitor($visitorId) { global $pdo; // 1. 获取所有 status1 的客服按 last_active 升序越久没活动越优先分配 $stmt $pdo-prepare( SELECT id, username FROM chat_operators WHERE status 1 ORDER BY last_active ASC LIMIT 1 ); $stmt-execute(); $operator $stmt-fetch(PDO::FETCH_ASSOC); if (!$operator) return null; // 2. 更新会话将 visitor_id 关联到该 operator_id并设 status1 $pdo-beginTransaction(); try { // 先插入会话记录status0 $stmt $pdo-prepare(INSERT INTO chat_sessions (visitor_id, status) VALUES (?, 0)); $stmt-execute([$visitorId]); $sessionId $pdo-lastInsertId(); // 再更新会话绑定客服并改状态 $stmt $pdo-prepare( UPDATE chat_sessions SET operator_id ?, status 1 WHERE id ? AND status 0 ); $stmt-execute([$operator[id], $sessionId]); // 同时更新客服 last_active $stmt $pdo-prepare(UPDATE chat_operators SET last_active NOW() WHERE id ?); $stmt-execute([$operator[id]]); $pdo-commit(); return $operator[id]; } catch (Exception $e) { $pdo-rollback(); error_log(Assign failed for visitor {$visitorId}: . $e-getMessage()); return null; } }关键点解析ORDER BY last_active ASC确保长时间未响应的客服优先承接新会话避免“忙客服更忙闲客服更闲”使用事务保证INSERTUPDATE原子性防止会话创建成功但未绑定客服WHERE status 0在UPDATE中二次校验避免并发时多个请求同时分配同一访客。3. 消息轮询机制与前端交互用setTimeout替代setInterval防止请求堆积PHP 本身不支持长连接因此网页版 IM 必须依赖客户端轮询Polling。但多数源码用setInterval(getNewMessages, 3000)导致页面切到后台时请求持续发送、网络抖动时请求积压、新消息到达后仍要等下一个周期。正确做法是每次请求完成后再设下一次超时且带时间戳过滤。3.1 后端消息查询接口get_messages.php?php // get_messages.php?session_id123last_id456 require_once config.php; // 包含 PDO 连接 if (!isset($_GET[session_id]) || !is_numeric($_GET[session_id])) { http_response_code(400); echo json_encode([error Invalid session_id]); exit; } $sessionId (int)$_GET[session_id]; $lastId isset($_GET[last_id]) is_numeric($_GET[last_id]) ? (int)$_GET[last_id] : 0; try { $pdo getPDO(); // 获取连接 // 查询 session_id 下所有 id last_id 的消息按时间升序 $stmt $pdo-prepare( SELECT m.id, m.sender_type, m.sender_id, m.content, UNIX_TIMESTAMP(m.sent_at) as sent_at FROM chat_messages m WHERE m.session_id ? AND m.id ? ORDER BY m.id ASC LIMIT 50 ); $stmt-execute([$sessionId, $lastId]); $messages $stmt-fetchAll(PDO::FETCH_ASSOC); // 返回 JSON含最新消息 ID 用于下次轮询 $response [ messages $messages, next_last_id !empty($messages) ? end($messages)[id] : $lastId, has_more count($messages) 50 ]; header(Content-Type: application/json; charsetutf-8); echo json_encode($response, JSON_UNESCAPED_UNICODE); } catch (Exception $e) { error_log(Get messages failed: . $e-getMessage()); http_response_code(500); echo json_encode([error Server error]); }参数与响应说明last_id前端传入上次获取的最后一条消息id后端只查id last_id避免漏消息或重复拉取UNIX_TIMESTAMP(m.sent_at)转为秒级时间戳前端 JS 可直接new Date(timestamp * 1000)格式化next_last_id返回本次查询结果中最大的id前端下次请求时填入last_id形成游标has_more若返回 50 条满额提示前端可能还有更多可主动增加轮询频率。3.2 前端轮询控制用setTimeout实现自适应间隔class ChatPoller { constructor(sessionId) { this.sessionId sessionId; this.lastId 0; this.polling false; this.timeoutId null; this.minInterval 1000; // 最小间隔 1s this.maxInterval 30000; // 最大间隔 30s this.currentInterval this.minInterval; } start() { if (this.polling) return; this.polling true; this._poll(); } stop() { this.polling false; if (this.timeoutId) { clearTimeout(this.timeoutId); this.timeoutId null; } } _poll() { if (!this.polling) return; const url get_messages.php?session_id${this.sessionId}last_id${this.lastId}; fetch(url) .then(res { if (!res.ok) throw new Error(HTTP ${res.status}); return res.json(); }) .then(data { if (data.messages data.messages.length 0) { // 渲染新消息 this._renderMessages(data.messages); this.lastId data.next_last_id; // 有新消息则重置为最小间隔 this.currentInterval this.minInterval; } else if (data.has_more) { // 有更多消息但本次没拉全缩短间隔 this.currentInterval Math.max(this.minInterval, this.currentInterval * 0.8); } else { // 无新消息逐步延长间隔指数退避 this.currentInterval Math.min(this.maxInterval, this.currentInterval * 1.5); } }) .catch(err { console.warn(Poll failed:, err); // 失败时用固定间隔重试避免雪崩 this.currentInterval this.minInterval * 2; }) .finally(() { // 下次轮询 this.timeoutId setTimeout(() this._poll(), this.currentInterval); }); } _renderMessages(messages) { messages.forEach(msg { const el document.createElement(div); el.className message ${msg.sender_type}; el.innerHTML strong${msg.sender_type visitor ? 访客 : 客服}:/strong ${msg.content}; document.getElementById(chat-log).appendChild(el); document.getElementById(chat-log).scrollTop document.getElementById(chat-log).scrollHeight; }); } } // 使用示例 const poller new ChatPoller(123); poller.start(); // 页面隐藏时暂停显示时恢复 document.addEventListener(visibilitychange, () { if (document.hidden) { poller.stop(); } else { poller.start(); } });轮询策略优势setTimeout链式调用确保每次请求完成后再发起下一次不会因网络延迟导致请求堆积currentInterval动态调整有消息 → 缩短无消息 → 延长平衡实时性与服务器压力visibilitychange监听让页面切到后台时自动暂停节省资源has_more字段支持前端判断是否需主动触发“加载更多”。4. 客服端状态同步与消息推送用 MySQLINSERT ... ON DUPLICATE KEY UPDATE实现原子状态写入客服端需实时显示“当前接待人数”、“访客等待数”、“自己状态”这些数据若靠定时 AJAX 拉取必然存在几秒延迟。更可靠的做法是所有状态变更都写入数据库前端用长轮询或 Server-Sent EventsSSE监听变更。由于 PHP 环境通常不启用 SSE我们采用“伪长轮询 原子写入”组合。4.1 客服状态表设计与原子更新新增状态快照表chat_operator_status用于存储每个客服的实时指标CREATE TABLE chat_operator_status ( operator_id INT UNSIGNED NOT NULL, online_count INT NOT NULL DEFAULT 0 COMMENT 当前接待会话数, waiting_count INT NOT NULL DEFAULT 0 COMMENT 排队中访客数, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (operator_id), FOREIGN KEY (operator_id) REFERENCES chat_operators(id) ON DELETE CASCADE ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;状态更新必须原子化避免并发时online_count计算错误。使用INSERT ... ON DUPLICATE KEY UPDATE// update_operator_status.php?operator_id5actioninc_online function updateOperatorStatus($operatorId, $action) { global $pdo; switch ($action) { case inc_online: $sql INSERT INTO chat_operator_status (operator_id, online_count) VALUES (?, 1) ON DUPLICATE KEY UPDATE online_count online_count 1; break; case dec_online: $sql INSERT INTO chat_operator_status (operator_id, online_count) VALUES (?, 0) ON DUPLICATE KEY UPDATE online_count GREATEST(0, online_count - 1); break; case inc_waiting: $sql INSERT INTO chat_operator_status (operator_id, waiting_count) VALUES (?, 1) ON DUPLICATE KEY UPDATE waiting_count waiting_count 1; break; case dec_waiting: $sql INSERT INTO chat_operator_status (operator_id, waiting_count) VALUES (?, 0) ON DUPLICATE KEY UPDATE waiting_count GREATEST(0, waiting_count - 1); break; default: return false; } $stmt $pdo-prepare($sql); return $stmt-execute([$operatorId]); } // 示例客服 A 开始接待会话 updateOperatorStatus(5, inc_online); // 示例访客 B 进入等待队列 updateOperatorStatus(0, inc_waiting); // operator_id0 表示全局等待队列原子性保障原理INSERT ... ON DUPLICATE KEY UPDATE是 MySQL 原子操作即使 10 个请求同时执行inc_online最终online_count也精确等于 10GREATEST(0, online_count - 1)防止负数避免状态错乱operator_id0作为特殊值代表“全站等待队列”便于统计总排队数。4.2 客服端状态轮询带IF-MODIFIED-SINCE的高效拉取为减少无效请求客服后台用 HTTPIf-Modified-Since头校验状态是否变更// get_operator_status.php header(Content-Type: application/json; charsetutf8mb4); if (isset($_SERVER[HTTP_IF_MODIFIED_SINCE])) { $since strtotime($_SERVER[HTTP_IF_MODIFIED_SINCE]); // 查询 updated_at $since 的记录 $stmt $pdo-prepare( SELECT operator_id, online_count, waiting_count, updated_at FROM chat_operator_status WHERE updated_at FROM_UNIXTIME(?) ); $stmt-execute([$since]); $rows $stmt-fetchAll(PDO::FETCH_ASSOC); if (empty($rows)) { http_response_code(304); exit; } // 返回变更数据 echo json_encode([status $rows], JSON_UNESCAPED_UNICODE); exit; } // 首次请求或无 If-Modified-Since 时返回全量 $stmt $pdo-query(SELECT * FROM chat_operator_status); $status $stmt-fetchAll(PDO::FETCH_ASSOC); // 设置 Last-Modified 头 $lastUpdate !empty($status) ? max(array_column($status, updated_at)) : date(Y-m-d H:i:s); header(Last-Modified: . gmdate(D, d M Y H:i:s, strtotime($lastUpdate)) . GMT); echo json_encode([status $status], JSON_UNESCAPED_UNICODE);前端调用示例带缓存校验async function fetchOperatorStatus() { const now new Date().toUTCString(); const response await fetch(get_operator_status.php, { headers: { If-Modified-Since: lastModified || } }); if (response.status 304) { console.log(No status change); return; } const data await response.json(); updateDashboard(data.status); // 渲染到客服控制台 // 记录 Last-Modified 供下次使用 const lastMod response.headers.get(Last-Modified); if (lastMod) lastModified lastMod; }注意If-Modified-Since依赖服务器时间严格同步若 NTP 未校准会导致误判。生产环境建议用ETag替代但Last-Modified对 PHPMySQL 组合更轻量。5. 消息内容安全与 XSS 防御对content字段做三层过滤而非仅htmlspecialchars客服系统最常被忽视的风险是访客在输入框提交scriptalert(1)/script若后端未过滤直接存库前端渲染时执行脚本。很多 PHP 源码只在输出时用htmlspecialchars()这不够——恶意内容已进入数据库可能被其他接口如导出 Excel、API 接口直接暴露。必须在入库前做三层净化。5.1 入库前过滤链strip_tags→htmlentities→ 正则白名单function sanitizeMessageContent($content) { // 第一层移除所有 HTML 标签保留换行和空格 $content strip_tags($content); // 第二层将剩余字符转义为 HTML 实体 → amp; 等 $content htmlentities($content, ENT_QUOTES | ENT_SUBSTITUTE, UTF-8); // 第三层只允许特定符号白名单移除控制字符和 Unicode 隐形字符 // 允许字母、数字、常用标点、中文、日文、韩文、空格、换行、制表符 $content preg_replace(/[^\p{L}\p{N}\p{P}\s\u{3000}-\u{303F}\u{3040}-\u{309F}\u{30A0}-\u{30FF}\x{0009}\x{000A}\x{000D}]/u, , $content); // 限制长度并 trim $content mb_substr(trim($content), 0, 2000, UTF-8); return $content; } // 使用示例 $userInput scriptalert(xss)/script你好\n\na hrefjavascript:alert(1)链接/a; $safeContent sanitizeMessageContent($userInput); // 输出你好\n\n链接过滤逻辑详解strip_tags()移除script、img等标签但保留文本中的符号如数学公式htmlentities()将转为实体防止属性注入preg_replace()白名单匹配\p{L}所有语言字母、\p{N}所有数字、\p{P}所有标点、\s空白符、\u{3000}-\u{303F}中文标点、\u{3040}-\u{309F}平假名、\u{30A0}-\u{30FF}片假名覆盖主流东亚文字\x{0009}\x{000A}\x{000D}显式保留 Tab、LF、CR确保换行正常mb_substr()用 UTF-8 安全截断避免截断多字节字符。5.2 前端二次渲染用textContent替代innerHTML即使后端过滤严格前端仍需防御 DOM 注入// ❌ 危险直接 innerHTML 会执行 script // messageEl.innerHTML message.content; // ✅ 安全textContent 自动转义 messageEl.textContent message.content; // 若需支持简单格式如换行用 pre-wrap textContent messageEl.style.whiteSpace pre-wrap; messageEl.textContent message.content.replace(/\n/g, \n);为什么textContent更安全textContent将字符串作为纯文本插入bhello/b会原样显示不会加粗不触发任何事件监听器或脚本执行性能优于innerHTML无 HTML 解析开销与后端过滤形成“双重保险”。5.3 敏感词拦截用 Redis 实现毫秒级关键词匹配对“违法”、“诈骗”、“微信”等敏感词需实时拦截。MySQL LIKE 查询太慢应预加载到内存// init_sensitive_words.php启动时加载敏感词到 Redis $redis new Redis(); $redis-connect(127.0.0.1, 6379); // 从数据库读取敏感词带权重 $stmt $pdo-query(SELECT word, weight FROM sensitive_words WHERE enabled 1); while ($row $stmt-fetch(PDO::FETCH_ASSOC)) { $redis-hSet(sensitive_words, $row[word], $row[weight]); } // 检查函数 function checkSensitiveWords($content) { global $redis; // 提取所有连续中文、英文、数字组合忽略标点 preg_match_all(/[\x{4e00}-\x{9fff}a-zA-Z0-9]/u, $content, $matches); $words $matches[0]; $hit []; foreach ($words as $word) { $weight $redis-hGet(sensitive_words, $word); if ($weight ! false) { $hit[] [word $word, weight (int)$weight]; } } return $hit; } // 使用 $hits checkSensitiveWords(这个微信号码很危险); if (!empty($hits)) { error_log(Sensitive word detected: . json_encode($hits)); // 可触发告警、打标、或拒绝入库 }Redis 方案优势HGET时间复杂度 O(1)10 万词库查询 0.1ms支持热更新修改数据库后FLUSHALL并重载即可preg_match_all提取词干避免“微 信”拆分导致漏检。6. 高并发优化实战用 PHP-FPM 进程池 OPcache 缓存会话元数据当单台服务器承载日均 5000 咨询时原始 PHP 轮询架构会出现 CPU 暴涨、MySQL 连接数打满。此时不能盲目加机器而应从 PHP 层和 MySQL 层协同优化。6.1 PHP-FPM 进程池隔离为客服接口单独配置在www.conf中新增一个进程池专供get_messages.php和send_message.php使用; /etc/php/8.1/fpm/pool.d/chat.conf [chat] listen /run/php/php8.1-fpm-chat.sock listen.owner www-data listen.group www-data listen.mode 0660 pm static pm.max_children 32 pm.start_servers 16 pm.min_spare_servers 8 pm.max_spare_servers 24 ; 降低超时避免长轮询占满进程 request_terminate_timeout 30s request_slowlog_timeout 10s ; 仅加载必要扩展 php_admin_value[extension] mysqli.so php_admin_value[extension] pdo_mysql.so php_admin_value[opcache.enable] 1Nginx 配置指向该 socketlocation ~ ^/chat/(get_messages|send_message)\.php$ { fastcgi_pass unix:/run/php/php8.1-fpm-chat.sock; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }隔离效果客服轮询请求不再与首页、商品页共用进程池避免慢请求阻塞主站pm.max_children 32限制最大并发连接数防止 MySQL 连接耗尽request_terminate_timeout 30s强制中断卡死请求保护进程池。6.2 OPcache 缓存会话元数据减少 MySQL 查询每次轮询都要查chat_sessions和chat_messages其中chat_sessions的status和operator_id属于低频变更数据可缓存 60 秒function getCachedSession($sessionId) { $cacheKey session_{$sessionId}; // 尝试 OPcache if (opcache_is_script_cached($cacheKey)) { $cached opcache_get_status()[scripts][$cacheKey][cached_timestamp] ?? 0; if (time() - $cached 60) { return opcache_get_status()[scripts][$cacheKey][cached_content] ?? null; } } // 未命中则查 DB并写入 OPcache需开启 opcache.file_cache global $pdo; $stmt $pdo-prepare(SELECT operator_id, status FROM chat_sessions WHERE id ?); $stmt-execute([$sessionId]); $session $stmt-fetch(PDO::FETCH_ASSOC); if ($session) { // 写入文件缓存OPcache file cache $cacheFile /tmp/opcache/session_ . $sessionId . .php; file_put_contents($cacheFile, ?php return . var_export($session, true) . ;); opcache_compile_file($cacheFile); } return $session; }提示opcache.file_cache需在php.ini中启用路径设为 SSD 目录避免 NFS 慢盘。6.3 MySQL 查询优化为chat_messages添加复合索引原始轮询查询WHERE session_id ? AND id ? ORDER BY id ASC LIMIT 50若只有INDEX(session_id)MySQL 仍需扫描大量行。添加覆盖索引-- 删除旧索引 DROP INDEX idx_session_id ON chat_messages; -- 创建新复合索引 CREATE INDEX idx_session_id_id ON chat_messages (session_id, id) COMMENT Covering index for polling queries;索引生效验证EXPLAIN SELECT id, sender_type, sender_id, content, sent_at FROM chat_messages WHERE session_id 123 AND id 456 ORDER BY id ASC LIMIT 50;输出中key应为idx_session_id_idrows应接近LIMIT值50而非全表扫描。本文还有配套的精品资源点击获取
PHP在线客服IM系统设计：连接-消息-状态三层架构
简介这是一套开源、可私有化部署的PHP在线客服IM系统源码面向中小网站开发者、独立站长及需要定制化客服能力的技术团队解决第三方客服工具年费高、功能受限、数据不自主等痛点。资源包共2000个文件涵盖418个JavaScript交互逻辑、280个HTML前端页面、165个XML配置与接口定义、155个CSS样式文件、114个PHP后端核心模块以及PNG/GIF图标资源和SQL数据库脚本等整体压缩包27.38MB结构完整支持PC网页、手机移动端及微信公众号多端接入。已有404人学习下载资源附带安装搭建教程适配Linux环境推荐2核4G5M带宽内置自动刷新、智能自动回复、弹窗嵌入、手机版管理后台等实用功能所有代码支持二次开发便于按业务需求扩展工单、会话存档、数据分析等模块。1. 用 PHP 搭建网页在线客服 IM 系统不是套模板而是理清「连接—消息—状态」三层骨架你下载了一套标着“PHP 客服在线 IM 源码”的压缩包解压后看到index.php、chat.php、admin/和一堆.sql文件但一运行就卡在“用户不在线”或“消息发不出去”——这不是代码有 bug而是这套源码默认假设你已理解三个底层契约HTTP 请求无法维持长连接客服与访客需独立会话标识消息投递必须绕过页面刷新延迟。它本质是一套基于 PHPMySQL 的轻量级轮询式 IM 架构适合日均咨询量 500 以内、无需实时音视频、强调快速嵌入现有网站的中小业务场景。如果你正为官网加客服入口、电商详情页嵌入咨询浮窗、或需要可二次开发的私有化部署方案这套 PHP 实现比 SaaS 工具更可控但若追求万级并发或端到端加密它需要配合 WebSocket 或消息队列重构。本文不讲“如何安装”而是带你从数据库设计开始重走一遍真实上线前必调的 7 处关键逻辑。2. 数据库结构与会话模型为什么chat_session表必须带visitor_id和operator_id双主键一套能跑通的 PHP 在线客服系统其数据表设计直接决定扩展上限。常见错误是把所有聊天记录堆进一张messages表用from_user和to_user字段硬编码区分角色结果客服切换时消息错乱、历史记录无法按会话归档。正确做法是分层建模会话Session→ 消息Message→ 状态Status三者通过外键强约束。2.1 核心四张表字段与索引策略以下为生产环境验证过的最小可行结构MySQL 5.7所有VARCHAR长度按实际需求收紧避免TEXT类型滥用表名关键字段必建索引说明chat_visitorsid,ip,user_agent,created_atINDEX(ip)、INDEX(created_at)访客非登录态唯一标识ipuser_agent组合可防重复创建chat_operatorsid,username,status,last_activeINDEX(status)、INDEX(last_active)客服账号表status用 TINYINT(1) 存 0离线/1在线/2忙碌chat_sessionsid,visitor_id,operator_id,started_at,ended_at,statusUNIQUE(visitor_id, operator_id)、INDEX(status)会话主表status区分 0未分配/1进行中/2已结束UNIQUE确保同一访客同一客服不重复建会话chat_messagesid,session_id,sender_type,sender_id,content,sent_atINDEX(session_id)、INDEX(sent_at)sender_type用 ENUM(visitor,operator)sender_id对应chat_visitors.id或chat_operators.id提示chat_sessions表的UNIQUE(visitor_id, operator_id)是防止客服重复接入同一访客的关键。若去掉此约束当访客刷新页面后重新请求客服系统可能生成新会话而非复用旧会话导致消息断连。2.2 初始化 SQL 脚本与字段含义详解-- 创建访客表不依赖用户登录 CREATE TABLE chat_visitors ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, ip VARCHAR(45) NOT NULL COMMENT IPv4/IPv6, user_agent VARCHAR(255) NOT NULL COMMENT 浏览器标识, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), INDEX idx_ip (ip), INDEX idx_created (created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 创建客服表需后台管理 CREATE TABLE chat_operators ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password_hash VARCHAR(255) NOT NULL, status TINYINT(1) NOT NULL DEFAULT 0 COMMENT 0离线,1在线,2忙碌, last_active DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), INDEX idx_status (status), INDEX idx_last_active (last_active) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 创建会话表核心枢纽 CREATE TABLE chat_sessions ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, visitor_id INT UNSIGNED NOT NULL, operator_id INT UNSIGNED DEFAULT NULL, started_at DATETIME DEFAULT CURRENT_TIMESTAMP, ended_at DATETIME DEFAULT NULL, status TINYINT(1) NOT NULL DEFAULT 0 COMMENT 0待分配,1进行中,2已结束, PRIMARY KEY (id), UNIQUE KEY uk_visitor_operator (visitor_id, operator_id), INDEX idx_status (status), FOREIGN KEY (visitor_id) REFERENCES chat_visitors(id) ON DELETE CASCADE, FOREIGN KEY (operator_id) REFERENCES chat_operators(id) ON DELETE SET NULL ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 创建消息表按会话归档 CREATE TABLE chat_messages ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, session_id INT UNSIGNED NOT NULL, sender_type ENUM(visitor,operator) NOT NULL, sender_id INT UNSIGNED NOT NULL, content TEXT NOT NULL COMMENT JSON 或纯文本建议限制长度, sent_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), INDEX idx_session_sent (session_id, sent_at), FOREIGN KEY (session_id) REFERENCES chat_sessions(id) ON DELETE CASCADE ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字段设计逻辑说明chat_visitors.ip存储完整 IP支持 IPv6不依赖 Cookie 或 Session ID因访客可能禁用 Cookie 或使用无痕模式chat_operators.status与last_active联动后台定时脚本每 30 秒扫描last_active超过 120 秒的记录自动设status0chat_sessions.status的0待分配状态由分配逻辑触发不是前端点击“找客服”就立即写入1进行中而是先置为0再由分配器选择空闲客服后更新chat_messages.content建议用TEXT但加应用层长度校验如 PHP 中mb_strlen($content) 2000则截断避免单条消息撑爆日志。2.3 会话分配逻辑为什么不能用ORDER BY RAND()选客服很多开源 PHP 客服源码在分配客服时直接写SELECT id FROM chat_operators WHERE status 1 ORDER BY RAND() LIMIT 1这在 10 人以内可用但并发稍高即锁表。真实场景应采用权重轮询 空闲时长优先// 分配函数返回 operator_id 或 null无空闲客服 function assignOperatorToVisitor($visitorId) { global $pdo; // 1. 获取所有 status1 的客服按 last_active 升序越久没活动越优先分配 $stmt $pdo-prepare( SELECT id, username FROM chat_operators WHERE status 1 ORDER BY last_active ASC LIMIT 1 ); $stmt-execute(); $operator $stmt-fetch(PDO::FETCH_ASSOC); if (!$operator) return null; // 2. 更新会话将 visitor_id 关联到该 operator_id并设 status1 $pdo-beginTransaction(); try { // 先插入会话记录status0 $stmt $pdo-prepare(INSERT INTO chat_sessions (visitor_id, status) VALUES (?, 0)); $stmt-execute([$visitorId]); $sessionId $pdo-lastInsertId(); // 再更新会话绑定客服并改状态 $stmt $pdo-prepare( UPDATE chat_sessions SET operator_id ?, status 1 WHERE id ? AND status 0 ); $stmt-execute([$operator[id], $sessionId]); // 同时更新客服 last_active $stmt $pdo-prepare(UPDATE chat_operators SET last_active NOW() WHERE id ?); $stmt-execute([$operator[id]]); $pdo-commit(); return $operator[id]; } catch (Exception $e) { $pdo-rollback(); error_log(Assign failed for visitor {$visitorId}: . $e-getMessage()); return null; } }关键点解析ORDER BY last_active ASC确保长时间未响应的客服优先承接新会话避免“忙客服更忙闲客服更闲”使用事务保证INSERTUPDATE原子性防止会话创建成功但未绑定客服WHERE status 0在UPDATE中二次校验避免并发时多个请求同时分配同一访客。3. 消息轮询机制与前端交互用setTimeout替代setInterval防止请求堆积PHP 本身不支持长连接因此网页版 IM 必须依赖客户端轮询Polling。但多数源码用setInterval(getNewMessages, 3000)导致页面切到后台时请求持续发送、网络抖动时请求积压、新消息到达后仍要等下一个周期。正确做法是每次请求完成后再设下一次超时且带时间戳过滤。3.1 后端消息查询接口get_messages.php?php // get_messages.php?session_id123last_id456 require_once config.php; // 包含 PDO 连接 if (!isset($_GET[session_id]) || !is_numeric($_GET[session_id])) { http_response_code(400); echo json_encode([error Invalid session_id]); exit; } $sessionId (int)$_GET[session_id]; $lastId isset($_GET[last_id]) is_numeric($_GET[last_id]) ? (int)$_GET[last_id] : 0; try { $pdo getPDO(); // 获取连接 // 查询 session_id 下所有 id last_id 的消息按时间升序 $stmt $pdo-prepare( SELECT m.id, m.sender_type, m.sender_id, m.content, UNIX_TIMESTAMP(m.sent_at) as sent_at FROM chat_messages m WHERE m.session_id ? AND m.id ? ORDER BY m.id ASC LIMIT 50 ); $stmt-execute([$sessionId, $lastId]); $messages $stmt-fetchAll(PDO::FETCH_ASSOC); // 返回 JSON含最新消息 ID 用于下次轮询 $response [ messages $messages, next_last_id !empty($messages) ? end($messages)[id] : $lastId, has_more count($messages) 50 ]; header(Content-Type: application/json; charsetutf-8); echo json_encode($response, JSON_UNESCAPED_UNICODE); } catch (Exception $e) { error_log(Get messages failed: . $e-getMessage()); http_response_code(500); echo json_encode([error Server error]); }参数与响应说明last_id前端传入上次获取的最后一条消息id后端只查id last_id避免漏消息或重复拉取UNIX_TIMESTAMP(m.sent_at)转为秒级时间戳前端 JS 可直接new Date(timestamp * 1000)格式化next_last_id返回本次查询结果中最大的id前端下次请求时填入last_id形成游标has_more若返回 50 条满额提示前端可能还有更多可主动增加轮询频率。3.2 前端轮询控制用setTimeout实现自适应间隔class ChatPoller { constructor(sessionId) { this.sessionId sessionId; this.lastId 0; this.polling false; this.timeoutId null; this.minInterval 1000; // 最小间隔 1s this.maxInterval 30000; // 最大间隔 30s this.currentInterval this.minInterval; } start() { if (this.polling) return; this.polling true; this._poll(); } stop() { this.polling false; if (this.timeoutId) { clearTimeout(this.timeoutId); this.timeoutId null; } } _poll() { if (!this.polling) return; const url get_messages.php?session_id${this.sessionId}last_id${this.lastId}; fetch(url) .then(res { if (!res.ok) throw new Error(HTTP ${res.status}); return res.json(); }) .then(data { if (data.messages data.messages.length 0) { // 渲染新消息 this._renderMessages(data.messages); this.lastId data.next_last_id; // 有新消息则重置为最小间隔 this.currentInterval this.minInterval; } else if (data.has_more) { // 有更多消息但本次没拉全缩短间隔 this.currentInterval Math.max(this.minInterval, this.currentInterval * 0.8); } else { // 无新消息逐步延长间隔指数退避 this.currentInterval Math.min(this.maxInterval, this.currentInterval * 1.5); } }) .catch(err { console.warn(Poll failed:, err); // 失败时用固定间隔重试避免雪崩 this.currentInterval this.minInterval * 2; }) .finally(() { // 下次轮询 this.timeoutId setTimeout(() this._poll(), this.currentInterval); }); } _renderMessages(messages) { messages.forEach(msg { const el document.createElement(div); el.className message ${msg.sender_type}; el.innerHTML strong${msg.sender_type visitor ? 访客 : 客服}:/strong ${msg.content}; document.getElementById(chat-log).appendChild(el); document.getElementById(chat-log).scrollTop document.getElementById(chat-log).scrollHeight; }); } } // 使用示例 const poller new ChatPoller(123); poller.start(); // 页面隐藏时暂停显示时恢复 document.addEventListener(visibilitychange, () { if (document.hidden) { poller.stop(); } else { poller.start(); } });轮询策略优势setTimeout链式调用确保每次请求完成后再发起下一次不会因网络延迟导致请求堆积currentInterval动态调整有消息 → 缩短无消息 → 延长平衡实时性与服务器压力visibilitychange监听让页面切到后台时自动暂停节省资源has_more字段支持前端判断是否需主动触发“加载更多”。4. 客服端状态同步与消息推送用 MySQLINSERT ... ON DUPLICATE KEY UPDATE实现原子状态写入客服端需实时显示“当前接待人数”、“访客等待数”、“自己状态”这些数据若靠定时 AJAX 拉取必然存在几秒延迟。更可靠的做法是所有状态变更都写入数据库前端用长轮询或 Server-Sent EventsSSE监听变更。由于 PHP 环境通常不启用 SSE我们采用“伪长轮询 原子写入”组合。4.1 客服状态表设计与原子更新新增状态快照表chat_operator_status用于存储每个客服的实时指标CREATE TABLE chat_operator_status ( operator_id INT UNSIGNED NOT NULL, online_count INT NOT NULL DEFAULT 0 COMMENT 当前接待会话数, waiting_count INT NOT NULL DEFAULT 0 COMMENT 排队中访客数, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (operator_id), FOREIGN KEY (operator_id) REFERENCES chat_operators(id) ON DELETE CASCADE ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;状态更新必须原子化避免并发时online_count计算错误。使用INSERT ... ON DUPLICATE KEY UPDATE// update_operator_status.php?operator_id5actioninc_online function updateOperatorStatus($operatorId, $action) { global $pdo; switch ($action) { case inc_online: $sql INSERT INTO chat_operator_status (operator_id, online_count) VALUES (?, 1) ON DUPLICATE KEY UPDATE online_count online_count 1; break; case dec_online: $sql INSERT INTO chat_operator_status (operator_id, online_count) VALUES (?, 0) ON DUPLICATE KEY UPDATE online_count GREATEST(0, online_count - 1); break; case inc_waiting: $sql INSERT INTO chat_operator_status (operator_id, waiting_count) VALUES (?, 1) ON DUPLICATE KEY UPDATE waiting_count waiting_count 1; break; case dec_waiting: $sql INSERT INTO chat_operator_status (operator_id, waiting_count) VALUES (?, 0) ON DUPLICATE KEY UPDATE waiting_count GREATEST(0, waiting_count - 1); break; default: return false; } $stmt $pdo-prepare($sql); return $stmt-execute([$operatorId]); } // 示例客服 A 开始接待会话 updateOperatorStatus(5, inc_online); // 示例访客 B 进入等待队列 updateOperatorStatus(0, inc_waiting); // operator_id0 表示全局等待队列原子性保障原理INSERT ... ON DUPLICATE KEY UPDATE是 MySQL 原子操作即使 10 个请求同时执行inc_online最终online_count也精确等于 10GREATEST(0, online_count - 1)防止负数避免状态错乱operator_id0作为特殊值代表“全站等待队列”便于统计总排队数。4.2 客服端状态轮询带IF-MODIFIED-SINCE的高效拉取为减少无效请求客服后台用 HTTPIf-Modified-Since头校验状态是否变更// get_operator_status.php header(Content-Type: application/json; charsetutf8mb4); if (isset($_SERVER[HTTP_IF_MODIFIED_SINCE])) { $since strtotime($_SERVER[HTTP_IF_MODIFIED_SINCE]); // 查询 updated_at $since 的记录 $stmt $pdo-prepare( SELECT operator_id, online_count, waiting_count, updated_at FROM chat_operator_status WHERE updated_at FROM_UNIXTIME(?) ); $stmt-execute([$since]); $rows $stmt-fetchAll(PDO::FETCH_ASSOC); if (empty($rows)) { http_response_code(304); exit; } // 返回变更数据 echo json_encode([status $rows], JSON_UNESCAPED_UNICODE); exit; } // 首次请求或无 If-Modified-Since 时返回全量 $stmt $pdo-query(SELECT * FROM chat_operator_status); $status $stmt-fetchAll(PDO::FETCH_ASSOC); // 设置 Last-Modified 头 $lastUpdate !empty($status) ? max(array_column($status, updated_at)) : date(Y-m-d H:i:s); header(Last-Modified: . gmdate(D, d M Y H:i:s, strtotime($lastUpdate)) . GMT); echo json_encode([status $status], JSON_UNESCAPED_UNICODE);前端调用示例带缓存校验async function fetchOperatorStatus() { const now new Date().toUTCString(); const response await fetch(get_operator_status.php, { headers: { If-Modified-Since: lastModified || } }); if (response.status 304) { console.log(No status change); return; } const data await response.json(); updateDashboard(data.status); // 渲染到客服控制台 // 记录 Last-Modified 供下次使用 const lastMod response.headers.get(Last-Modified); if (lastMod) lastModified lastMod; }注意If-Modified-Since依赖服务器时间严格同步若 NTP 未校准会导致误判。生产环境建议用ETag替代但Last-Modified对 PHPMySQL 组合更轻量。5. 消息内容安全与 XSS 防御对content字段做三层过滤而非仅htmlspecialchars客服系统最常被忽视的风险是访客在输入框提交scriptalert(1)/script若后端未过滤直接存库前端渲染时执行脚本。很多 PHP 源码只在输出时用htmlspecialchars()这不够——恶意内容已进入数据库可能被其他接口如导出 Excel、API 接口直接暴露。必须在入库前做三层净化。5.1 入库前过滤链strip_tags→htmlentities→ 正则白名单function sanitizeMessageContent($content) { // 第一层移除所有 HTML 标签保留换行和空格 $content strip_tags($content); // 第二层将剩余字符转义为 HTML 实体 → amp; 等 $content htmlentities($content, ENT_QUOTES | ENT_SUBSTITUTE, UTF-8); // 第三层只允许特定符号白名单移除控制字符和 Unicode 隐形字符 // 允许字母、数字、常用标点、中文、日文、韩文、空格、换行、制表符 $content preg_replace(/[^\p{L}\p{N}\p{P}\s\u{3000}-\u{303F}\u{3040}-\u{309F}\u{30A0}-\u{30FF}\x{0009}\x{000A}\x{000D}]/u, , $content); // 限制长度并 trim $content mb_substr(trim($content), 0, 2000, UTF-8); return $content; } // 使用示例 $userInput scriptalert(xss)/script你好\n\na hrefjavascript:alert(1)链接/a; $safeContent sanitizeMessageContent($userInput); // 输出你好\n\n链接过滤逻辑详解strip_tags()移除script、img等标签但保留文本中的符号如数学公式htmlentities()将转为实体防止属性注入preg_replace()白名单匹配\p{L}所有语言字母、\p{N}所有数字、\p{P}所有标点、\s空白符、\u{3000}-\u{303F}中文标点、\u{3040}-\u{309F}平假名、\u{30A0}-\u{30FF}片假名覆盖主流东亚文字\x{0009}\x{000A}\x{000D}显式保留 Tab、LF、CR确保换行正常mb_substr()用 UTF-8 安全截断避免截断多字节字符。5.2 前端二次渲染用textContent替代innerHTML即使后端过滤严格前端仍需防御 DOM 注入// ❌ 危险直接 innerHTML 会执行 script // messageEl.innerHTML message.content; // ✅ 安全textContent 自动转义 messageEl.textContent message.content; // 若需支持简单格式如换行用 pre-wrap textContent messageEl.style.whiteSpace pre-wrap; messageEl.textContent message.content.replace(/\n/g, \n);为什么textContent更安全textContent将字符串作为纯文本插入bhello/b会原样显示不会加粗不触发任何事件监听器或脚本执行性能优于innerHTML无 HTML 解析开销与后端过滤形成“双重保险”。5.3 敏感词拦截用 Redis 实现毫秒级关键词匹配对“违法”、“诈骗”、“微信”等敏感词需实时拦截。MySQL LIKE 查询太慢应预加载到内存// init_sensitive_words.php启动时加载敏感词到 Redis $redis new Redis(); $redis-connect(127.0.0.1, 6379); // 从数据库读取敏感词带权重 $stmt $pdo-query(SELECT word, weight FROM sensitive_words WHERE enabled 1); while ($row $stmt-fetch(PDO::FETCH_ASSOC)) { $redis-hSet(sensitive_words, $row[word], $row[weight]); } // 检查函数 function checkSensitiveWords($content) { global $redis; // 提取所有连续中文、英文、数字组合忽略标点 preg_match_all(/[\x{4e00}-\x{9fff}a-zA-Z0-9]/u, $content, $matches); $words $matches[0]; $hit []; foreach ($words as $word) { $weight $redis-hGet(sensitive_words, $word); if ($weight ! false) { $hit[] [word $word, weight (int)$weight]; } } return $hit; } // 使用 $hits checkSensitiveWords(这个微信号码很危险); if (!empty($hits)) { error_log(Sensitive word detected: . json_encode($hits)); // 可触发告警、打标、或拒绝入库 }Redis 方案优势HGET时间复杂度 O(1)10 万词库查询 0.1ms支持热更新修改数据库后FLUSHALL并重载即可preg_match_all提取词干避免“微 信”拆分导致漏检。6. 高并发优化实战用 PHP-FPM 进程池 OPcache 缓存会话元数据当单台服务器承载日均 5000 咨询时原始 PHP 轮询架构会出现 CPU 暴涨、MySQL 连接数打满。此时不能盲目加机器而应从 PHP 层和 MySQL 层协同优化。6.1 PHP-FPM 进程池隔离为客服接口单独配置在www.conf中新增一个进程池专供get_messages.php和send_message.php使用; /etc/php/8.1/fpm/pool.d/chat.conf [chat] listen /run/php/php8.1-fpm-chat.sock listen.owner www-data listen.group www-data listen.mode 0660 pm static pm.max_children 32 pm.start_servers 16 pm.min_spare_servers 8 pm.max_spare_servers 24 ; 降低超时避免长轮询占满进程 request_terminate_timeout 30s request_slowlog_timeout 10s ; 仅加载必要扩展 php_admin_value[extension] mysqli.so php_admin_value[extension] pdo_mysql.so php_admin_value[opcache.enable] 1Nginx 配置指向该 socketlocation ~ ^/chat/(get_messages|send_message)\.php$ { fastcgi_pass unix:/run/php/php8.1-fpm-chat.sock; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }隔离效果客服轮询请求不再与首页、商品页共用进程池避免慢请求阻塞主站pm.max_children 32限制最大并发连接数防止 MySQL 连接耗尽request_terminate_timeout 30s强制中断卡死请求保护进程池。6.2 OPcache 缓存会话元数据减少 MySQL 查询每次轮询都要查chat_sessions和chat_messages其中chat_sessions的status和operator_id属于低频变更数据可缓存 60 秒function getCachedSession($sessionId) { $cacheKey session_{$sessionId}; // 尝试 OPcache if (opcache_is_script_cached($cacheKey)) { $cached opcache_get_status()[scripts][$cacheKey][cached_timestamp] ?? 0; if (time() - $cached 60) { return opcache_get_status()[scripts][$cacheKey][cached_content] ?? null; } } // 未命中则查 DB并写入 OPcache需开启 opcache.file_cache global $pdo; $stmt $pdo-prepare(SELECT operator_id, status FROM chat_sessions WHERE id ?); $stmt-execute([$sessionId]); $session $stmt-fetch(PDO::FETCH_ASSOC); if ($session) { // 写入文件缓存OPcache file cache $cacheFile /tmp/opcache/session_ . $sessionId . .php; file_put_contents($cacheFile, ?php return . var_export($session, true) . ;); opcache_compile_file($cacheFile); } return $session; }提示opcache.file_cache需在php.ini中启用路径设为 SSD 目录避免 NFS 慢盘。6.3 MySQL 查询优化为chat_messages添加复合索引原始轮询查询WHERE session_id ? AND id ? ORDER BY id ASC LIMIT 50若只有INDEX(session_id)MySQL 仍需扫描大量行。添加覆盖索引-- 删除旧索引 DROP INDEX idx_session_id ON chat_messages; -- 创建新复合索引 CREATE INDEX idx_session_id_id ON chat_messages (session_id, id) COMMENT Covering index for polling queries;索引生效验证EXPLAIN SELECT id, sender_type, sender_id, content, sent_at FROM chat_messages WHERE session_id 123 AND id 456 ORDER BY id ASC LIMIT 50;输出中key应为idx_session_id_idrows应接近LIMIT值50而非全表扫描。本文还有配套的精品资源点击获取
