四端互通IM源码部署：环境配置、WebSocket联调与排错-平芜编程栈

简介：面向具备一定开发基础、希望自建即时通讯系统的技术团队与独立开发者，这份资料围绕视酷酷信 IM 源码展开，重点对应四端互通、二次开发与私有化部署三类需求。压缩包共 9 个文件，以 6 个 txt 解析笔记为主，另含 1 个 html 预览页、1 份 doc 深度文档和 1 张 jpg 示意图，整体仅 99KB，属于轻量级文档型资料包，便于快速通读与检索，目前已有 501 人学习。内容覆盖安卓、苹果、PC 与 Web 四端架构，涉及 Java、OC、C#、Vue 多语言客户端，以及 tio 通信技术、MongoDB 存储和 CentOS 7.6 部署环境；对单机万人并发、集群扩展、强拖与双空间切换等实现也有专门解析。读者可据此梳理源码结构、评估二开加商城等改造路径，并对照部署清单完成环境准备与安全自查，适合作为自建 IM 项目的前期调研与开发参考。

1. 一套源码四种跑法：先搞清楚这份即时通讯源码对环境的挑剔点

拿到一份标着「四端互通」的即时通讯源码，最常见的翻车方式不是代码跑不起来，而是把它当成普通建站程序：解压到已经跑着两个站点的 PHP 环境里，改个数据库密码，打开首页，登录页出来了，然后消息永远在转圈。这套 IM 源码不是单一站点，它至少包含 HTTP 接口服务、一个常驻的通讯进程、后台管理端，以及 H5、PC、小程序、APP 四套前端工程，任何一处运行时版本对不上都会在联调阶段集中爆发。适合动手能力强、能读配置文件、有独立服务器的人；只想点几下鼠标就上线的不适合。下面按我实际装过一遍的顺序，从环境盘点写到验证收尾。

2. 开装前的环境盘点：PHP、MySQL、Redis 和 Node 各锁哪个版本

源码包解压后第一件事不是装，是看目录。一份能跑的四端 IM 源码，目录结构基本长这样：api（HTTP 接口）、process（常驻通讯进程）、admin（后台）、h5、pc、uniapp（小程序与 APP 共用一套）、sql（初始化脚本）、doc（部署说明）。先翻doc里的环境说明和composer.json、package.json里锁的版本，那份文件比任何教程都权威，我下面给的是一套我反复用过的、容错比较高的组合。

2.1 四个端分别跑在什么运行时上

很多人以为四端就是四个前端，其实真正吃资源、最容易版本踩坑的是后端那两个：接口服务和常驻进程。它们往往共用同一份 PHP，但常驻进程对 Swoole 扩展版本更敏感。我一般先按这张表把版本定下来，再动手装。

模块	运行时	关键依赖	默认端口
HTTP 接口服务	PHP 8.0 / 8.1	pdo_mysql、redis、mbstring、bcmath、fileinfo、openssl	走 80/443
常驻通讯进程	PHP + Swoole 4.8+ 或 Workerman 4.x	swoole（须与 PHP 版本匹配）	9501（对外 WS）
后台管理端	PHP 同源或独立 Node 构建	同上	复用主域名子目录
H5 / PC 前端	Node 16 或 18 构建，产物是静态文件	构建期依赖 node-sass / vite	Nginx 托管
小程序 / APP	各自开发者工具，产物为包	HTTPS 域名、合法 socket 域名	不占服务器端口
数据库 / 缓存	MySQL 5.7 或 8.0、Redis 6+	utf8mb4、requirepass	3306 / 6379

版本取舍上有两个我踩过的点。第一，PHP 别上 8.2，一些老框架的动态属性写法在 8.2 会刷一屏 deprecated，虽然不致命，但日志会被淹掉，真出问题时你找不到重点。第二，Swoole 必须和 PHP 主版本对齐，PHP 8.0 配 Swoole 4.8.x 比较稳，PHP 8.1 建议 5.0 以上；pecl install swoole装出来的版本不一定对得上，我一般指定版本号装。

2.2 用几条命令把扩展和端口核一遍

装扩展之前先确认现在到底有什么，别等安装脚本跑到一半报Call to undefined function再回头找。下面这几条我每次开新机器都会顺手跑一遍。

