Swoole做IM的核心价值在于用协程+常驻内存+连接池实现长连接全生命周期管控、消息路由稳定与资源泄漏兜底；onReceive非阻塞上下文，须禁用同步IO并用协程客户端，跨进程需Redis映射fd，task可靠性依赖幂等与双写，内存增长主因static/连接未释放，消息可靠送达需业务层补全ACK、回执与离线存储。
直接说结论：Swoole 做 IM 的核心价值不在“替代 WebSocket”，而在“用协程 + 常驻内存 + 连接池”把长连接生命周期管住、把消息路由压稳、把资源泄漏兜住——面试时若只讲“支持 WebSocket”就等于没答到点上。
为什么 Swoole 的 onReceive 不等于 HTTP 的 onRequest？
很多人一写 Swoole Server 就习惯性在 onReceive 里查数据库、调远程接口、发 Redis Pub/Sub，结果压测时 CPU 拉满、内存持续上涨。这不是代码逻辑错，是没理解事件循环的本质。
onReceive 是协程上下文，但默认不挂起；一旦里面出现阻塞操作（比如未开启协程化的 mysqli_query、file_get_contents、同步 Redis get），整个 worker 进程就卡死，后续所有 fd 的消息全被堵住。
- 必须用协程版客户端：如
Swoole\Coroutine\MySQL、Swoole\Coroutine\Redis、Swoole\Coroutine\Http\Client - 禁止在
onReceive中使用sleep()、usleep()、while(true)等轮询或休眠逻辑 - 耗时操作（如日志落盘、消息归档）应投递到
task_worker，用$server->task()非阻塞触发
如何避免多进程间 WebSocket 连接状态不同步？
单机部署多个 worker 进程后，fd 只在本 worker 内有效。用户 A 在 worker1 上线，发送消息给用户 B，但 B 实际连在 worker2 —— 如果没做跨进程路由，消息就丢了。
这不是 Swoole 的 Bug，而是设计前提：Swoole 默认不维护全局连接映射。必须自己补一层中间状态。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 用 Redis Hash 存
fd → uid映射，key 如ws:fd_map，每次onOpen时HSET，onClose时HDEL - 发消息前先查 Redis：
HGET ws:fd_map $target_uid，拿到fd和所属worker_id（需额外存） - 若目标
fd不在当前 worker，走sendMessageToWorker()或统一走 Redis Pub/Sub 中转（推荐后者，解耦更强） - 别依赖
$server->getClientList()做广播 —— 它只返回本 worker 的活跃 fd，对集群无效
task_worker 投递后，怎么确保消息不丢、不重复？
$server->task() 是内存管道通信，快但不持久。如果 task_worker 进程崩溃或机器宕机，正在管道里的任务就没了。面试常被追问“可靠性怎么保证？”
关键不是“能不能加 try/catch”，而是架构层要不要为 task 加兜底。
- 业务级幂等：消息体带唯一
msg_id，入库前先SETNX msg_id:xxx 1 EX 3600，失败则跳过 - 异步任务双写：投递
task的同时，把原始消息写入 Redis Stream 或 Kafka，task 成功后再XDEL或 commit offset - 慎用
max_task_request：设太小会导致 task_worker 频繁重启，未消费完的管道数据丢失；建议设为 0（不限制），靠监控 + OOM killer + supervisor 保活 - 不要在 task 中重连 Redis/DB：task_worker 是短生命周期，连接复用不如 worker 稳定；应复用连接池，或每次新建后立即 close
上线后内存持续增长，但没明显 leak，问题在哪？
常见于用了 static、global、闭包引用 $this、或 Redis 连接未显式 close()。Swoole 进程常驻，变量不会随请求结束自动销毁。
最隐蔽的是“缓存没设 TTL”和“连接池没回收”。
- 所有
static $cache = []必须配清理机制，比如用onWorkerStart启动定时器定期array_splice - 协程 Redis 客户端不调
close()，底层连接会一直留在连接池里，直到 worker 重启 - 用
swoole_memory_dump或memory_get_usage(true)定期采样，对比onReceive前后内存差值 - 别信“PHP 自动 GC”——协程环境 GC 触发时机更不可控，主动 unset + null 更可靠
IM 架构里最易被忽略的，不是怎么发消息，而是怎么证明“这条消息真的被对方收到了”。Swoole 提供了能力，但可靠性永远要靠业务层补全：消息 ID、服务端 ACK、客户端回执、离线存储 TTL、重试退避策略——这些才是面试官想听你拆解的细节。
