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”