# 确认 PHP 主版本与已装扩展，缺哪个补哪个 php -v php -m | grep -E 'pdo_mysql|redis|mbstring|bcmath|fileinfo|openssl|swoole' # 单独确认 Swoole 的版本与编译参数（重点看是否开启了 openssl、http2） php --ri swoole | head -20 # 确认 Node 版本，前端构建对主版本敏感 node -v && npm -v # 确认 MySQL、Redis 是否已在跑，以及缓存是否设了密码 mysql --version redis-cli -a '你的密码' ping # 返回 PONG 才算通

php --ri swoole这条特别值得看，除了版本号还会打出编译时的--enable-openssl、--enable-http2之类的开关。如果常驻进程配置里用了wss://而你编译时没开 openssl，进程启动会直接报握手失败，日志里只给一行错，很容易误判成证书问题。

端口方面，装之前先用ss -lntp看一眼 9501、9502 有没有被别的进程占。我见过一次是旧版本进程没杀干净，新进程bind失败但被 systemd 反复拉起，表面看是"消息发不出去"，实际上是两个进程在抢一个端口。

2.3 目录规划与运行用户

不建议和已有的站点混在一个目录、一个 PHP-FPM 池里。IM 的常驻进程是长连接，跑起来之后会长期占内存，和普通站点的 FPM 混在一起，一旦进程内存涨上去，最先被 OOM Killer 干掉的是你的其他站点。我一般这样分：

# 统一放在一个业务目录下，按模块分开，便于单独升级 mkdir -p /www/wwwroot/im/{api,process,admin,h5,pc,uniapp,logs} chown -R www:www /www/wwwroot/im chmod -R 755 /www/wwwroot/im chmod -R 775 /www/wwwroot/im/api/runtime /www/wwwroot/im/logs

runtime、logs、上传目录这三个必须是可写的，其余保持只读权限。运行用户统一用www（或nginx，跟着你的 Web 服务走），常驻进程也用同一个用户启动，否则进程写日志、写上传文件时会因为属主不一致失败，报错还特别隐晦——表现是"图片上传成功但打不开"。

3. 后端落地：建库、改配置、把常驻进程托管起来

后端是整个 IM 的地基，装错一步后面四端全白搭。这一章按我实际的执行顺序走：先库，再配置，再进程，最后反代。

3.1 建库建用户与导入 SQL 的顺序

不要用 root 连业务库，这是基本习惯。建库时字符集统一utf8mb4，IM 里昵称、群名、表情符号都很容易出四字节字符，用utf8迟早会遇到插入报错。

-- 建库：字符集跟排序规则要跟 MySQL 版本匹配 -- MySQL 8.0 用 utf8mb4_0900_ai_ci，5.7 只能用 utf8mb4_general_ci CREATE DATABASE `im_core` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 建专用账号，只授权这个库，别给全局权限 CREATE USER 'im_user'@'127.0.0.1' IDENTIFIED BY '换成强密码'; GRANT ALL PRIVILEGES ON `im_core`.* TO 'im_user'@'127.0.0.1'; FLUSH PRIVILEGES;

排序规则这一项是真会翻车的：你把 8.0 上导出的建库语句搬到 5.7，utf8mb4_0900_ai_ci直接报未知排序规则，整个导入中断。反过来，5.7 的库恢复到 8.0 一般没问题。

导入顺序也有讲究。源码包sql目录里通常是structure.sql（表结构）加data.sql（初始数据，比如后台管理员、默认配置项），先结构后数据。导入前建议临时放宽sql_mode，老代码里GROUP BY写得随意、时间字段默认0000-00-00的情况不少：

# 导入时临时去掉严格模式，导完再改回来 mysql -u im_user -p im_core -e "SET SESSION sql_mode='NO_ENGINE_SUBSTITUTION';" mysql -u im_user -p im_core < sql/structure.sql mysql -u im_user -p im_core < sql/data.sql # 核对表数量和初始管理员是否进来了 mysql -u im_user -p im_core -e "SHOW TABLES;" | wc -l mysql -u im_user -p im_core -e "SELECT id,username FROM im_admin LIMIT 3;"

表名以你包里的实际结构为准，重点是最后两步核对：表数量对不上说明导入中途断了，管理员表为空说明data.sql没进去或者表前缀不一致。

3.2 配置文件里必须逐项确认的七个地方

配置文件通常在api/.env或api/config/database.php这类位置。不要只改数据库那三行就往下走，下面这几项漏一个就要多排查两小时。

