简介朵米3.5客服系统源码2023正式版是一套面向企业级客户服务场景的全功能源码适合需要搭建在线客服平台的技术人员与运营团队。系统覆盖多渠道接入、智能路由分配、工单处理及数据分析等核心模块能够帮助企业将客户请求快速分派给合适坐席并借助报表洞察服务短板。资源包共2000个文件压缩后43.85MB以JavaScript、HTML、CSS前端文件为主辅以PHP后端逻辑、MySQL数据库脚本及Shell部署脚本另有Word版搭建配置文档方便本地还原运行环境。目前已有384人学习/下载可直接学习ThinkPHP架构下的客服系统开发思路掌握宝塔面板配合Nginx、PHP7.1-7.3及MySQL5.6-5.7的环境配置方法并参考文档完成从上传解压、设置运行目录到导入数据库的完整部署流程是二次开发或系统学习客服产品设计的实用范本。1. 为什么要把朵米3.5客服系统源码拿下来自己部署客服系统的采购决策里最常见的坑是买完 SaaS 才发现改不动。坐席台要接内部工单、访客端要嵌自己的 H5、消息记录要定期归档到数仓SaaS 给的接口要么没有、要么限频、要么按调用量单独收费。朵米3.5客服系统源码这类以源码交付的方案解决的就是这个问题代码在你手里前端聊天窗、坐席工作台、管理后台的路由规则都能改消息数据落在自己的 MySQL 里权限和留存策略自己说了算。拿 2023 正式版这个版本号做生产部署不代表装完就能跑得稳它真正值钱的地方在于你可以顺着代码理解“一条访客消息怎么从网页进到坐席窗口”按自己的业务重写分配与提醒逻辑。这篇文章会按我部署过同类 PHP 客服系统的经验把架构拆解、LNMP 部署、二开入口和排错验证串起来适合有服务器操作经验、准备接手这套源码做私有化或二次开发的工程师。2. 拆开朵米3.5客服系统源码先看懂架构、模块与消息链路2.1 三端结构管理端、坐席端、访客端在源码里的分工拿到任意一套 PHP 客服系统源码先不要急着配站点。按访问角色去分目录基本都能理出三条主线管理端负责配置路由、坐席分组、欢迎语和知识库坐席端是浏览器里的工作台处理会话、转接、查看访客地理与来源访客端是嵌入业务页面的聊天窗口负责发起会话、传图片、收回复。朵米3.5这个版本延续了常见的 MVC 分层入口一般会做在 web 根目录下静态资源与业务代码分离如果下载目录里看到类似 application、public、runtime 这样的顶层文件夹就用 ThinkPHP 风格的方式去理解它application 下按模块再拆public 作为唯一对外暴露目录runtime 存缓存与日志。站在二次开发的角度这三个端在代码里对应三套不同的交互频率。管理端低频、重配置坐席端中频、依赖实时会话列表访客端高频、要能快速建立连接。所以源码里大概率会把聊天消息相关逻辑独立成接口或控制器而不是跟用户管理混在一起。看代码时先定位三件事访客提交咨询的入口方法、坐席拉取会话列表的入口方法、以及消息推送或轮询的地址。把这三个点标出来整张数据链路就通了。2.2 技术栈选型PHP、数据库、Web 服务与消息进程怎么组合以 2023 年这个时间点发布、面向私有化部署的 PHP 客服系统最常见的技术栈配置是 PHP 7.2 到 7.4、MySQL 5.7 或 MariaDB 10.3、Nginx 或 Apache再叠加 Redis 做缓存、可选 Workerman/GatewayWorker 做长连接推送。选这套组合的原因很实际PHP 7.4 对主流框架兼容性好内存占用比 PHP 8 更可控MySQL 5.7 的 JSON 类型和全文索引足够支撑会话检索Nginx 处理静态文件和反向代理的效率高不会在聊天轮询上抢 PHP-FPM 的进程。下表是我建议的基准环境低于这个版本容易在安装扩展、导入 SQL 时报错。组件推荐版本说明PHP7.4最低 7.2若源码跑在 PHP 8 上报Array and string offset access类错误通常是旧框架语法兼容问题先切回 7.4 再排查MySQL / MariaDB5.7 / 10.3数据库排序规则建议用 utf8mb4_general_ci避免访客昵称里的特殊字符报错Nginx / ApacheNginx 1.18 / Apache 2.4Nginx 需要配伪静态Apache 需要开 mod_rewriteRedis5.x / 6.x可选主要用于缓存会话状态和排队计数小并发可先不装常驻进程Workerman / GatewayWorker如果源码带 WebSocket 推送需要 CLI 模式启动并配合 supervisor 守护这里有个容易踩的坑很多人拿到源码后沿用服务器上已有的 PHP 5.6 或 PHP 8.1 去跑前者缺类型声明、后者报废弃警告。客服系统不像普通 CMS老代码跑在新版本上常常是“装好能开、一聊天就白屏”。所以部署前先php -v确认版本再用php -m检查扩展别把时间浪费在环境兼容的内耗上。2.3 消息链路的常见实现轮询与常驻进程的取舍客服系统最核心的技术难点不是存储而是“新消息怎么到达坐席端”。PHP 源码里最省事的做法是前端定时轮询浏览器每隔 3 到 5 秒请求一次未读消息接口有数据就渲染没数据就静默返回。我见过不少朵米同类的系统默认就工作在轮询模式下好处是部署简单不用维护额外的常驻进程坏处是并发上来后PHP-FPM 进程会被高频请求占满。轮询接口的正确写法应该像下面这段逻辑一样轻量只查当前用户自上次同步后的增量消息不要每次把整个会话记录拖出来。?php public function poll() { $userId (int) $_GET[user_id] ?? 0; $lastId (int) $_GET[last_message_id] ?? 0; // 只查询大于 lastId 的增量消息避免反复拉取已读内容 $messages ChatMessage::where(to_user_id, $userId) -where(id, , $lastId) -orderBy(id, asc) -limit(30) -get(); $newLastId $messages-isNotEmpty() ? $messages-last()-id : $lastId; return json_encode([ last_message_id $newLastId, items $messages, ]); }这段代码的两个关键点用主键id做增量游标而不是用created_at时间戳避免同一秒产生多条消息时漏数据限制 30 条是为了防止访客离线很久后积压大量消息导致一次性响应体过大拖垮坐席端浏览器。轮询的间隔也不能拍脑袋设设 1 秒会把服务端打满设 10 秒又让访客觉得回复迟钝我一般建议生产环境先按 4 到 5 秒跑观察 PHP-FPM 的活跃进程数再调整。如果源码带 WebSocket 长连接底层通常会依赖 GatewayWorker 这类常驻进程。它的好处是服务端可以主动把新消息推到坐席端访客发送后几乎零延迟但运维上要多管一套进程还要处理 Nginx 对 ws 协议的反向代理。小团队、会话量日均几百条的阶段轮询足够如果目标是几百个坐席同时在线再考虑把长连接进程拉起来。3. 从零部署朵米3.5客服系统源码LNMP 环境、初始化与关键参数3.1 部署前要装的 PHP 扩展与系统依赖客服系统的功能点很杂聊天传图、语音留言、Excel 导入导出、二维码生成都会依赖特定扩展。按我上面的基准环境以 Ubuntu 22.04 为例安装 PHP 7.4 和扩展的命令大致是下面这样。实际版本号以你的系统源能拉到的为准核心是把fileinfo、curl、mbstring、openssl、pdo_mysql、zip、gd这几个补齐。sudo apt update sudo apt install -y php7.4-fpm php7.4-mysql php7.4-mbstring \ php7.4-curl php7.4-gd php7.4-zip php7.4-xml php7.4-bcmath sudo systemctl enable php7.4-fpm sudo systemctl start php7.4-fpm安装完成后不要直接进下一步先检查扩展是否真的加载了php -v php -m | grep -E pdo_mysql|mbstring|curl|gd|zip|bcmathgrep那行只要有一个扩展缺失后面装系统的时候就会在文件上传、验证码、支付回调等环节莫名报错。特别注意bcmath很多客服系统的优惠券计算或金额分账逻辑依赖它没有这个扩展时页面可能正常但一到结算类接口就是 500。另外确认php-fpm与 CLI 是同一个版本我遇到过 CLI 是 7.4、FPM 是 8.0 的情况php -m看着正常跑 Web 请求却全部报错。3.2 最小部署步骤上传源码、建库、导表、配置站点环境准备就绪后按下面这套顺序操作基本可以避免“安装到一半发现目录权限不对”的反复折腾。# 1. 上传源码到站点目录 mkdir -p /var/www/duomi # 将下载的源码包解压到该目录确保 public 或 web 目录作为入口 # 2. 创建数据库并导入初始 SQL mysql -uroot -p -e CREATE DATABASE duomi DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; mysql -uroot -p duomi /var/www/duomi/database/install.sql # 3. 修改运行时目录权限PHP 进程需要写入缓存与日志 chown -R www-data:www-data /var/www/duomi chmod -R 755 /var/www/duomi chmod -R 775 /var/www/duomi/runtime顺着命令解释一下数据库字符集用utf8mb4是为了兼容访客输入的表情符号如果用默认的utf8会在消息写入时偶发 “Incorrect string value” 错误导入 SQL 前先确认文件路径有的源码把安装脚本放在sql/、install/或根目录的.sql文件里以实际目录为准runtime目录权限是最容易忽略的Nginx 运行用户如果不是www-data要把chown换成实际用户否则登录后台后缓存写不进去症状是页面能开但一保存配置就跳 500。接着配置 Nginx 站点。下面是一段通用配置按 ThinkPHP 风格的路由写成重写到index.phpserver { listen 80; server_name your-domain.com; root /var/www/duomi/public; index index.php index.html; # 静态文件直接访问动态请求交给 PHP if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.4-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ { expires 7d; access_log off; } }这里有个安全细节root直接指向public子目录而不是项目根目录。这样用户无法通过 URL 直接下载配置文件、SQL 备份或 runtime 日志是 PHP 项目部署的基本底线。如果你下载的源码入口目录不叫public请以实际目录名替换但原则不变——Web 根目录必须只暴露入口文件与静态资源。fastcgi_pass的 socket 路径要跟php-fpm配置一致不匹配时页面会报 502。3.3 影响客服体验的三个关键参数内存、上传与超时客服系统部署完能开只是第一步真正要调的是 PHP 运行参数。管理后台的会话列表、访客详情、数据报表页面往往一次要拉几百行数据memory_limit设太小会导致后台页面打开到一半变白屏坐席聊天要传截图和文件upload_max_filesize默认 2M 根本不够导出报表或执行队列任务时max_execution_time限制 30 秒又不够。下面是我一般会改的参数表在/etc/php/7.4/fpm/php.ini里按需调整后重启php-fpm生效。参数建议值启动原因memory_limit256M会话列表和统计页会在内存中组装多维数组128M 偶尔够用坐席多时建议 256Mupload_max_filesize20M客服传截图和高清图片2M 上限经常被客户投诉post_max_size24M必须大于 upload_max_filesize否则大文件上传会被截断max_execution_time60大批量导入客户资料时需要更长的执行时间CLI 任务不受此限max_input_vars3000后台表单字段较多默认 1000 在保存坐席权限时可能丢字段改完参数后用php -i | grep memory_limit确认 CLI 配置再通过?php phpinfo();确认 FPM 配置——两者不是同一个文件容易改错。另一个和体验直接相关的是消息推送进程如果源码带 GatewayWorker需要靠supervisor守护否则机器一重启客服端就收不到新消息提醒。[program:duomi-push] commandphp think gatewayworker start directory/var/www/duomi userwww-data autostarttrue autorestarttrue startsecs3 redirect_stderrtruecommand里的think是常见框架入口文件名实际以源码根目录里的入口文件名为准。配好后执行supervisorctl reread supervisorctl update supervisorctl start duomi-push再用supervisorctl status确认状态是 RUNNING。如果进程反复重启多半是站点还没配好或数据库连不上去runtime/log或项目日志目录看实际报错。4. 二开朵米3.5客服系统源码会话分配、消息实时性与安全加固提示二次开发前先确认源码的授权范围保留版权标识、不绕过授权校验是底线以下改动都在合法授权前提下讨论。4.1 二开前先读懂会话与消息的数据关系客服系统的数据表看起来多核心关系其实就几条访客表或用户表、会话表、消息表、坐席表。会话表是中间枢纽记录访客与坐席之间的归属关系、状态和最后消息时间消息表挂在会话ID下保存来往内容。后端要展示“当前待处理会话数”时根本不需要查消息表只要按会话状态聚合就行。一般会用一个类似下面的查询把未读消息数和会话列表拼起来SELECT s.id AS session_id, s.visitor_name, s.last_msg_at, COUNT(CASE WHEN m.is_read 0 AND m.is_from_agent 0 THEN 1 END) AS unread_count FROM chat_session s LEFT JOIN chat_message m ON m.session_id s.id WHERE s.agent_id ? AND s.status active GROUP BY s.id, s.visitor_name, s.last_msg_at ORDER BY s.last_msg_at DESC LIMIT 50;参数里的agent_id是当前登录坐席的 IDis_from_agent 0表示访客发送的消息这样未读数不会被坐席自己刚发出去的内容污染GROUP BY后面把查询字段写全是避免 MySQL 5.7 的ONLY_FULL_GROUP_BY模式直接报错。实际表名以源码为准但关系模型基本是这个形态。二开前先把这三张表的字段列出来比看任何设计文档都快。4.2 坐席分配规则的改造思路与代码示例默认分配规则往往是谁在线就给谁但实际业务要求可能是“按技能组”“按当前负载”“按 VIP 优先”。改分配逻辑时找一个集中的服务类方法把当前在线坐席按活跃会话数排序取最少的一个。下面的 PHP 方法展示的是“负载最低优先”的简化实现核心在于把“分配”从控制器里提出来做成独立函数方便后续替换策略?php // 传入坐席列表及各自当前活跃会话数 function assignAgent(array $agents, callable $filter null): int { // 先过滤掉不在线、置忙的坐席 $available array_filter($agents, function ($agent) use ($filter) { return $agent[online] 1 $agent[status] ! busy ($filter ? $filter($agent) : true); }); if (empty($available)) { return 0; // 返回 0 表示无可用坐席交给排队逻辑 } // 按活跃会话数升序排列会话数最少的优先 uasort($available, function ($a, $b) { return $a[active_sessions] $b[active_sessions]; }); $best reset($available); return (int) $best[id]; }这里的是 PHP 7 引入的太空船运算符返回 -1、0、1不需要再手动写 if 判断$filter闭包让你能在不改主流程的情况下接入技能组匹配。线上切换时先在日志里打印“访客进来了分配给了谁”跑两天再关掉日志而不是一上线就盲改出问题不好回退。另外分配完成后别忘记更新会话表里的agent_id和状态字段同时给坐席端推一条新会话通知。4.3 消息实时性的前端轮询改造如果默认的轮询间隔是 5 秒你想改成 3 秒或者从轮询切换到 WebSocket先在前端找定时器。前端拉取消息的逻辑通常长这样// 轮询拉取新消息示例interval 单位毫秒 const pollInterval 3000; function startPolling(visitorId) { const timer setInterval(async () { try { const resp await fetch(/api/message/poll, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({ user_id: visitorId, last_message_id: localStorage.getItem(lastMsgId) || 0 }) }); const data await resp.json(); // 更新游标保存在本地避免重复推送 localStorage.setItem(lastMsgId, data.last_message_id); if (data.items.length 0) { renderMessages(data.items); } } catch (e) { // 轮询失败不要弹窗静默等待下一轮 console.warn(poll error, e); } }, pollInterval); }代码里把last_message_id存在localStorage是为了刷新页面后能接着上次的位置拉不用重新拉全部历史catch里只打console.warn是为了避免网络抖动时反复弹错误框打断坐席操作。把轮询间隔从 5 秒改到 3 秒对服务端压力不是线性增长那么简单——改成 2 秒以下PHP-FPM 活跃连接数很容易翻倍所以改完前端务必回服务端看netstat -anp | grep :9000 | wc -l判断连接数是否在可接受范围。4.4 二开必补的输入校验与限流客服系统是直接暴露给访客的系统二开时最容易漏的是消息内容和头像地址的过滤。访客能提交nickname和content两个字段就要防 XSS能传图片 URL就要防外链钓鱼。PHP 端至少做一层htmlspecialchars过滤和内容长度校验?php $content trim($_POST[content] ?? ); $content mb_substr($content, 0, 2000, utf-8); $content htmlspecialchars($content, ENT_QUOTES, UTF-8); // 拒绝空内容或纯空白消息 if ($content || preg_match(/^\s*$/, $content)) { http_response_code(400); exit(json_encode([error empty_message])); }htmlspecialchars会把script转成纯文本坐席端渲染时不会执行脚本mb_substr限制长度是为了防止有人一次性提交几十万字刷爆数据库。限流方面同一访客 IP 每分钟最多提交 20 条消息可以直接在 Redis 里做计数用INCR加EXPIRE实现。# Redis 限流逻辑key 带分钟时间戳 redis-cli INCR chat:limit:$(date %H%M) redis-cli EXPIRE chat:limit:$(date %H%M) 60这样做的好处是把“防滥用”从 PHP 应用层挪到 Redis即使 PHP 进程重启计数也不会丢。二开时把这套限流加到消息发送入口比事后看慢查询日志高效得多。5. 朵米3.5客服系统的验证与排错压测、日志与刷新间隔验证5.1 用接口压测验证系统能扛多少并发部署完成后先拿登录接口和消息轮询接口做压测。abApacheBench是最快的验证工具命令里带上真实请求路径优先压轮询接口因为它是热点。ab -n 2000 -c 50 -H Content-Type: application/json \ -p /tmp/poll_body.json \ https://cs.example.com/api/message/poll-n 2000表示总请求数-c 50表示同时 50 个并发-p指向 POST 的 JSON 文件。跑完重点看两个指标失败的请求数必须是 0Time per request的数值乘上并发数如果明显超过 PHP 的max_execution_time说明接口里有慢查询或死循环。压测时建议只打测试环境别在生产库上压否则慢查询日志会瞬间被刷爆。5.2 按日志定位故障php-fpm、MySQL 慢查询与运行日志客服系统出问题最怕的是“页面转圈但不知道卡在哪”。按下面三条日志顺序排查能覆盖绝大多数场景。# 1. PHP-FPM 错误日志看致命错误与进程退出 tail -f /var/log/php7.4-fpm.log # 2. MySQL 慢查询日志看 SQL 是否走了全表扫描 tail -f /var/log/mysql/mysql-slow.log # 3. 应用运行日志看业务异常与推送进程状态 tail -f /var/www/duomi/runtime/log/*.logphp-fpm日志里出现WARNING: [pool www] seems busy说明进程池被打满优先看轮询间隔是否太短mysql-slow.log里同一条 SQL 反复出现就在EXPLAIN看索引应用日志里出现Connection refused检查 Redis 或 GatewayWorker 有没有在跑。5.3 一个容易忽略的验证技巧改完前端轮询后确认生效改完前端轮询时间或消息接口地址后最常遇到的困惑是“代码改了浏览器里还是老行为”。打开浏览器开发者工具的 Network 面板找到轮询请求看两次请求的时间间隔是不是新设的值如果间隔没变先清浏览器缓存或给 JS 文件加版本号参数再确认 Nginx 有没有开gzip压缩旧文件。另一个更隐蔽的问题是后端接口返回了旧数据原因是轮询游标last_message_id被存在了localStorage你换了个浏览器域名访问游标归零就会把历史消息重新拉一遍。排查时直接localStorage.removeItem(lastMsgId)后重新加载看请求参数是否正常带上新游标。下次再遇到“聊天列表不动”先沿着这条时间线查请求、日志、进程比反复改前端代码要省时间得多。本文还有配套的精品资源点击获取 朵米3.5客服系统源码私有化部署与二次开发实战
简介朵米3.5客服系统源码2023正式版是一套面向企业级客户服务场景的全功能源码适合需要搭建在线客服平台的技术人员与运营团队。系统覆盖多渠道接入、智能路由分配、工单处理及数据分析等核心模块能够帮助企业将客户请求快速分派给合适坐席并借助报表洞察服务短板。资源包共2000个文件压缩后43.85MB以JavaScript、HTML、CSS前端文件为主辅以PHP后端逻辑、MySQL数据库脚本及Shell部署脚本另有Word版搭建配置文档方便本地还原运行环境。目前已有384人学习/下载可直接学习ThinkPHP架构下的客服系统开发思路掌握宝塔面板配合Nginx、PHP7.1-7.3及MySQL5.6-5.7的环境配置方法并参考文档完成从上传解压、设置运行目录到导入数据库的完整部署流程是二次开发或系统学习客服产品设计的实用范本。1. 为什么要把朵米3.5客服系统源码拿下来自己部署客服系统的采购决策里最常见的坑是买完 SaaS 才发现改不动。坐席台要接内部工单、访客端要嵌自己的 H5、消息记录要定期归档到数仓SaaS 给的接口要么没有、要么限频、要么按调用量单独收费。朵米3.5客服系统源码这类以源码交付的方案解决的就是这个问题代码在你手里前端聊天窗、坐席工作台、管理后台的路由规则都能改消息数据落在自己的 MySQL 里权限和留存策略自己说了算。拿 2023 正式版这个版本号做生产部署不代表装完就能跑得稳它真正值钱的地方在于你可以顺着代码理解“一条访客消息怎么从网页进到坐席窗口”按自己的业务重写分配与提醒逻辑。这篇文章会按我部署过同类 PHP 客服系统的经验把架构拆解、LNMP 部署、二开入口和排错验证串起来适合有服务器操作经验、准备接手这套源码做私有化或二次开发的工程师。2. 拆开朵米3.5客服系统源码先看懂架构、模块与消息链路2.1 三端结构管理端、坐席端、访客端在源码里的分工拿到任意一套 PHP 客服系统源码先不要急着配站点。按访问角色去分目录基本都能理出三条主线管理端负责配置路由、坐席分组、欢迎语和知识库坐席端是浏览器里的工作台处理会话、转接、查看访客地理与来源访客端是嵌入业务页面的聊天窗口负责发起会话、传图片、收回复。朵米3.5这个版本延续了常见的 MVC 分层入口一般会做在 web 根目录下静态资源与业务代码分离如果下载目录里看到类似 application、public、runtime 这样的顶层文件夹就用 ThinkPHP 风格的方式去理解它application 下按模块再拆public 作为唯一对外暴露目录runtime 存缓存与日志。站在二次开发的角度这三个端在代码里对应三套不同的交互频率。管理端低频、重配置坐席端中频、依赖实时会话列表访客端高频、要能快速建立连接。所以源码里大概率会把聊天消息相关逻辑独立成接口或控制器而不是跟用户管理混在一起。看代码时先定位三件事访客提交咨询的入口方法、坐席拉取会话列表的入口方法、以及消息推送或轮询的地址。把这三个点标出来整张数据链路就通了。2.2 技术栈选型PHP、数据库、Web 服务与消息进程怎么组合以 2023 年这个时间点发布、面向私有化部署的 PHP 客服系统最常见的技术栈配置是 PHP 7.2 到 7.4、MySQL 5.7 或 MariaDB 10.3、Nginx 或 Apache再叠加 Redis 做缓存、可选 Workerman/GatewayWorker 做长连接推送。选这套组合的原因很实际PHP 7.4 对主流框架兼容性好内存占用比 PHP 8 更可控MySQL 5.7 的 JSON 类型和全文索引足够支撑会话检索Nginx 处理静态文件和反向代理的效率高不会在聊天轮询上抢 PHP-FPM 的进程。下表是我建议的基准环境低于这个版本容易在安装扩展、导入 SQL 时报错。组件推荐版本说明PHP7.4最低 7.2若源码跑在 PHP 8 上报Array and string offset access类错误通常是旧框架语法兼容问题先切回 7.4 再排查MySQL / MariaDB5.7 / 10.3数据库排序规则建议用 utf8mb4_general_ci避免访客昵称里的特殊字符报错Nginx / ApacheNginx 1.18 / Apache 2.4Nginx 需要配伪静态Apache 需要开 mod_rewriteRedis5.x / 6.x可选主要用于缓存会话状态和排队计数小并发可先不装常驻进程Workerman / GatewayWorker如果源码带 WebSocket 推送需要 CLI 模式启动并配合 supervisor 守护这里有个容易踩的坑很多人拿到源码后沿用服务器上已有的 PHP 5.6 或 PHP 8.1 去跑前者缺类型声明、后者报废弃警告。客服系统不像普通 CMS老代码跑在新版本上常常是“装好能开、一聊天就白屏”。所以部署前先php -v确认版本再用php -m检查扩展别把时间浪费在环境兼容的内耗上。2.3 消息链路的常见实现轮询与常驻进程的取舍客服系统最核心的技术难点不是存储而是“新消息怎么到达坐席端”。PHP 源码里最省事的做法是前端定时轮询浏览器每隔 3 到 5 秒请求一次未读消息接口有数据就渲染没数据就静默返回。我见过不少朵米同类的系统默认就工作在轮询模式下好处是部署简单不用维护额外的常驻进程坏处是并发上来后PHP-FPM 进程会被高频请求占满。轮询接口的正确写法应该像下面这段逻辑一样轻量只查当前用户自上次同步后的增量消息不要每次把整个会话记录拖出来。?php public function poll() { $userId (int) $_GET[user_id] ?? 0; $lastId (int) $_GET[last_message_id] ?? 0; // 只查询大于 lastId 的增量消息避免反复拉取已读内容 $messages ChatMessage::where(to_user_id, $userId) -where(id, , $lastId) -orderBy(id, asc) -limit(30) -get(); $newLastId $messages-isNotEmpty() ? $messages-last()-id : $lastId; return json_encode([ last_message_id $newLastId, items $messages, ]); }这段代码的两个关键点用主键id做增量游标而不是用created_at时间戳避免同一秒产生多条消息时漏数据限制 30 条是为了防止访客离线很久后积压大量消息导致一次性响应体过大拖垮坐席端浏览器。轮询的间隔也不能拍脑袋设设 1 秒会把服务端打满设 10 秒又让访客觉得回复迟钝我一般建议生产环境先按 4 到 5 秒跑观察 PHP-FPM 的活跃进程数再调整。如果源码带 WebSocket 长连接底层通常会依赖 GatewayWorker 这类常驻进程。它的好处是服务端可以主动把新消息推到坐席端访客发送后几乎零延迟但运维上要多管一套进程还要处理 Nginx 对 ws 协议的反向代理。小团队、会话量日均几百条的阶段轮询足够如果目标是几百个坐席同时在线再考虑把长连接进程拉起来。3. 从零部署朵米3.5客服系统源码LNMP 环境、初始化与关键参数3.1 部署前要装的 PHP 扩展与系统依赖客服系统的功能点很杂聊天传图、语音留言、Excel 导入导出、二维码生成都会依赖特定扩展。按我上面的基准环境以 Ubuntu 22.04 为例安装 PHP 7.4 和扩展的命令大致是下面这样。实际版本号以你的系统源能拉到的为准核心是把fileinfo、curl、mbstring、openssl、pdo_mysql、zip、gd这几个补齐。sudo apt update sudo apt install -y php7.4-fpm php7.4-mysql php7.4-mbstring \ php7.4-curl php7.4-gd php7.4-zip php7.4-xml php7.4-bcmath sudo systemctl enable php7.4-fpm sudo systemctl start php7.4-fpm安装完成后不要直接进下一步先检查扩展是否真的加载了php -v php -m | grep -E pdo_mysql|mbstring|curl|gd|zip|bcmathgrep那行只要有一个扩展缺失后面装系统的时候就会在文件上传、验证码、支付回调等环节莫名报错。特别注意bcmath很多客服系统的优惠券计算或金额分账逻辑依赖它没有这个扩展时页面可能正常但一到结算类接口就是 500。另外确认php-fpm与 CLI 是同一个版本我遇到过 CLI 是 7.4、FPM 是 8.0 的情况php -m看着正常跑 Web 请求却全部报错。3.2 最小部署步骤上传源码、建库、导表、配置站点环境准备就绪后按下面这套顺序操作基本可以避免“安装到一半发现目录权限不对”的反复折腾。# 1. 上传源码到站点目录 mkdir -p /var/www/duomi # 将下载的源码包解压到该目录确保 public 或 web 目录作为入口 # 2. 创建数据库并导入初始 SQL mysql -uroot -p -e CREATE DATABASE duomi DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; mysql -uroot -p duomi /var/www/duomi/database/install.sql # 3. 修改运行时目录权限PHP 进程需要写入缓存与日志 chown -R www-data:www-data /var/www/duomi chmod -R 755 /var/www/duomi chmod -R 775 /var/www/duomi/runtime顺着命令解释一下数据库字符集用utf8mb4是为了兼容访客输入的表情符号如果用默认的utf8会在消息写入时偶发 “Incorrect string value” 错误导入 SQL 前先确认文件路径有的源码把安装脚本放在sql/、install/或根目录的.sql文件里以实际目录为准runtime目录权限是最容易忽略的Nginx 运行用户如果不是www-data要把chown换成实际用户否则登录后台后缓存写不进去症状是页面能开但一保存配置就跳 500。接着配置 Nginx 站点。下面是一段通用配置按 ThinkPHP 风格的路由写成重写到index.phpserver { listen 80; server_name your-domain.com; root /var/www/duomi/public; index index.php index.html; # 静态文件直接访问动态请求交给 PHP if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.4-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ { expires 7d; access_log off; } }这里有个安全细节root直接指向public子目录而不是项目根目录。这样用户无法通过 URL 直接下载配置文件、SQL 备份或 runtime 日志是 PHP 项目部署的基本底线。如果你下载的源码入口目录不叫public请以实际目录名替换但原则不变——Web 根目录必须只暴露入口文件与静态资源。fastcgi_pass的 socket 路径要跟php-fpm配置一致不匹配时页面会报 502。3.3 影响客服体验的三个关键参数内存、上传与超时客服系统部署完能开只是第一步真正要调的是 PHP 运行参数。管理后台的会话列表、访客详情、数据报表页面往往一次要拉几百行数据memory_limit设太小会导致后台页面打开到一半变白屏坐席聊天要传截图和文件upload_max_filesize默认 2M 根本不够导出报表或执行队列任务时max_execution_time限制 30 秒又不够。下面是我一般会改的参数表在/etc/php/7.4/fpm/php.ini里按需调整后重启php-fpm生效。参数建议值启动原因memory_limit256M会话列表和统计页会在内存中组装多维数组128M 偶尔够用坐席多时建议 256Mupload_max_filesize20M客服传截图和高清图片2M 上限经常被客户投诉post_max_size24M必须大于 upload_max_filesize否则大文件上传会被截断max_execution_time60大批量导入客户资料时需要更长的执行时间CLI 任务不受此限max_input_vars3000后台表单字段较多默认 1000 在保存坐席权限时可能丢字段改完参数后用php -i | grep memory_limit确认 CLI 配置再通过?php phpinfo();确认 FPM 配置——两者不是同一个文件容易改错。另一个和体验直接相关的是消息推送进程如果源码带 GatewayWorker需要靠supervisor守护否则机器一重启客服端就收不到新消息提醒。[program:duomi-push] commandphp think gatewayworker start directory/var/www/duomi userwww-data autostarttrue autorestarttrue startsecs3 redirect_stderrtruecommand里的think是常见框架入口文件名实际以源码根目录里的入口文件名为准。配好后执行supervisorctl reread supervisorctl update supervisorctl start duomi-push再用supervisorctl status确认状态是 RUNNING。如果进程反复重启多半是站点还没配好或数据库连不上去runtime/log或项目日志目录看实际报错。4. 二开朵米3.5客服系统源码会话分配、消息实时性与安全加固提示二次开发前先确认源码的授权范围保留版权标识、不绕过授权校验是底线以下改动都在合法授权前提下讨论。4.1 二开前先读懂会话与消息的数据关系客服系统的数据表看起来多核心关系其实就几条访客表或用户表、会话表、消息表、坐席表。会话表是中间枢纽记录访客与坐席之间的归属关系、状态和最后消息时间消息表挂在会话ID下保存来往内容。后端要展示“当前待处理会话数”时根本不需要查消息表只要按会话状态聚合就行。一般会用一个类似下面的查询把未读消息数和会话列表拼起来SELECT s.id AS session_id, s.visitor_name, s.last_msg_at, COUNT(CASE WHEN m.is_read 0 AND m.is_from_agent 0 THEN 1 END) AS unread_count FROM chat_session s LEFT JOIN chat_message m ON m.session_id s.id WHERE s.agent_id ? AND s.status active GROUP BY s.id, s.visitor_name, s.last_msg_at ORDER BY s.last_msg_at DESC LIMIT 50;参数里的agent_id是当前登录坐席的 IDis_from_agent 0表示访客发送的消息这样未读数不会被坐席自己刚发出去的内容污染GROUP BY后面把查询字段写全是避免 MySQL 5.7 的ONLY_FULL_GROUP_BY模式直接报错。实际表名以源码为准但关系模型基本是这个形态。二开前先把这三张表的字段列出来比看任何设计文档都快。4.2 坐席分配规则的改造思路与代码示例默认分配规则往往是谁在线就给谁但实际业务要求可能是“按技能组”“按当前负载”“按 VIP 优先”。改分配逻辑时找一个集中的服务类方法把当前在线坐席按活跃会话数排序取最少的一个。下面的 PHP 方法展示的是“负载最低优先”的简化实现核心在于把“分配”从控制器里提出来做成独立函数方便后续替换策略?php // 传入坐席列表及各自当前活跃会话数 function assignAgent(array $agents, callable $filter null): int { // 先过滤掉不在线、置忙的坐席 $available array_filter($agents, function ($agent) use ($filter) { return $agent[online] 1 $agent[status] ! busy ($filter ? $filter($agent) : true); }); if (empty($available)) { return 0; // 返回 0 表示无可用坐席交给排队逻辑 } // 按活跃会话数升序排列会话数最少的优先 uasort($available, function ($a, $b) { return $a[active_sessions] $b[active_sessions]; }); $best reset($available); return (int) $best[id]; }这里的是 PHP 7 引入的太空船运算符返回 -1、0、1不需要再手动写 if 判断$filter闭包让你能在不改主流程的情况下接入技能组匹配。线上切换时先在日志里打印“访客进来了分配给了谁”跑两天再关掉日志而不是一上线就盲改出问题不好回退。另外分配完成后别忘记更新会话表里的agent_id和状态字段同时给坐席端推一条新会话通知。4.3 消息实时性的前端轮询改造如果默认的轮询间隔是 5 秒你想改成 3 秒或者从轮询切换到 WebSocket先在前端找定时器。前端拉取消息的逻辑通常长这样// 轮询拉取新消息示例interval 单位毫秒 const pollInterval 3000; function startPolling(visitorId) { const timer setInterval(async () { try { const resp await fetch(/api/message/poll, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({ user_id: visitorId, last_message_id: localStorage.getItem(lastMsgId) || 0 }) }); const data await resp.json(); // 更新游标保存在本地避免重复推送 localStorage.setItem(lastMsgId, data.last_message_id); if (data.items.length 0) { renderMessages(data.items); } } catch (e) { // 轮询失败不要弹窗静默等待下一轮 console.warn(poll error, e); } }, pollInterval); }代码里把last_message_id存在localStorage是为了刷新页面后能接着上次的位置拉不用重新拉全部历史catch里只打console.warn是为了避免网络抖动时反复弹错误框打断坐席操作。把轮询间隔从 5 秒改到 3 秒对服务端压力不是线性增长那么简单——改成 2 秒以下PHP-FPM 活跃连接数很容易翻倍所以改完前端务必回服务端看netstat -anp | grep :9000 | wc -l判断连接数是否在可接受范围。4.4 二开必补的输入校验与限流客服系统是直接暴露给访客的系统二开时最容易漏的是消息内容和头像地址的过滤。访客能提交nickname和content两个字段就要防 XSS能传图片 URL就要防外链钓鱼。PHP 端至少做一层htmlspecialchars过滤和内容长度校验?php $content trim($_POST[content] ?? ); $content mb_substr($content, 0, 2000, utf-8); $content htmlspecialchars($content, ENT_QUOTES, UTF-8); // 拒绝空内容或纯空白消息 if ($content || preg_match(/^\s*$/, $content)) { http_response_code(400); exit(json_encode([error empty_message])); }htmlspecialchars会把script转成纯文本坐席端渲染时不会执行脚本mb_substr限制长度是为了防止有人一次性提交几十万字刷爆数据库。限流方面同一访客 IP 每分钟最多提交 20 条消息可以直接在 Redis 里做计数用INCR加EXPIRE实现。# Redis 限流逻辑key 带分钟时间戳 redis-cli INCR chat:limit:$(date %H%M) redis-cli EXPIRE chat:limit:$(date %H%M) 60这样做的好处是把“防滥用”从 PHP 应用层挪到 Redis即使 PHP 进程重启计数也不会丢。二开时把这套限流加到消息发送入口比事后看慢查询日志高效得多。5. 朵米3.5客服系统的验证与排错压测、日志与刷新间隔验证5.1 用接口压测验证系统能扛多少并发部署完成后先拿登录接口和消息轮询接口做压测。abApacheBench是最快的验证工具命令里带上真实请求路径优先压轮询接口因为它是热点。ab -n 2000 -c 50 -H Content-Type: application/json \ -p /tmp/poll_body.json \ https://cs.example.com/api/message/poll-n 2000表示总请求数-c 50表示同时 50 个并发-p指向 POST 的 JSON 文件。跑完重点看两个指标失败的请求数必须是 0Time per request的数值乘上并发数如果明显超过 PHP 的max_execution_time说明接口里有慢查询或死循环。压测时建议只打测试环境别在生产库上压否则慢查询日志会瞬间被刷爆。5.2 按日志定位故障php-fpm、MySQL 慢查询与运行日志客服系统出问题最怕的是“页面转圈但不知道卡在哪”。按下面三条日志顺序排查能覆盖绝大多数场景。# 1. PHP-FPM 错误日志看致命错误与进程退出 tail -f /var/log/php7.4-fpm.log # 2. MySQL 慢查询日志看 SQL 是否走了全表扫描 tail -f /var/log/mysql/mysql-slow.log # 3. 应用运行日志看业务异常与推送进程状态 tail -f /var/www/duomi/runtime/log/*.logphp-fpm日志里出现WARNING: [pool www] seems busy说明进程池被打满优先看轮询间隔是否太短mysql-slow.log里同一条 SQL 反复出现就在EXPLAIN看索引应用日志里出现Connection refused检查 Redis 或 GatewayWorker 有没有在跑。5.3 一个容易忽略的验证技巧改完前端轮询后确认生效改完前端轮询时间或消息接口地址后最常遇到的困惑是“代码改了浏览器里还是老行为”。打开浏览器开发者工具的 Network 面板找到轮询请求看两次请求的时间间隔是不是新设的值如果间隔没变先清浏览器缓存或给 JS 文件加版本号参数再确认 Nginx 有没有开gzip压缩旧文件。另一个更隐蔽的问题是后端接口返回了旧数据原因是轮询游标last_message_id被存在了localStorage你换了个浏览器域名访问游标归零就会把历史消息重新拉一遍。排查时直接localStorage.removeItem(lastMsgId)后重新加载看请求参数是否正常带上新游标。下次再遇到“聊天列表不动”先沿着这条时间线查请求、日志、进程比反复改前端代码要省时间得多。本文还有配套的精品资源点击获取