核心三点是连接生命周期、任务分发边界和共享状态一致性；worker_num应按业务特征配置，弹幕场景设cpu核数×1.2，io/计算密集型需拆至task进程且task_worker_num设4～8，swoole\table全表扫描百万数据达30～50ms易成瓶颈。
面试官常问的 Swoole WebSocket 架构题，核心就看这三点
能不能扛住百万连接，不取决于你写了多少 $server->push()，而在于你是否理解连接生命周期、任务分发边界和共享状态一致性。面试时一问进程模型、二问心跳与断连回收、三问广播性能瓶颈，答偏任意一点，基本就出局。
worker_num 和 task_worker_num 怎么配才不翻车
很多人直接写 worker_num => swoole_cpu_num()，但没说清为什么——这不是为了“用满 CPU”，而是避免 Worker 进程间因锁竞争或共享内存争抢导致协程调度延迟。真实线上环境必须结合业务特征调：
• 消息收发密集（如弹幕）：Worker 数设为 CPU 核数 × 1.2，留出缓冲余量应对 burst 流量
• 含大量 I/O 或 CPU 密集型逻辑（如消息加解密、LLM 流式解析）：必须拆到 Task 进程，task_worker_num 至少设为 4～8，且 task_tmpdir 必须挂 SSD 路径，否则日志写入会卡死整个队列
• 千万级 QPS 场景下，task_worker_num 不宜超过 16——再多反而因 IPC 开销上升，吞吐不增反降
Swoole\Table 真的比 Redis 快？什么情况下会慢出事
快的前提是：表结构简单、key 固定、无复杂查询。一旦你用 Swoole\Table 存 fd → 房间号映射，再用 foreach ($table as $fd => $row) 全表扫描找同房间用户，那 100 万条数据遍历一次就要 30～50ms，8 个 Task 进程并行也扛不住突发弹幕洪峰。
• 容易踩的坑：
– 忘记加 $server->isEstablished($fd) 判断，对已断开的 fd 调用 push() 会触发 warning 并阻塞当前协程
– 表容量预估不足，Swoole\Table(1 是 1048576 槽位，但哈希冲突后实际能存的记录远少于该数，超限后 <code>set() 返回 false 且静默失败
– 多进程读写未加锁，比如两个 Worker 同时对同一 fd 更新 room 字段，后者覆盖前者，用户进错房间
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
HTTP 接口怎么安全触发 WebSocket 广播而不拖垮主服务
这是高频陷阱题。不能在 HTTP 请求里直接调 $server->push()，因为 Swoole 的 Server 实例只存在于 Worker 进程中，HTTP 请求跑在另一个进程/线程里，根本拿不到句柄。
• 正确路径只有两条：
– 用 swoole_http_server 和 swoole_websocket_server 合并在一个进程内（需 enable_coroutine = true），HTTP 请求通过 go 协程投递任务到全局 Task 队列
– 更稳妥的是走外部通信：HTTP 接口写 Redis List，由独立的 Task Worker 定期 rpop 并广播；此时必须加分布式锁（如 SETNX system_broadcast_lock 1 EX 30），否则多个实例同时消费同一条消息会导致重复推送
• 关键细节：Redis 的 rpop 要配合 pipeline 批量取，单次最多取 100 条，防止一次拉太多压垮 Task 进程内存
真正难的不是写出来，而是知道哪一行代码在百万连接下会成为单点瓶颈——比如忘了关 heartbeat_check_interval，空闲连接堆积后 reactor 线程轮询 fd_set 的时间复杂度会从 O(1) 变成 O(n)。