; 数据库：host 用 127.0.0.1 而不是 localhost，避免走 socket 找不到 DB_HOST = 127.0.0.1 DB_PORT = 3306 DB_NAME = im_core DB_USER = im_user DB_PASS = 换成强密码 DB_CHARSET = utf8mb4 ; 缓存：有密码就必须填，protected-mode 开着时空密码连不上 REDIS_HOST = 127.0.0.1 REDIS_PORT = 6379 REDIS_PASS = 换成强密码 REDIS_DB = 0 ; 应用层：这三项决定前端能不能连上 APP_URL = https://im.example.com APP_KEY = 安装脚本生成的随机串，别手填 WS_URL = wss://im.example.com/ws ; 上传与时间 UPLOAD_PATH = /www/wwwroot/im/api/public/uploads DEFAULT_TIMEZONE = Asia/Shanghai

WS_URL是最容易写错的一项。它必须是外部可访问的地址，而不是进程监听的127.0.0.1:9501。前端拿这个值去建连，如果填成内网地址，PC 端本机测试能通、手机一打开就转圈。另外APP_KEY用于加密和签名，多端登录态校验依赖它，改一次所有已登录用户都会掉线——这不是 bug，是设计如此。

时区也要一起定死：PHP 的date.timezone、MySQL 的time_zone、常驻进程里写死的时区，三者必须一致。不一致的表现很有迷惑性——H5 端发的消息时间正常，APP 端收到的时间差 8 小时，然后你开始怀疑是不是跨端编码问题。

3.3 常驻进程用 systemd 托管，别用 nohup

通讯进程挂了不会有人告诉你，用户只会说"消息发不出去"。nohup php start.php start -d &这种写法在测试机上凑合，正式环境必须交给 systemd，至少能保证进程退出后自动拉起、日志有地方落。

# /etc/systemd/system/im-process.service [Unit] Description=IM Websocket Process After=network.target mysql.service redis.service [Service] Type=simple User=www Group=www WorkingDirectory=/www/wwwroot/im/process # -d 是守护模式，交给 systemd 托管时要去掉，让它前台跑 ExecStart=/usr/bin/php start.php start ExecReload=/usr/bin/php start.php reload Restart=always RestartSec=5 # 限制单进程内存，防止泄漏把整机拖垮 MemoryMax=1G StandardOutput=append:/www/wwwroot/im/logs/process.log StandardError=append:/www/wwwroot/im/logs/process.err [Install] WantedBy=multi-user.target

几个参数的取舍说一下。Restart=always配RestartSec=5，是为了避免进程启动即崩时疯狂重启把日志刷爆；如果日志里出现每分钟几十次重启，先去看process.err，八成是 Swoole 扩展没装或端口被占。ExecStart里的start后面不能带-d，守护模式和 systemd 的Type=simple冲突，表现为 systemd 认为进程已退出然后不断重拉。MemoryMax是后悔药，长连接进程跑久了内存缓慢上涨很常见，设个硬上限，超了自动重启总比整机卡死强。

# 启动并设开机自启，然后立刻看状态和日志 systemctl daemon-reload systemctl enable --now im-process systemctl status im-process --no-pager tail -f /www/wwwroot/im/logs/process.log

状态里Active: active (running)只是第一步，真正要看的是日志里有没有打出监听端口那一行。没有的话，ss -lntp | grep 9501确认端口在听。

3.4 Nginx 反代与 WebSocket 升级的写法

四端里 H5、PC、小程序、APP 都连同一个域名，WebSocket 走路径区分最省事。这里有两处必须写对，否则握手永远失败。

# WebSocket 升级：Connection 头要根据客户端请求动态取值 map $http_upgrade $connection_upgrade { default upgrade; '' close; } server { listen 443 ssl http2; server_name im.example.com; # H5 与 PC 端静态产物 root /www/wwwroot/im/h5/dist; index index.html; # 前端路由，刷新 404 的固定解法 location / { try_files $uri $uri/ /index.html; } # HTTP 接口 location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # WebSocket：这三行少一行都不行 location /ws { proxy_pass http://127.0.0.1:9501; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_set_header X-Real-IP $remote_addr; # 长连接不能按默认 60s 断，否则用户挂机一会就掉线 proxy_read_timeout 600s; proxy_send_timeout 600s; } }

