协程单核性能强但无法利用多核，多进程可并行占满多核；二者是分工关系：协程处理高并发i/o，多进程承担cpu密集任务，混合使用（如worker协程+taskworker进程）为最佳实践。
协程在单核上压倒性胜出，但多进程才能真正吃满多核 CPU —— 两者不是替代关系，而是分工关系。
协程并发快，但只跑在一个 CPU 核上
协程本质是单线程调度：所有 go() 启动的协程共享同一个 OS 线程，由 Swoole 协程调度器在用户态切换。这意味着：
- 上下文切换开销极低（微秒级），
file_get_contents、Redis::get、MySQLi::query等 I/O 操作会自动挂起当前协程，让出 CPU 给其他协程 - 无法并行利用多个物理 CPU 核 —— 即使你启了 10 万个协程，
top看到的始终是 100% 单核占用 - 适合高 I/O、低计算场景（如 API 聚合、HTTP 请求编排、Redis 批量读写），实测 5000 次百度请求在单核 1G 机器上耗时约
1.8s，QPS 达2700+
多进程能跑满多核，但创建/通信成本高
每个 Swoole\Process 是独立的 OS 进程，拥有自己的内存空间和 PID：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 天然可并行 —— 4 核机器上启动 4 个 worker 进程，CPU 使用率可稳定在 400%
- 进程间无共享内存，
file_get_contents这类阻塞调用不会互相干扰，但也意味着无法直接复用连接池或全局状态 - 进程创建开销大（fork + 内存拷贝），5000 次
new Process()在单核 1G 机器上就耗掉68s，QPS 仅217 - 跨进程通信必须走
IPC（如msgqueue、Table、Atomic），不能直接传对象或闭包
真实项目该选哪个？看瓶颈在哪
别纠结“哪个更快”，先定位你的性能卡点：
- 如果瓶颈是网络延迟（比如调用 10 个外部 HTTP 接口），用
Runtime::enableCoroutine()+go()并发，单进程就够了 - 如果瓶颈是 CPU 密集型（比如图像缩放、JSON 大量解析、加密计算），必须用多进程，协程毫无帮助
- 混合场景（如接收请求 → 查 Redis → 处理数据 → 写 MySQL）建议：主进程用协程处理 I/O，重计算任务投递到
TaskWorker进程执行 - 注意
enableCoroutine()后，sleep()、usleep()、file_get_contents()等函数才变协程安全；普通for循环或数学运算仍是同步阻塞的
容易被忽略的兼容性陷阱
协程不是万能胶，很多 PHP 原生函数在协程环境下会失效或行为异常：
-
curl_exec()不支持协程 —— 必须换用Swoole\Coroutine\Http\Client -
mysqli和PDO需启用Runtime::enableCoroutine()后才异步，否则仍阻塞整个进程 - 自定义扩展若未标记为协程安全（即没调用
sw_coro_resume()/sw_coro_yield()），在协程中调用会导致崩溃或死锁 - 协程内不能使用
pcntl_fork()、stream_select()等依赖系统调用的函数
协程的轻量是以“严格限制运行环境”为前提的 —— 它快，是因为它只允许你走它铺好的那条路。
