简介基于ThinkPHP框架打造的运营级在线客服系统源码面向需要快速搭建网页客服、多坐席协作与智能客服平台的开发者和企业技术团队可直接用于电商、官网、SaaS产品等场景的客户服务模块。系统包含实时聊天、坐席状态管理、访客分配、智能自动回复与智能推荐等核心功能采用前后端分离架构适配NginxPHP7.3MySQL5.6环境并附详细的部署与二次开发教程便于快速上手。整套资源共2010个文件以JS、HTML、CSS等前端资源为主配合PHP后端逻辑、SQL建表脚本以及Markdown/TXT说明文档压缩后约67.91MB目录层级完整适合本地搭建与对照学习。目前已有134人浏览/学习源码覆盖完整客服业务链路并保留了可扩展的模块化结构对希望深入掌握ThinkPHP企业级项目实践、或需要快速交付客服方案的团队来说是一份扎实的参考资料。1. 在线客服系统的选型与架构背景在线客户服务被验证为一道“慢半秒就流失”的转化环节。电商大促期间访客同时在线、坐席排队、消息乱序几乎同时爆发而自研即时通信的成本往往被严重低估团队急需一个现成可改、能扛住并发的基础底座。这套基于 ThinkPHP 框架开发的运营级在线客服系统源码把网页客服、多坐席分配、智能自动回复三条主干功能打包在一起运行在 Nginx PHP 7.3 MySQL 5.6 这套经典组合上。前端资源完整后台具备规则配置能力附带的教程文档覆盖了安装部署和基本使用。对已有 PHP 运维基础、想绕开商业 SaaS 客服数据边界的团队来说核心功能层和扩展点都在框架层留好不用从零写会话和消息表。下文按架构设计、部署调优、二次开发三个层次把这套系统拆开讲。2. ThinkPHP 路由与客服核心模块的实现思路2.1 路由设计与访客会话建立访客侧的会话建立本质上是“匿名用户身份标识 会话 ID 绑定”的过程。ThinkPHP 框架里路由定义决定了客服端入口和访客端入口如何分流。常见做法是在route.php中显式声明路由规则而不是依赖默认的 controller/action 拼接// 访客端入口 Route::rule(visit/index, index/Visitor/index); // 坐席端登录 Route::rule(agent/login, agent/Account/login); // 前端轮询接口 Route::rule(chat/poll, index/Chat/poll); // 坐席分配接口 Route::rule(chat/assign, index/Chat/assign);这里把访客端和坐席端拆成两个控制器分组核心原因是两者挂载的中间件不同。访客端只需要校验会话 token坐席端还要校验登录态和坐席角色权限。Route::rule第一个参数是外部访问路径第二个参数是内部控制器映射例如index/Visitor/index表示 index 模块下 Visitor 控制器的 index 方法。部署后我会在公共入口先判断是否携带有效的visitor_token没有则先创建会话记录再进入消息拉取逻辑避免访客直接访问轮询接口时拿不到 session_id。会话 token 的生成不建议直接用自增 ID容易被遍历。我一般用Session::getId()拼接一段随机串再按 user_id 或 visitor_ip 维度绑定到会话表。访客会话记录本身需要带上来源页 URL、User-Agent、IP 三段信息后续做来源统计和防骚扰时这三段是最基础的维度。注意 IP 段在 Nginx 反代场景下要从HTTP_X_FORWARDED_FOR读取直接在 PHP 里读REMOTE_ADDR拿到的是代理服务器地址坐席端展示的归属地会全部错乱。2.2 多坐席分配策略与排队逻辑多坐席分配是运营级客服系统和 demo 级项目的分水岭。demo 通常把新会话直接派给最后登录的坐席但真实场景下会出现某个坐席被塞满、其他人闲置的情况。比较常见的分配策略有三种轮询、最少会话数优先、空闲时长优先实际运用中还会叠加“忙碌中不参与分配”的判断。这套源码的默认分配逻辑是取在线且当前会话数最少的坐席// 默认分配策略在线坐席中取当前负载最小者 public function dispatch($visitorId) { $agents Db::name(agent) -where(online_status, 1) -order(current_load ASC, last_active_time ASC) -limit(10) -select(); if (empty($agents)) { return $this-enqueue($visitorId); // 进入排队队列 } $target $agents[0]; Db::name(agent)-where(id, $target[id]) -setInc(current_load); return $target[id]; }current_load的维护点有两处坐席点击“结束会话”时减一访客长时间不发言触发超时回收时减一。最容易踩坑的是并发下的原子性setInc生成的是UPDATE agent SET current_load current_load 1行级原子操作直接调用即可不要先select出来加一再update高并发下会丢更新。如果坐席规模超过 50 人建议把在线坐席列表缓存在 Redis 中分配时只读缓存减少数据库读压力。三种策略的选型对比如下策略适用规模优点缺点轮询分配10 人以下小团队实现最简单逻辑透明无法感知坐席实际忙碌度最少会话数优先10-50 人客服团队负载均衡效果最直观需要维护实时会话计数字段空闲时长优先排班制团队响应速度更稳定空闲统计本身有额外开销实际业务里轮询和空闲时长往往组合使用新会话先检查坐席的online_status再按current_load升序取第一个。排队队列用 MySQL 表实现时要记得给status 0的排队记录加索引否则访客量上来后enqueue和dequeue都会变慢。排队中的访客建议每分钟推一次“当前排队位置”从体验上说比干等要好很多。2.3 消息表与 MySQL 5.6 的兼容性设计MySQL 5.6 对 JSON 字段类型的支持不理想JSON 类型要到 5.7 才正式可用。这套源码里消息内容、访客信息、扩展字段全部拆成平铺字段避免依赖 JSON 函数CREATE TABLE chat_message ( id int(11) NOT NULL AUTO_INCREMENT, session_id int(11) NOT NULL COMMENT 会话ID, from_type tinyint(1) NOT NULL DEFAULT 0 COMMENT 0访客 1坐席 2系统, from_user varchar(64) NOT NULL COMMENT 发送方标识, content text COMMENT 消息内容, msg_type tinyint(1) NOT NULL DEFAULT 0 COMMENT 0文本 1图片 2文件, create_time int(11) NOT NULL COMMENT Unix时间戳, PRIMARY KEY (id), KEY idx_session_time (session_id, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT聊天消息表;设计上的几个细节值得注意。create_time用 int 时间戳而不是 datetime是为了会话归档和冷热数据分离时区间查询更快且不受时区配置影响。from_type和from_user分开存是因为系统转接消息、坐席回复、访客留言在展示层走完全不同的渲染逻辑。复合索引idx_session_time服务于消息翻页和未读计数避免每次会话打开都做全表扫描。MySQL 5.6 下有两点很容易踩一是 utf8mb4 的索引长度限制varchar 超过 191 字符再建索引会报 767 字节上限错误二是 5.6 默认的 sql_mode 对严格模式支持不完整插入超长字符串可能只是截断而不是报错导致消息内容莫名丢失结尾字符。会话表也建议加一个channel字段标记访客来源是 PC 端还是 H5 端后续统计网页客服转化率时特别有用。3. Nginx 与 PHP 7.3 环境下的部署与参数调优3.1 环境版本匹配与站点配置先把环境对齐PHP 7.3、MySQL 5.6、Nginx 1.16 以上。PHP 7.3 对 ThinkPHP 的兼容性很好闭包路由、标量类型声明、list()解构都能正常使用。部署时优先确认 PHP 是否装了pdo_mysql、mbstring、curl三个扩展缺任何一个都会在安装向导或首次请求时报错。Nginx 站点配置需要处理 pathinfo 形式的 URL 重写否则首页可以打开、但聊天接口全部 404server { listen 80; server_name kefu.example.com; root /www/wwwroot/kefu/public; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } access_log /data/logs/kefu.access.log main; }rewrite ^(.*)$ /index.php?s$1 last;是把 ThinkPHP 的 PATH_INFO 转换成 query 参数模式适用于未开启cgi.fix_pathinfo的环境。fastcgi_pass 127.0.0.1:9000对应 PHP-FPM 的 TCP 监听如果改成 unix socket 方式需要同步调整 fastcgi_pass 的路径。root 指向public目录而不是项目根目录因为 ThinkPHP 的入口文件只在public下这样可避免外部直接访问application、runtime目录。源码包上传时还要注意一个细节runtime目录不要整个覆盖到线上。本地调试产生的编译缓存、日志文件如果跟着上线会和新环境配置冲突表现是登录跳转异常、SESSION 写入失败。我一般会把runtime目录清空后保留空目录加写入权限再同步代码。3.2 PHP-FPM 进程数与并发兜底客服系统的并发模型和普通门户站不同。访客会长时间保持轮询请求占用 PHP-FPM worker 的时间远长于普通请求默认的 50 个max_children在大促场景下很快被打满。可以按下面的参数起步pm dynamic pm.max_children 80 pm.start_servers 20 pm.min_spare_servers 10 pm.max_spare_servers 30 pm.max_requests 1000pm.max_requests 1000是为了定期回收可能发生内存泄漏的 worker这个值不要设太小否则 worker 频繁重启反而增加 CPU 开销。更合理的max_children要根据单进程内存反推先用下面的命令统计ps aux | grep php-fpm | awk {sum$6; n} END {print sum/n/1024 MB}这条命令把所有 php-fpm 进程的 RSS 内存求和再除以进程数得到单进程平均内存占用然后按(总内存 - 系统预留) / 单进程内存计算 max_children。比如 8G 内存的机器单进程 80MBmax_children 设在 80 左右是安全的。轮询接口的空转消耗也要处理。我一般会在消息拉取接口里加上set_time_limit(25)让请求在服务端保持 25 秒再返回配合前端 30 秒的轮询间隔能把无效请求量减少一半。上线后观察 Nginx access log如果 502 和 503 比例超过 1%先看max_children是不是被打满了再决定是加机器还是换长连接方案。3.3 部署阶段高频报错定位部署阶段的问题大多集中在 runtime 目录权限和 PHP 扩展缺失两块。常见现象与处理方式如下报错现象原因处理方式首页正常接口 404Nginx 伪静态规则未生效检查 location / 的 rewrite 后 reload提示 mbstring 扩展缺失PHP 7.3 未安装 mbstring安装对应扩展并重启 PHP-FPM数据库连接失败MySQL 5.6 用户名密码或 auth 插件不匹配确认使用 mysql_native_password登录后立刻退出runtime 会话文件写入失败修正 runtime 目录属主与写权限定位时先把 PHP 错误日志打开入口文件顶部加error_reporting(E_ALL);再复现一次请求看具体报错。注意 ThinkPHP 自带调试模式.env里把app_debug设为 true 能看到完整的调用栈和 SQL 日志但上线前必须关掉否则会把表结构、缓存路径暴露给访客。4. 智能自动回复与前端实时交互的实现4.1 关键字匹配与自动回复触发链路智能客服平台在源码层面通常落成一套规则匹配引擎。后台配置自动回复规则后访客消息进来先走匹配命中就直接回复没命中才进入人工坐席队列。触发链路是消息入库 → 调用匹配服务 → 命中则生成系统回复 → 未命中则进入坐席分配。public function matchReply($content) { $rules Db::name(auto_reply) -where(status, 1) -order(priority DESC, id ASC) -select(); foreach ($rules as $rule) { if ($rule[match_type] 1 strpos($content, $rule[keyword]) ! false) { return $rule[reply_content]; } if ($rule[match_type] 2 preg_match(/ . $rule[keyword] . /, $content)) { return $rule[reply_content]; } } return ; }match_type 1是包含匹配strpos判断消息里是否出现关键词match_type 2是正则匹配适用于“订单号退款”这类组合条件。规则表里的priority字段控制多条规则同时命中的优先级数字越大越先执行。需要注意正则规则不要直接拼接用户输入作为preg_match模式后台配置时要做转义校验否则一个错误的正则可以打挂整个 FPM 进程。自动回复命中后建议在消息表里写入from_type 2的系统消息前端渲染时显示为机器人头像访客感知更自然。4.2 前端实时通信的轮询与 WebSocket 取舍网页客服的前端消息拉取有两种主流方案短轮询和 WebSocket。这套源码默认是轮询因为 PHP-FPM 是短生命周期模型跑 WebSocket 需要额外的常驻进程轮询的代价是 30 秒一次的请求频率在坐席量大的时候会形成固定 QPS 底座。前端实现通常这样写function pollMessage(sessionId, lastMsgId) { setInterval(async () { const res await fetch(/index.php?s/chat/poll, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ session_id: sessionId, last_msg_id: lastMsgId }) }); const data await res.json(); if (data.list data.list.length 0) { renderMessages(data.list); lastMsgId data.list[data.list.length - 1].id; } }, 30000); }last_msg_id作为游标传给服务端服务端只返回大于该 ID 的消息避免重复渲染。轮询接口里要加一个上限比如一次最多返回 200 条超出的引导访客刷新页面加载历史消息。两种方案的对比可以简单概括为对比项轮询方案WebSocket 推送实时性最长延迟一个轮询间隔毫秒级服务端占用PHP-FPM worker 被请求占用独立常驻进程承载部署复杂度直接可用需要进程守护和端口放行适用规模坐席数 30 人以内消息量大、延迟敏感4.3 访客会话状态维持与超时回收多坐席客服场景里访客关闭浏览器但没点“结束会话”很常见会话记录会一直占用坐席负载。系统里通常会设定一个空闲超时比如 10 分钟没有新消息就把会话标记为status 3的已超时状态同时释放坐席的current_load。超时回收可以用定时任务也可以惰性检查轮询接口每次先查update_time超过阈值就自动关闭会话并返回特定的 code前端收到后显示“会话已结束”。超时时间的配置入口一般在应用配置文件的session_timeout参数调成 600 表示 10 分钟。线上运营时要注意超时回收不是越短越好访客可能只是切去看别的页面回来发现会话被关闭会明显降低满意度。我一般会在前端监听visibilitychange事件页面重新可见时先调一次状态查询接口让服务端把会话重新激活。还有一个产品细节需要想清楚访客离开页面后又回来系统是重建会话还是复用旧会话推荐的做法是保留同一个session_id只把历史消息重新拉出来这样访客不用重复描述问题。实现上只需要在访客 token 里带上session_id服务端做一次状态恢复即可。释放坐席负载的时机要和超时回收一致否则会出现坐席明明没在聊天、却显示忙碌的假象。5. 二次开发的扩展点与链路验证技巧5.1 把轮询升级为主动推送源码里/chat/poll是轮询入口升级推送的侵入点有两个一是消息入库后触发事件把新消息写入 Redis 的频道二是增加一个 Workerman 常驻进程订阅频道并推送给前端。PHP 7.3 下实现最小推送服务只需要几条命令composer require workerman/workerman php think workerman:start --channelkefu_msg这里不需要改消息表结构只把chat_message表的插入操作后面加一次Redis::publish(kefu_msg, json_encode($msg))。坐席端通过 WebSocket 连接 Workerman 端口收到kefu_msg频道的消息后再校验 session 归属。注意 Workerman 进程要由 supervisor 托管崩溃后自动拉起否则推送链路会静默断开。5.2 验证分配与推送链路是否真正打通验证多坐席分配是否生效最直接的方法是用命令行模拟两个访客同时发起会话。先查数据库确认会话分配给了不同的坐席SELECT session_id, agent_id, status FROM chat_session WHERE create_time UNIX_TIMESTAMP() - 60;如果两个会话分给了同一个坐席检查坐席的online_status和current_load字段是不是没被正确维护。再验证自动回复链路可以直接在 MySQL 里插入一条带触发词的访客消息然后调轮询接口看是否返回from_type 2的系统回复。消息推送延迟用curl测一轮最直接curl -X POST http://127.0.0.1/index.php?s/chat/poll \ -H Content-Type: application/json \ -d {session_id: 1, last_msg_id: 0}本文还有配套的精品资源点击获取
简介基于ThinkPHP框架打造的运营级在线客服系统源码面向需要快速搭建网页客服、多坐席协作与智能客服平台的开发者和企业技术团队可直接用于电商、官网、SaaS产品等场景的客户服务模块。系统包含实时聊天、坐席状态管理、访客分配、智能自动回复与智能推荐等核心功能采用前后端分离架构适配NginxPHP7.3MySQL5.6环境并附详细的部署与二次开发教程便于快速上手。整套资源共2010个文件以JS、HTML、CSS等前端资源为主配合PHP后端逻辑、SQL建表脚本以及Markdown/TXT说明文档压缩后约67.91MB目录层级完整适合本地搭建与对照学习。目前已有134人浏览/学习源码覆盖完整客服业务链路并保留了可扩展的模块化结构对希望深入掌握ThinkPHP企业级项目实践、或需要快速交付客服方案的团队来说是一份扎实的参考资料。1. 在线客服系统的选型与架构背景在线客户服务被验证为一道“慢半秒就流失”的转化环节。电商大促期间访客同时在线、坐席排队、消息乱序几乎同时爆发而自研即时通信的成本往往被严重低估团队急需一个现成可改、能扛住并发的基础底座。这套基于 ThinkPHP 框架开发的运营级在线客服系统源码把网页客服、多坐席分配、智能自动回复三条主干功能打包在一起运行在 Nginx PHP 7.3 MySQL 5.6 这套经典组合上。前端资源完整后台具备规则配置能力附带的教程文档覆盖了安装部署和基本使用。对已有 PHP 运维基础、想绕开商业 SaaS 客服数据边界的团队来说核心功能层和扩展点都在框架层留好不用从零写会话和消息表。下文按架构设计、部署调优、二次开发三个层次把这套系统拆开讲。2. ThinkPHP 路由与客服核心模块的实现思路2.1 路由设计与访客会话建立访客侧的会话建立本质上是“匿名用户身份标识 会话 ID 绑定”的过程。ThinkPHP 框架里路由定义决定了客服端入口和访客端入口如何分流。常见做法是在route.php中显式声明路由规则而不是依赖默认的 controller/action 拼接// 访客端入口 Route::rule(visit/index, index/Visitor/index); // 坐席端登录 Route::rule(agent/login, agent/Account/login); // 前端轮询接口 Route::rule(chat/poll, index/Chat/poll); // 坐席分配接口 Route::rule(chat/assign, index/Chat/assign);这里把访客端和坐席端拆成两个控制器分组核心原因是两者挂载的中间件不同。访客端只需要校验会话 token坐席端还要校验登录态和坐席角色权限。Route::rule第一个参数是外部访问路径第二个参数是内部控制器映射例如index/Visitor/index表示 index 模块下 Visitor 控制器的 index 方法。部署后我会在公共入口先判断是否携带有效的visitor_token没有则先创建会话记录再进入消息拉取逻辑避免访客直接访问轮询接口时拿不到 session_id。会话 token 的生成不建议直接用自增 ID容易被遍历。我一般用Session::getId()拼接一段随机串再按 user_id 或 visitor_ip 维度绑定到会话表。访客会话记录本身需要带上来源页 URL、User-Agent、IP 三段信息后续做来源统计和防骚扰时这三段是最基础的维度。注意 IP 段在 Nginx 反代场景下要从HTTP_X_FORWARDED_FOR读取直接在 PHP 里读REMOTE_ADDR拿到的是代理服务器地址坐席端展示的归属地会全部错乱。2.2 多坐席分配策略与排队逻辑多坐席分配是运营级客服系统和 demo 级项目的分水岭。demo 通常把新会话直接派给最后登录的坐席但真实场景下会出现某个坐席被塞满、其他人闲置的情况。比较常见的分配策略有三种轮询、最少会话数优先、空闲时长优先实际运用中还会叠加“忙碌中不参与分配”的判断。这套源码的默认分配逻辑是取在线且当前会话数最少的坐席// 默认分配策略在线坐席中取当前负载最小者 public function dispatch($visitorId) { $agents Db::name(agent) -where(online_status, 1) -order(current_load ASC, last_active_time ASC) -limit(10) -select(); if (empty($agents)) { return $this-enqueue($visitorId); // 进入排队队列 } $target $agents[0]; Db::name(agent)-where(id, $target[id]) -setInc(current_load); return $target[id]; }current_load的维护点有两处坐席点击“结束会话”时减一访客长时间不发言触发超时回收时减一。最容易踩坑的是并发下的原子性setInc生成的是UPDATE agent SET current_load current_load 1行级原子操作直接调用即可不要先select出来加一再update高并发下会丢更新。如果坐席规模超过 50 人建议把在线坐席列表缓存在 Redis 中分配时只读缓存减少数据库读压力。三种策略的选型对比如下策略适用规模优点缺点轮询分配10 人以下小团队实现最简单逻辑透明无法感知坐席实际忙碌度最少会话数优先10-50 人客服团队负载均衡效果最直观需要维护实时会话计数字段空闲时长优先排班制团队响应速度更稳定空闲统计本身有额外开销实际业务里轮询和空闲时长往往组合使用新会话先检查坐席的online_status再按current_load升序取第一个。排队队列用 MySQL 表实现时要记得给status 0的排队记录加索引否则访客量上来后enqueue和dequeue都会变慢。排队中的访客建议每分钟推一次“当前排队位置”从体验上说比干等要好很多。2.3 消息表与 MySQL 5.6 的兼容性设计MySQL 5.6 对 JSON 字段类型的支持不理想JSON 类型要到 5.7 才正式可用。这套源码里消息内容、访客信息、扩展字段全部拆成平铺字段避免依赖 JSON 函数CREATE TABLE chat_message ( id int(11) NOT NULL AUTO_INCREMENT, session_id int(11) NOT NULL COMMENT 会话ID, from_type tinyint(1) NOT NULL DEFAULT 0 COMMENT 0访客 1坐席 2系统, from_user varchar(64) NOT NULL COMMENT 发送方标识, content text COMMENT 消息内容, msg_type tinyint(1) NOT NULL DEFAULT 0 COMMENT 0文本 1图片 2文件, create_time int(11) NOT NULL COMMENT Unix时间戳, PRIMARY KEY (id), KEY idx_session_time (session_id, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT聊天消息表;设计上的几个细节值得注意。create_time用 int 时间戳而不是 datetime是为了会话归档和冷热数据分离时区间查询更快且不受时区配置影响。from_type和from_user分开存是因为系统转接消息、坐席回复、访客留言在展示层走完全不同的渲染逻辑。复合索引idx_session_time服务于消息翻页和未读计数避免每次会话打开都做全表扫描。MySQL 5.6 下有两点很容易踩一是 utf8mb4 的索引长度限制varchar 超过 191 字符再建索引会报 767 字节上限错误二是 5.6 默认的 sql_mode 对严格模式支持不完整插入超长字符串可能只是截断而不是报错导致消息内容莫名丢失结尾字符。会话表也建议加一个channel字段标记访客来源是 PC 端还是 H5 端后续统计网页客服转化率时特别有用。3. Nginx 与 PHP 7.3 环境下的部署与参数调优3.1 环境版本匹配与站点配置先把环境对齐PHP 7.3、MySQL 5.6、Nginx 1.16 以上。PHP 7.3 对 ThinkPHP 的兼容性很好闭包路由、标量类型声明、list()解构都能正常使用。部署时优先确认 PHP 是否装了pdo_mysql、mbstring、curl三个扩展缺任何一个都会在安装向导或首次请求时报错。Nginx 站点配置需要处理 pathinfo 形式的 URL 重写否则首页可以打开、但聊天接口全部 404server { listen 80; server_name kefu.example.com; root /www/wwwroot/kefu/public; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } access_log /data/logs/kefu.access.log main; }rewrite ^(.*)$ /index.php?s$1 last;是把 ThinkPHP 的 PATH_INFO 转换成 query 参数模式适用于未开启cgi.fix_pathinfo的环境。fastcgi_pass 127.0.0.1:9000对应 PHP-FPM 的 TCP 监听如果改成 unix socket 方式需要同步调整 fastcgi_pass 的路径。root 指向public目录而不是项目根目录因为 ThinkPHP 的入口文件只在public下这样可避免外部直接访问application、runtime目录。源码包上传时还要注意一个细节runtime目录不要整个覆盖到线上。本地调试产生的编译缓存、日志文件如果跟着上线会和新环境配置冲突表现是登录跳转异常、SESSION 写入失败。我一般会把runtime目录清空后保留空目录加写入权限再同步代码。3.2 PHP-FPM 进程数与并发兜底客服系统的并发模型和普通门户站不同。访客会长时间保持轮询请求占用 PHP-FPM worker 的时间远长于普通请求默认的 50 个max_children在大促场景下很快被打满。可以按下面的参数起步pm dynamic pm.max_children 80 pm.start_servers 20 pm.min_spare_servers 10 pm.max_spare_servers 30 pm.max_requests 1000pm.max_requests 1000是为了定期回收可能发生内存泄漏的 worker这个值不要设太小否则 worker 频繁重启反而增加 CPU 开销。更合理的max_children要根据单进程内存反推先用下面的命令统计ps aux | grep php-fpm | awk {sum$6; n} END {print sum/n/1024 MB}这条命令把所有 php-fpm 进程的 RSS 内存求和再除以进程数得到单进程平均内存占用然后按(总内存 - 系统预留) / 单进程内存计算 max_children。比如 8G 内存的机器单进程 80MBmax_children 设在 80 左右是安全的。轮询接口的空转消耗也要处理。我一般会在消息拉取接口里加上set_time_limit(25)让请求在服务端保持 25 秒再返回配合前端 30 秒的轮询间隔能把无效请求量减少一半。上线后观察 Nginx access log如果 502 和 503 比例超过 1%先看max_children是不是被打满了再决定是加机器还是换长连接方案。3.3 部署阶段高频报错定位部署阶段的问题大多集中在 runtime 目录权限和 PHP 扩展缺失两块。常见现象与处理方式如下报错现象原因处理方式首页正常接口 404Nginx 伪静态规则未生效检查 location / 的 rewrite 后 reload提示 mbstring 扩展缺失PHP 7.3 未安装 mbstring安装对应扩展并重启 PHP-FPM数据库连接失败MySQL 5.6 用户名密码或 auth 插件不匹配确认使用 mysql_native_password登录后立刻退出runtime 会话文件写入失败修正 runtime 目录属主与写权限定位时先把 PHP 错误日志打开入口文件顶部加error_reporting(E_ALL);再复现一次请求看具体报错。注意 ThinkPHP 自带调试模式.env里把app_debug设为 true 能看到完整的调用栈和 SQL 日志但上线前必须关掉否则会把表结构、缓存路径暴露给访客。4. 智能自动回复与前端实时交互的实现4.1 关键字匹配与自动回复触发链路智能客服平台在源码层面通常落成一套规则匹配引擎。后台配置自动回复规则后访客消息进来先走匹配命中就直接回复没命中才进入人工坐席队列。触发链路是消息入库 → 调用匹配服务 → 命中则生成系统回复 → 未命中则进入坐席分配。public function matchReply($content) { $rules Db::name(auto_reply) -where(status, 1) -order(priority DESC, id ASC) -select(); foreach ($rules as $rule) { if ($rule[match_type] 1 strpos($content, $rule[keyword]) ! false) { return $rule[reply_content]; } if ($rule[match_type] 2 preg_match(/ . $rule[keyword] . /, $content)) { return $rule[reply_content]; } } return ; }match_type 1是包含匹配strpos判断消息里是否出现关键词match_type 2是正则匹配适用于“订单号退款”这类组合条件。规则表里的priority字段控制多条规则同时命中的优先级数字越大越先执行。需要注意正则规则不要直接拼接用户输入作为preg_match模式后台配置时要做转义校验否则一个错误的正则可以打挂整个 FPM 进程。自动回复命中后建议在消息表里写入from_type 2的系统消息前端渲染时显示为机器人头像访客感知更自然。4.2 前端实时通信的轮询与 WebSocket 取舍网页客服的前端消息拉取有两种主流方案短轮询和 WebSocket。这套源码默认是轮询因为 PHP-FPM 是短生命周期模型跑 WebSocket 需要额外的常驻进程轮询的代价是 30 秒一次的请求频率在坐席量大的时候会形成固定 QPS 底座。前端实现通常这样写function pollMessage(sessionId, lastMsgId) { setInterval(async () { const res await fetch(/index.php?s/chat/poll, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ session_id: sessionId, last_msg_id: lastMsgId }) }); const data await res.json(); if (data.list data.list.length 0) { renderMessages(data.list); lastMsgId data.list[data.list.length - 1].id; } }, 30000); }last_msg_id作为游标传给服务端服务端只返回大于该 ID 的消息避免重复渲染。轮询接口里要加一个上限比如一次最多返回 200 条超出的引导访客刷新页面加载历史消息。两种方案的对比可以简单概括为对比项轮询方案WebSocket 推送实时性最长延迟一个轮询间隔毫秒级服务端占用PHP-FPM worker 被请求占用独立常驻进程承载部署复杂度直接可用需要进程守护和端口放行适用规模坐席数 30 人以内消息量大、延迟敏感4.3 访客会话状态维持与超时回收多坐席客服场景里访客关闭浏览器但没点“结束会话”很常见会话记录会一直占用坐席负载。系统里通常会设定一个空闲超时比如 10 分钟没有新消息就把会话标记为status 3的已超时状态同时释放坐席的current_load。超时回收可以用定时任务也可以惰性检查轮询接口每次先查update_time超过阈值就自动关闭会话并返回特定的 code前端收到后显示“会话已结束”。超时时间的配置入口一般在应用配置文件的session_timeout参数调成 600 表示 10 分钟。线上运营时要注意超时回收不是越短越好访客可能只是切去看别的页面回来发现会话被关闭会明显降低满意度。我一般会在前端监听visibilitychange事件页面重新可见时先调一次状态查询接口让服务端把会话重新激活。还有一个产品细节需要想清楚访客离开页面后又回来系统是重建会话还是复用旧会话推荐的做法是保留同一个session_id只把历史消息重新拉出来这样访客不用重复描述问题。实现上只需要在访客 token 里带上session_id服务端做一次状态恢复即可。释放坐席负载的时机要和超时回收一致否则会出现坐席明明没在聊天、却显示忙碌的假象。5. 二次开发的扩展点与链路验证技巧5.1 把轮询升级为主动推送源码里/chat/poll是轮询入口升级推送的侵入点有两个一是消息入库后触发事件把新消息写入 Redis 的频道二是增加一个 Workerman 常驻进程订阅频道并推送给前端。PHP 7.3 下实现最小推送服务只需要几条命令composer require workerman/workerman php think workerman:start --channelkefu_msg这里不需要改消息表结构只把chat_message表的插入操作后面加一次Redis::publish(kefu_msg, json_encode($msg))。坐席端通过 WebSocket 连接 Workerman 端口收到kefu_msg频道的消息后再校验 session 归属。注意 Workerman 进程要由 supervisor 托管崩溃后自动拉起否则推送链路会静默断开。5.2 验证分配与推送链路是否真正打通验证多坐席分配是否生效最直接的方法是用命令行模拟两个访客同时发起会话。先查数据库确认会话分配给了不同的坐席SELECT session_id, agent_id, status FROM chat_session WHERE create_time UNIX_TIMESTAMP() - 60;如果两个会话分给了同一个坐席检查坐席的online_status和current_load字段是不是没被正确维护。再验证自动回复链路可以直接在 MySQL 里插入一条带触发词的访客消息然后调轮询接口看是否返回from_type 2的系统回复。消息推送延迟用curl测一轮最直接curl -X POST http://127.0.0.1/index.php?s/chat/poll \ -H Content-Type: application/json \ -d {session_id: 1, last_msg_id: 0}本文还有配套的精品资源点击获取
)
)