proxy_http_version 1.1是最常漏的一行。Nginx 对上游默认用 HTTP/1.0，而 WebSocket 升级依赖 1.1 的Upgrade头，漏了就是 400 或者握手后立刻断开。proxy_read_timeout默认 60 秒，IM 场景下用户切个窗口回来就掉线，你能收到一堆"消息延迟"的反馈。600 秒不是绝对值，配合前端心跳一起调，心跳间隔一般 30 到 50 秒，超时设到心跳的十倍左右比较稳。

4. 四端前端编译：改对一个环境变量省掉半天联调

前端四套工程看着多，核心其实就一件事：把接口地址和 WS 地址改对，然后各端按自己的规则打包。搞错这一层，你会看到"后台能登录、H5 登录失败"这种割裂现象。

4.1 接口前缀与构建环境变量

前端工程一般会有.env.development和.env.production两个文件。生产构建只读后者，很多人改错了文件，npm run build出来还是旧地址，然后开始怀疑缓存。

// h5/.env.production —— 变量名以你工程里的 vite/webpack 定义为准 VITE_APP_TITLE = IM // 接口根地址：带不带 /api 取决于 Nginx 的 location 配置 VITE_API_BASE = https://im.example.com/api // WS 地址：必须是 wss，走 https 的站点混用 ws 会被浏览器直接拦掉 VITE_WS_URL = wss://im.example.com/ws // 上传地址单独配，很多工程和后端接口不在同一前缀下 VITE_UPLOAD_URL = https://im.example.com/api/upload

wss这一项没有商量余地。https 页面里连ws://会被浏览器作为混合内容拦截，控制台只给一行警告，表现是 H5 端所有实时功能失效但接口请求都正常。另外VITE_API_BASE结尾带不带斜杠要和代码里的拼法对齐，带斜杠再加路径会出现//api双斜杠，部分网关会直接 404。

# 生产构建，注意 Node 版本 cd /www/wwwroot/im/h5 npm config set registry https://registry.npmmirror.com npm ci # 有 lock 文件就用 ci，比 install 稳定 npm run build # 产物默认在 dist，确认里面有 index.html 再交给 Nginx ls -lh dist/index.html

npm ci和npm install的区别在多人协作时很明显：ci严格按 lock 文件装，不会悄悄升级次版本。老工程里如果有node-sass，在 Node 18 上编译大概率失败，报Node Sass does not yet support your current environment，这种时候要么降到 Node 16，要么把依赖换成sass（dart-sass），后者是更彻底的做法。

4.2 H5 端在 Safari 上的四个已知坑

四端里最能出玄学问题的就是 iOS Safari。同样的代码安卓 Chrome 一切正常，到 Safari 就掉线、白屏、听不到语音。这几个坑我基本每次都要处理一遍。

第一个是页面切后台后连接被挂起。iOS Safari 在页面进入后台一段时间后会冻结 JS 和网络活动，WebSocket 名义上还开着但实际收不到数据，用户切回来看到的是"消息不更新"。解法是监听可见性变化，回来时主动探活、必要时重建连接：

// 处理 iOS Safari 切后台导致的连接假死 let ws = null; let heartbeatTimer = null; function connect() { ws = new WebSocket(import.meta.env.VITE_WS_URL); ws.onopen = () => { // 上线后立刻发一次心跳，避免后台冻结期间的计时错乱 startHeartbeat(); }; ws.onclose = () => { clearInterval(heartbeatTimer); // 退避重连，避免服务端抖动时被瞬间打满 setTimeout(connect, 3000); }; } function startHeartbeat() { clearInterval(heartbeatTimer); heartbeatTimer = setInterval(() => { // readyState 为 1 才发，否则说明连接已经废了 if (ws && ws.readyState === WebSocket.OPEN) { ws.send(JSON.stringify({ type: 'ping', ts: Date.now() })); } }, 30000); } // 关键：从后台回到前台时重新计时并探活 document.addEventListener('visibilitychange', () => { if (document.visibilityState === 'visible') { if (!ws || ws.readyState !== WebSocket.OPEN) { connect(); } else { ws.send(JSON.stringify({ type: 'ping', ts: Date.now() })); startHeartbeat(); } } });

