必须根据业务场景选对dispatch_mode：http短连接用1（轮询），tcp/websocket长连接用2（fd取模）或5（ip哈希），udp转发禁用2、优先用1或5并调高reactor_num，协程i/o密集型用3（抢占式调度）且需启用协程。
要让Swoole服务在不同业务场景下稳定扛住并发、不丢连接、不错乱上下文，必须根据连接类型、状态需求和I/O特征选对dispatch_mode——选错不是慢一点，而是onConnect/onClose/onReceive事件错序、长连接被踢、会话丢失、UDP包堆积丢弃。
HTTP短连接API服务
这类服务无状态、每次请求独立、响应快，核心诉求是负载绝对均匀。
设置 【dispatch_mode => 1】 即可。Reactor线程按顺序将每个新连接或新数据包交给下一个Worker，像银行叫号一样轮着来。
注意：SWOOLE_BASE模式下该模式无效，因为BASE没有投递机制，Reactor收到就直接回调，不经过dispatch流程。
TCP/WebSocket长连接服务
必须保证同一个客户端的所有数据始终由同一个Worker处理，否则$server->connection_info($fd)查不到、协程上下文断裂、心跳超时误判。
方法一：用 【dispatch_mode => 2】 ——底层自动执行 $worker_id = $fd % $worker_num，只要连接不关闭，fd不变，分配结果就永远固定。
方法二：用 【dispatch_mode => 5】 ——按客户端IP哈希分配，适合NAT后多设备共用IP但需会话保持的场景（如企业内网IM），但要求Swoole ≥ 1.7.8。
方法三：手动绑定，仅限onConnect/onReceive中调用$server->bind($fd, $worker_id)，强制指定Worker。此操作不可逆，且只在Worker进程内生效，Manager或Task进程调用会失败。
UDP高并发转发服务
UDP无连接，所有数据靠Packet回调处理，默认dispatch_mode=2按IP+PORT哈希，在NAT或客户端复用端口时极易打到同一Worker，造成单核100%而其他Worker空闲。
第一步：将dispatch_mode设为1 → 均匀轮询分发每个UDP包，适合纯echo、协议解析等轻量处理。
第二步：若需按源IP做限速/鉴权等状态操作，改用dispatch_mode=5 → 但必须同步调高reactor_num至CPU核心数，否则Reactor线程成为瓶颈。
第三步：禁用dispatch_mode=2用于UDP场景——它在UDP下不仅不保粘性，反而加剧负载倾斜。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
协程I/O密集型服务
当代码大量使用Swoole\Coroutine\MySQL、Redis或sleep()等协程等待时，抢占式调度能显著提升吞吐。
启用 【dispatch_mode => 3】 → 主进程感知Worker忙闲状态，只把新连接/数据包投递给空闲Worker。
必须搭配 'enable_coroutine' => true，否则协程无法挂起，抢占失去意义。
注意：该模式下onConnect/onClose事件会被底层屏蔽，因为无法保证三个事件严格顺序到达同一Worker——如果你依赖onConnect初始化session，就不能用mode=3。
配置落地实操
在Server启动前调用set()方法写入配置：
$server = new Swoole\Server("0.0.0.0", 9501);
$server->set([
'dispatch_mode' => 3,
'worker_num' => swoole_cpu_num() * 2,
'enable_coroutine' => true,
]);
