enable_coroutine控制swoole是否为每个请求自动创建协程上下文：开启时onrequest等回调默认运行于协程中，可直接使用co::sleep等api；关闭时退回到1.x同步模式，go()仍可用但协程api会报错，且task_enable_coroutine失效。

开启 enable_coroutine 后，Swoole 会为每个请求自动创建协程上下文，所有回调（如 onRequest、onReceive）都在协程中执行；关闭后，回调退回到纯同步模式，和 Swoole 1.x 行为完全一致。

enable_coroutine=true 时的默认行为

底层在进入 onRequest 等事件回调前，已为你启动一个协程，你无需手动调用 go() 就能直接使用协程 API：

• co::sleep()、Swoole\Coroutine\MySQL、Swoole\Coroutine\Http\Client 等可即用
• 定时器（after、tick）也运行在协程环境中，支持协程阻塞调用
• HTTP Server 的每个请求天然隔离，变量作用域不互相干扰
• 错误堆栈更清晰，协程 ID 可追踪（Co::getcid()）

enable_coroutine=false 时的实际影响

这不是“禁用协程功能”，而是彻底退出协程调度环境：

Swoole 6.1.1

Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。

下载

• go() 仍可调用，但必须显式包裹所有协程逻辑，否则无法并发
• co::sleep()、协程 MySQL 等会直接报错：Fatal error: Uncaught Swoole\Error: must be called in the coroutine
• 所有 I/O 操作（如 file_get_contents、cURL）保持同步阻塞，会卡住整个 worker 进程
• 与旧版 Swoole 1.x 兼容性 100%，适合迁移过渡或调试协程问题

为什么不能只靠 task_enable_coroutine？

task_enable_coroutine 是独立开关，但它**依赖 enable_coroutine === true 才生效**。如果主服务关闭了 enable_coroutine，即使你设了 task_enable_coroutine => true，Swoole 也会忽略它，并在 onTask 中抛出警告或降级为同步执行。

• 常见误配：'enable_coroutine' => false, 'task_enable_coroutine' => true → 实际无效
• 正确组合只有两种：enable_coroutine=true（推荐），或两者都 false
• task_enable_coroutine 本质是“在已有的协程环境里，为每个任务再开一个子协程”，不是独立协程入口

容易被忽略的关键点

很多人以为开了 enable_coroutine 就万事大吉，但实际协程能否真正非阻塞，还取决于是否启用 Runtime Hook：

• 默认情况下，file_get_contents、curl_exec、sleep() 等**不会自动协程化**，仍会阻塞 worker
• 必须显式调用 Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_ALL)（建议放在 Server->start() 前）
• PHP 8.3+ 下部分函数（如 stream_socket_client）需额外确认是否在 SWOOLE_HOOK_ALL 支持列表中
• 协程栈默认仅 2KB，深度递归或大数组局部变量可能触发栈溢出，而错误提示常被掩盖为“segmentation fault”