第二个是登录态丢失。Safari 的智能防跟踪策略对跨站 Cookie 卡得很死，如果你的接口域名和 H5 域名不是同一个二级域，SameSite默认策略下 Cookie 根本带不过去，表现是登录接口返回成功、下一个请求又提示未登录。我的做法是登录态不用 Cookie，改由前端存 token、每个请求塞进请求头。这种做法在小程序端本来也是必需的，四端统一反而省事。

第三个是隐私模式下localStorage写入抛异常。Safari 无痕窗口的存储配额可能是 0，setItem直接抛QuotaExceededError，如果这段没包 try/catch，整个初始化流程就断了，页面白屏。稳妥做法是封一层带内存兜底的存储：

// 带内存兜底的存储封装，Safari 无痕模式写入会抛异常 const memoryStore = {}; const safeStorage = { set(key, value) { try { localStorage.setItem(key, value); } catch (e) { // 配额为 0 或隐私模式，退化为内存存储，至少本次会话可用 memoryStore[key] = value; } }, get(key) { try { return localStorage.getItem(key) ?? memoryStore[key] ?? null; } catch (e) { return memoryStore[key] ?? null; } } };

第四个是语音消息首条没声音。iOS 规定音频播放必须由用户手势触发，页面加载后自动播放会被静默拦截。处理方式是在用户第一次点击时播放一段静音音频"解锁"，之后再用Audio对象播放就正常了。这个不算源码 bug，是平台规则，但没有它语音功能在 iOS 上就是不可用状态。

4.3 小程序与 APP 打包容易漏的配置

小程序端最硬的门槛是域名。请求域名和 socket 域名都要在后台白名单里，且必须是 HTTPS/WSS 加已备案域名，本地调试可以临时勾选"不校验合法域名"，但真机预览肯定过不去。这一步卡住的人最多，而且报错信息只说"不在以下 request 合法域名列表中"，不会告诉你去哪配。

APP 端打包要注意包名和证书。manifest.json里的应用标识一旦定下来就别再改，改了之后覆盖安装会变成两个应用并存，用户数据不互通。Android 用自有证书签名时，证书文件丢了就再也无法覆盖升级，只能让用户卸载重装——这是我最强调备份的一个文件。

// uniapp/manifest.json 关键片段 { "name": "IM", "appid": "__UNI__XXXXXXX", "versionName": "1.0.0", "versionCode": 100, "app-plus": { "distribute": { "android": { "packagename": "com.example.im", "permissions": ["<uses-permission android:name=\"android.permission.CAMERA\"/>"] } } } }

versionCode每次发版必须递增，否则应用市场会拒收，本地覆盖安装也可能不生效。权限列表按需加，相机、录音、存储这三个是 IM 的刚需，少一个就是"点语音按钮没反应"。

5. 装完跑不通的排查：五个我真实翻过车的点

下面五条都是装完之后最常见的状态，每条按我当时的排查顺序写，现象、原因、解决三件事对齐看。

5.1 后台能登录，消息一直转圈

现象：管理后台正常登录、用户列表能加载，H5 端登录也提示成功，但发消息永远显示发送中。

原因：九成是 WebSocket 没通。要么WS_URL写成了内网地址，要么 Nginx 少了proxy_http_version 1.1，要么常驻进程压根没起来。

解决：按顺序验三段。先在服务器上ss -lntp | grep 9501确认进程在听；再curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" https://im.example.com/ws看返回是不是 101；最后打开浏览器控制台看 WS 那一栏的报错，Unexpected response code: 400指向 Nginx 配置，WebSocket is closed before the connection is established指向进程或上游地址。

5.2 常驻进程启动几秒就退出

现象：systemctl status显示activating和failed交替，Restart计数一直在涨。

原因：集中在三种。Swoole 扩展没装或版本与 PHP 不匹配；监听端口被上次没杀干净的进程占着；ExecStart里带了-d和Type=simple打架。

解决：先journalctl -u im-process -n 50 --no-pager看最后几十行，找不到原因就手动前台跑一次cd /www/wwwroot/im/process && php start.php start，错误会直接打在终端上。端口冲突用lsof -i:9501找到 PID 再处理，别直接kill -9，先正常停再启。

5.3 图片能上传但打不开

现象：接口返回上传成功，返回的 URL 粘到浏览器里 404 或者 403。

原因：上传目录的属主或权限不对，或者 URL 前缀和 Nginx 的静态目录映射对不上。还有一种容易被忽略：上传目录在public之外，Nginx 根本没法直接访问。

