简介WeLive是一款采用PHP开发的开源在线客服系统基于WebSocket全双工通信实现请求与推送兼顾Web端和移动端内置AI自动回复、5种配色、中英文自动切换且客服坐席无数量限制适合需要自主搭建网站客服体系的PHP开发者或中小企业。资源包为5.9.0版本共287个文件含56个PHP源码文件、127张PNG界面图、21个MP3提示音以及JS/CSS脚本等整体仅1.6MB源码结构清晰便于本地部署和二次定制。已有330人学习包内附更新说明可帮助快速掌握新增的访客提示音选择、单双窗口切换、离线访客关闭、上传权限控制等功能同时可结合后台配置实现AI机器人无人值守减少人工成本。总体而言这份资源既适合想低成本自建客服系统的技术团队也适合希望学习WebSocket客服系统开发流程的PHP学习者收藏参考。1. WeLive是什么以及为什么还需要一个PHP客服系统先直接回答最实际的问题WeLive是一套基于ThinkPHP 3.2.3框架开发的免费开源PHP在线客服系统服务端语言是PHP前端和管理后台都是标准的Web页面部署到自己的服务器就能用。它解决的核心问题很明确——你的网站、App、小程序里需要挂一个能够实时聊天、自动分配、留档查询的客服窗口但不想为这件事每年支付几千上万的SaaS订阅费也不想被第三方平台掐住数据接口和聊天记录。现在市面上开源的客服系统其实不少Go写的、Java写的都有但PHP版本仍然有大量刚需。原因很实际大量中小型网站、企业官网、个人博客跑在虚拟主机或低配云服务器上环境就是LNMP或者LAMP让你为了一个客服系统去专门装Java环境或者Go环境运维成本直接翻倍。WeLive这种纯PHP方案的优势就在这儿——只要服务器能跑WordPress基本就能跑WeLive部署门槛几乎为零。这个系统适合谁来用我觉得有三类人特别对口。第一类是PHP开发者和外包接单者接到企业官网需要带客服功能的需求直接部署一套WeLive再改改皮肤就能交付省掉从零写聊天功能的重复劳动。第二类是中小企业站长不想把访客数据、聊天记录放在别人的SaaS平台上需要数据完全自控。第三类是技术爱好者想研究一个完整的PHP客服系统的代码结构学习ThinkPHP 3.2.3的项目组织方式WeLive的代码量适中适合通读。我自己实际部署过的感受是这套系统的定位很务实不玩花活。它的功能覆盖了在线客服系统最核心的几条链路访客端对话窗口、客服端工作台、会话分配机制、消息持久化存储、历史记录查询、常用回复话术。没有复杂的微服务、没有消息队列、没有容器编排就是老老实实的PHP MySQL 前端轮询/推送反而让它在低配服务器上跑得很稳。下面我把整个系统的架构逻辑、部署细节和二次开发要点一条条展开讲。2. 核心功能拆解与技术实现方案2.1 访客端到客服端的完整消息链路在线客服系统最核心的链路就是消息从访客浏览器发到客服工作台再由客服回复回访客浏览器。WeLive在这条链路上采用的是典型的PHP方案访客端通过前端Ajax轮询或者长轮询方式拉取新消息客服端同样通过轮询从服务端获取新的访客消息。这里的“轮询”不是每秒发一次请求的低效做法而是设置了合理的时间间隔结合会话心跳机制在保证消息实时性和服务器负载之间取平衡。具体的消息表设计核心是session_message这类消息表包含字段消息ID、会话ID、发送者类型访客/客服、发送者ID、消息类型文本/图片/系统消息、消息内容、创建时间。写入消息时通过事务保证会话维度的数据一致性。这里有个容易踩的坑在线客服系统的消息并发量虽然远低于社交软件但访客端和客服端同时操作同一条会话时容易出现重复插入或者会话状态错乱的问题所以写入操作必须带会话级锁或者乐观锁控制。我补充一下为什么选择轮询而不是WebSocket。WeLive基于ThinkPHP 3.2.3这个框架版本的PHP原生环境跑WebSocket需要额外维护常驻进程对于虚拟主机用户来说根本无法实现。轮询方式虽然实时性不如WebSocket但胜在兼容性极强任何能跑PHP的环境都能跑起来。实际使用中把轮询间隔设置在2到3秒访客感知不到明显延迟服务器负载也完全可控。2.2 客服工作台与多客服分配机制客服端工作台是WeLive里功能最密集的部分。登录后可以看到当前在线访客列表、进行中的会话、历史会话记录、访客详情IP、来源页面、浏览时间等。多客服分配这块系统默认实现的是轮流分配或手动抢接两种模式。轮流分配模式下系统维护一个客服队列新访客发起咨询时自动分配给队列中当前空闲且在线状态为“可接待”的客服。分配算法的实现在服务端是一个简单的取模或指针移动逻辑但要注意一个细节客服离线或者会话数已满时必须从分配池中剔除否则会出现访客消息分配给一个根本不在线的客服导致访客长时间无人回复。我在排查一些部署案例时发现很多人反馈“访客发了消息没人接”八成是分配池的状态同步逻辑没有处理好。WeLive在这一块的做法是维护客服状态表通过心跳机制更新客服的在线状态、忙碌状态和当前接待数每次分配前先筛一遍可用客服列表。2.3 消息记录、统计报表与数据管理消息记录是客服系统价值密度最高的数据资产。WeLive提供了按时间范围、按客服、按访客维度筛选历史消息的能力支持导出。这个功能对团队管理者特别有用——可以复盘客服响应时长、服务质量也能在发生纠纷时调取聊天记录作为凭证。统计报表方面系统核心关注几个指标会话总数、平均响应时长、平均会话时长、消息总数、客服接待量排行。这里的实现方式是定时脚本或每次会话关闭时更新统计表避免实时聚合大表导致性能问题。我建议在实际使用中定期把统计结果导出备份因为MySQL中的数据表如果长时间运行不清理会话表和消息表会迅速膨胀影响查询性能。3. 环境准备与部署实操全流程3.1 部署环境要求与参数选择WeLive依赖的PHP版本和ThinkPHP框架直接相关。ThinkPHP 3.2.3对PHP版本的要求是5.3以上但实测在PHP 5.6和PHP 7.0下运行最稳定PHP 7.2以上部分老代码会出现兼容性警告尤其是mysql扩展替换为mysqli或PDO的过程中可能暴露问题。数据库要求MySQL 5.5及以上建议5.7字符集统一用utf8mb4否则访客消息里如果带了emoji表情存入数据库时会报“Incorrect string value”错误。Web服务器Apache或Nginx均可Nginx需要额外配置伪静态规则把请求重写到入口文件。操作系统Linux优先Windows服务器用phpstudy或WAMP环境也能跑但生产环境还是建议Linux。下面是部署前的关键参数建议表参数项建议配置说明PHP版本5.6 / 7.0兼容性最佳避免过高版本MySQL版本5.7支持utf8mb4性能稳定Web服务器Nginx / ApacheNginx需配伪静态规则PHP扩展pdo_mysql, curl, mbstring必须开启缺一不可内存1GB以上低配512MB也能跑但会吃力轮询间隔2~3秒在config中配置3.2 从下载到上线完整安装步骤第一步是下载源码。从WeLive的官方开源仓库获取最新版本代码解压到网站根目录。这里注意一个细节不要把源码直接解压到服务器现有网站的根目录建议用独立子目录部署例如/wechat/或/kefu/避免入口文件和现有路由规则冲突。第二步是配置数据库。创建数据库并导入项目根目录下的SQL文件我使用命令行导入mysql -u root -p -e CREATE DATABASE welive DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; mysql -u root -p welive welive.sql导入完成后修改数据库配置文件。ThinkPHP 3.2.3的数据库配置在Application/Common/Conf/config.php中重点修改数据库主机、库名、用户名、密码。第三步是配置Web服务器。以Nginx为例需要在server块中添加伪静态规则location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } }Apache则需要在.htaccess中配置对应的RewriteRule。配置完成后访问安装向导地址按照提示完成安装。安装向导会检查PHP扩展是否齐全、目录是否可写绿勾全亮后即可进入系统。第四步是配置访客端接入。WeLive提供了一段JavaScript代码将代码嵌入到你的网站页面底部前端就会渲染出客服对话浮窗。这段代码的核心作用是拉取访客标识通常用cookie或localStorage生成唯一ID然后调用后端接口建立会话、获取欢迎语、建立消息轮询。3.3 访客端嵌入代码的实操写法嵌入代码的正确写法直接影响访客识别和会话建立。下面是我整理的最小可用嵌入模板script typetext/javascript (function() { var welive document.createElement(script); welive.type text/javascript; welive.async true; welive.src https://yourdomain.com/index.php?gVisitmIndexawidget; var s document.getElementsByTagName(script)[0]; s.parentNode.insertBefore(welive, s); })(); /script这里的yourdomain.com替换为你的WeLive部署域名。脚本加载后会动态创建对话浮窗并在访客点击浮窗时发起会话请求。如果发现访客打开网站后看不到浮窗最常见的原因是脚本加载的跨域问题——页面域名和WeLive部署域名不是同一个域名需要在后端配置允许跨域的头信息或者在嵌入页面通过反向代理把客服路径代理到同域下。4. 常见问题与排查技巧实录4.1 消息发不出去的排查思路我遇到过几十次“访客发消息收不到”的反馈这类问题90%集中在会话状态异常上。先看服务端日志确认请求有没有到达PHP层。没有到达就是网络层问题——检查Nginx配置中是否有对index.php的访问限制或者防火墙是否拦截了POST请求。请求到达PHP层但仍发不出去打开浏览器开发者工具看Network面板重点看接口返回的JSON状态码。一个典型的坑是ThinkPHP的URL模式配置。如果你开启了REWRITE模式但服务器伪静态没配好接口路径会全部404。解决方法是把URL_MODEL修改为兼容模式即URL_MODEL 2让URL带上index.php入口标识绕过伪静态依赖。消息已入库但客服端看不到则是轮询逻辑问题。检查客服工作台的消息轮询请求是否携带了正确的客服登录态session如果客服长时间不操作导致session过期轮询接口会返回未登录前端没有做自动跳转登录页的处理看起来就像“系统卡住了”。4.2 数据库连接数与慢查询优化WeLive部署到有一定访客量的站点后最容易暴露的问题是数据库连接数被打满。排查方法SHOW PROCESSLIST; SHOW VARIABLES LIKE max_connections;当看到大量Sleep状态的连接堆积时说明PHP进程持有的数据库连接没有及时释放。ThinkPHP 3.2.3默认的数据库连接配置里可以在config.php中开启连接池或调整连接超时参数但我实测最有效的办法是给MySQL增加wait_timeout和interactive_timeout的合理值比如设置为60秒这样空闲连接能快速回收。慢查询方面消息表的数据量到达几十万条后不带索引的查询会明显拖慢客服端打开会话记录的速度。建议在session_message表的sender_id和create_time字段上建立联合索引在session表的status和last_message_time字段上建立索引。这是低成本高收益的优化手段。4.3 多域名部署时的Cookie与Session问题我在实际项目里遇到过一个很有意思的问题同一套WeLive同时嵌入了三个不同域名的网站访客在A网站发起咨询后跳到B网站又发起一次咨询结果被系统判定为同一个访客历史消息串了。原因是访客标识依赖Cookie而Cookie是按域名隔离的但我的自定义逻辑里用了固定的客户端ID生成规则导致不同域名的Cookie被浏览器隔离后生成的访客ID重复了。正确的做法是在生成访客唯一ID时叠加一个随机因子或者直接使用uniqid()配合更多的熵源。将访客的标识与具体来路域名绑定避免跨域串号。5. 二次开发的几个方向和实用建议5.1 消息推送升级从轮询到WebSocket如果你觉得轮询方式不够极致想升级到WebSocket方案可以基于Workerman或Swoole做改造。核心思路是保留现有的消息存储逻辑在消息写入后触发一个异步事件通过WebSocket服务推送给在线客服。这样改造的工作量集中在前端消息接收层和增加一个常驻进程服务不需要动数据库结构。但我的建议是如果你的站点日活访客在几千这个量级保持轮询完全够用没必要增加运维复杂度。升级WebSocket意味着服务器需要常驻内存进程虚拟主机将不再支持部署门槛会提高一个档次。5.2 与主流CMS和电商系统的对接WeLive常见的二次开发方向是和企业已有的用户体系打通。比如在ThinkPHP框架内部增加一个用户身份映射接口当已登录用户发起咨询时自动把用户昵称、手机号、历史订单信息带入会话信息中。这个功能在电商场景下价值很大——客服一接会话就能看到来咨询的人是谁、买了什么、想退什么。对接方式可以通过在WeLive的会话创建接口中增加一个扩展字段前端嵌入时从业务系统的全局变量中读取用户信息拼装到初始化参数里后端接收后写入session_info表。5.3 数据迁移与备份策略在线客服系统的数据价值很高必须做好备份。我把备份策略拆成两个层面数据库层面每天凌晨自动导出全量SQL文件保留最近30天文件层面主要是上传的图片等附件做好异地备份。恢复时要注意数据表的自增ID如果被重置过会出现会话和消息无法对应的问题所以SQL文件的导入导出不要用--no-create-info参数必须包含完整的表结构和数据。我自己部署过多个PHP客服系统WeLive给我的整体印象是作为一套ThinkPHP 3.2.3时代的产物它的代码结构清晰、部署简单、功能足够实用特别适合中小型项目。如果你正在找一套能快速落地、方便改代码的PHP在线客服方案把WeLive拉下来跑一遍大概率不会让你失望。最后分享一个小技巧部署完成后建议在后台把默认的管理员密码改掉再关掉调试模式很多安全风险都是因为这两步偷懒导致的。本文还有配套的精品资源点击获取