php在线客服系统源码

去年帮朋友搭一个外贸站的线系统客服模块，他预算卡得死，客服买不起Zendesk，源码又嫌LiveChat按坐席收费太黑。线系统我扔给他一套PHP在线客服系统源码，客服丢在阿里云1核2G的源码机器上，跑了三个月，线系统日均咨询量两百来条，客服稳得很。源码这事让我重新审视了一个老话题：PHP写客服系统，线系统到底还行不行？客服

行，而且比很多人想的源码要行。市面上开源的线系统PHP客服源码不少，比如基于Workerman的客服LiveHelperChat、老牌的源码PHPLive、还有国内开发者常改的MyCrm。它们的核心逻辑并不复杂——WebSocket维持长连接，MySQL存会话和消息，Redis做在线状态缓存。一套下来，代码量撑死两万行，读懂它比读一个中型框架容易得多。

长连接才是分水岭

早期PHP客服系统用Ajax轮询，三秒一次请求，服务器CPU跟坐过山车似的。我实测过，五十个访客同时在线，轮询方案在1核机器上负载直接飙到8。换成Workerman的GatewayWorker后，同样的并发，CPU占用不到15%。差距就在连接模型上。Workerman用PHP socket加epoll，单进程能扛几千连接，配合多进程，小规模场景完全够用。Swoole也行，但扩展安装对新手不太友好，Workerman纯PHP实现，composer一拉就能跑，这点很关键。

源码里最值得看的是消息路由部分。访客发一条消息，系统得判断：当前有没有客服在线？该分配给谁？分配规则是轮询还是按负载？消息要不要存离线？这些逻辑全在Event.php的onMessage回调里。写得好的源码，这块会拆成独立的Router类，写得烂的，两百行if-else堆在一起。我见过一套国内某CMS附带的客服模块，分配逻辑硬编码了“按客服ID从小到大”，结果1号客服永远在接消息，3号客服闲得刷手机。这种细节，不读源码根本发现不了。

数据库设计里的坑

消息表别用自增ID做主键。客服系统消息量大，自增ID在分库分表时是灾难。用雪花算法或者UUID都行，虽然存储空间大点，但扩展性好。另外，会话表要加复合索引——(visitor_id, created_at)和(agent_id, status)这两个查询最频繁。我见过一套源码，会话表没建任何索引，一万条数据时查询就开始卡，加到十万条直接超时。这种问题，测试环境数据少根本暴露不出来。

还有个容易忽略的点：消息已读状态。访客发了消息，客服没看，这条消息的状态字段怎么设计？用tinyint存0/1？那客服多端登录怎么办？A端读了，B端还是未读？正确做法是单独建一张message_read表，记录(user_id, message_id, read_at)。这套逻辑在LiveHelperChat源码里有现成实现，直接抄就行，别自己造轮子。

安全不是加个验证码就完事

PHP客服系统最常见的漏洞是XSS。访客输入的消息直接存库，客服后台渲染时没转义，一段<script>就能偷走客服的session。修复方法简单——输出时用htmlspecialchars，输入时用strip_tags过滤。但很多源码只在访客端做了过滤，客服回复的消息没过滤，结果客服自己中招。这种不对称的防护，说明开发者压根没想清楚数据流向。

另一个是WebSocket鉴权。Workerman的onConnect回调里如果不校验token，任何人连上就能冒充客服发消息。正确做法是在连接时传token，服务端查Redis验证身份，失败直接断开。这套流程在GatewayWorker的文档里有示例，但不少源码为了“简化部署”，把鉴权砍了。省事是省事，上线就是裸奔。

改还是重写

拿到一套源码，先别急着改。跑起来，用ab压测一下，看QPS和内存增长曲线。如果五百并发下内存泄漏超过50MB，直接放弃，重写比修快。如果基础架构没问题，那就盯着三个地方改：消息路由策略、数据库索引、前端渲染性能。这三块优化完，一套开源客服系统撑个日均五千咨询量，问题不大。

朋友那套系统后来加了个功能——客服离线时自动回复带表单链接，访客填完直接生成工单。代码不到一百行，但转化率提了12%。你看，PHP客服源码的价值不在功能多全，而在改起来快。这点，Java和Node的方案真比不了。