解决：ls -l看上传目录属主是不是和进程用户一致，不一致就chown -R www:www；然后确认 Nginx 里对该目录有location且没被前面的try_files规则截胡。上传大文件还要同步调client_max_body_size和 PHP 的upload_max_filesize，两边有一个小就会 413。

5.4 换域名之后 H5 白屏

现象：从测试域名切到正式域名，页面一片空白，控制台有跨域报错或者资源 404。

原因：构建产物里写死了旧域名，缓存里的旧index.html引用了旧路径的 JS，或者 Nginx 的root还指向老目录。

解决：改.env.production之后一定要重新npm run build，只改源码不重新打包是不会生效的；然后确认dist目录整体替换而不是覆盖部分文件，带 hash 的老文件残留很容易让人误判。最后清浏览器强缓存（无痕窗口验一遍最省事）。

5.5 消息时间差 8 小时、列表顺序乱

现象：同一台手机，H5 里收到的时间是对的，APP 里差 8 小时；或者消息列表偶尔出现后发先至。

原因：时区三处不一致是时间差的根因。顺序乱通常是客户端按本地时间排序而不是按服务端下发的自增 ID 或序列号排序。

解决：统一php.ini的date.timezone = Asia/Shanghai、MySQL 的time_zone、常驻进程里的时区设置；排序一律用服务端下发的消息序号，不要用客户端Date.now()。多端同时在线时客户端时钟差异可以到几秒，用它排序必乱。

6. 怎么验证真的跑通：一条消息穿过三端再回来看时间戳

装完之后我不看页面能不能打开，那个说明不了任何问题。我的验收方式是让一条消息从 H5 发出去，在 APP 上收到，再从 APP 回一条，最后在后台的消息记录里对时间戳。这条链路走通，说明接口、常驻进程、Nginx 升级、四端鉴权、数据库写入全部正常。

具体做法分三步。第一步在浏览器无痕窗口和真机 APP 上同时登录两个不同账号，注意用无痕是因为 H5 的localStorage里的旧 token 会让你误以为登录成功了实际还在用老会话。第二步 H5 发一条文本、一条图片、一条 5 秒以上的语音，APP 侧逐条确认；语音这一项专门针对 iOS 的自动播放限制，能播出来才说明解锁逻辑生效了。第三步把 H5 切到后台放置三分钟再切回来，然后再发一条——这一步专门验 Safari 的连接假死处理，如果切回来第一条消息卡住几秒才发出，说明重连逻辑在起作用，如果直接发不出去，说明visibilitychange那段没生效或者被别的监听覆盖了。

时间戳核对我用一个固定的三条 SQL，比翻页面快得多，也更容易发现问题：

-- 一条消息的三个时间：客户端发出、服务端接收、对端确认 -- 正常情况三者间隔在毫秒级，超过 5 秒说明链路某一段在阻塞 SELECT id, from_uid, to_uid, send_time, -- 客户端上报的发送时间 created_at, -- 服务端落库时间 TIMESTAMPDIFF(SECOND, send_time, created_at) AS lag_sec FROM im_message ORDER BY id DESC LIMIT 20;

lag_sec大面积是负数，基本可以确定服务端时间比客户端慢，回头看 5.5 那条时区问题；大面积超过 5 秒，去看常驻进程日志里有没有阻塞操作，比如在消息回调里同步查了数据库或者调了外部接口。我在一个项目里就是因为消息回调里同步发了一条短信通知，把整个进程堵住，表现是"人一多消息就延迟"。

还有一项我必查：把服务重启一次，systemctl restart im-process，然后立刻用两端互发消息。这一步验的是进程重启后客户端的重连能力。很多前端只在onclose里重连，但收到服务端主动断开时不会触发，结果是服务端重启完，老连接的客户端还在那儿干等。

从那以后我每次部署完这套东西，都强制走一遍「H5 发→APP 收→切后台三分钟→再发→重启进程→再发」这条固定动作，二十来分钟，比事后被用户追着问"为什么消息发不出去"省心得多。这套源码本身带着部署教程，把上面这些环境参数和配置文件对着自己机器填一遍，四端是能同时跑起来的，剩下的二次开发再按需往下做就行。希望帮到你。

本文还有配套的精品资源，点击获取