默认通信模式为task_ipc_mode=1（unix socket），数据8kb写临时文件，仅限本机、不支持定向投递、高并发下易现timeout；mode=2用sysvmsg，支持定向投递但需配置message_queue_key并监控队列容量；mode=3为争抢模式，定向失效，适用于无状态任务，但调试和监控成本高。
task_ipc_mode=1 用 Unix Socket，但要注意数据大小限制
这是默认通信模式，worker 和 task 进程之间通过 Unix Socket 管道传递数据。它简单、轻量，适合中小规模任务分发。
关键限制在于：数据 小于 8KB 时直接走内存管道；一旦超过，Swoole 会自动写入临时文件，onTask 回调里再读取——这会带来额外 I/O 开销，且临时文件若因进程异常退出未被清理，可能残留。
- 不支持跨机器部署（仅限本机进程间）
- 无法指定投递目标 task 进程（即不能用
$serv->task($data, $task_worker_id)的第二个参数） - 高并发下大量小包可能引发 socket 缓冲区竞争，表现为偶尔的
task timeout或延迟毛刺
task_ipc_mode=2 用 sysvmsg 消息队列，支持定向投递
切换到系统 V 消息队列后，通信更稳定，尤其适合中高负载场景。它保留了定向能力：$serv->task($data, $task_worker_id) 中的 $task_worker_id 生效，你可以把任务精准塞给某个特定 task 进程（比如按业务类型绑定、状态隔离）。
需要额外配置 message_queue_key，例如 0x72000100，确保多个 Swoole 实例不会共用同一队列导致混乱。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 必须保证系统开启了 sysvmsg 支持（
ipcs -q可查） - 消息队列有容量上限（默认一般 16MB），超限时
task调用会阻塞或失败，需监控ipcs -q输出的used-bytes -
task_max_request设得过大 + 长时间运行，可能导致队列 key 被重复占用（重启不自动释放），需手动ipcrm -Q <key></key>
task_ipc_mode=3 是争抢模式，定向投递完全失效
本质仍是 sysvmsg，但底层启用了“争抢”逻辑：所有 task 进程都从同一个队列里 msgrcv，谁抢到算谁的。这意味着你传了 $task_worker_id 参数也没用，Swoole 会直接忽略。
适用场景很明确：任务完全无状态、可任意调度，且你希望最大化吞吐、避免单个 task 进程成为瓶颈。比如日志归档、简单数据清洗这类“扔进去就不管谁处理”的任务。
-
$serv->taskwait()在此模式下无法指定目标，只能等待任意一个 task 完成并返回结果 - 无法做负载感知投递（比如只往空闲 task 投），全靠系统调度
- 如果 task 进程数少于并发任务数，队列积压会变明显，
ipcs -q显示queues的qnum持续上涨就是信号
选哪个？看你的 task 是否需要“可控性”
绝大多数业务一开始用 task_ipc_mode=1 就够了；一旦发现任务延迟抖动大、或要按 worker_id/业务维度做路由，就切到 =2；只有当你确认所有 task 完全等价、且追求极致吞吐不 care 执行者身份时，才上 =3。别为了“听起来高级”而提前切换——mode 3 的调试成本和监控盲区比想象中高得多，尤其是队列满、key 冲突、残留消息这些事，线上出问题时很难一眼定位。
