Coroutine::set 设置的是进程级全局配置，影响该 Worker 进程内后续创建的所有协程，而非仅当前协程；必须在 onWorkerStart 等进程初始化阶段调用，运行时调用多数参数静默无效。
Coroutine::set 会影响所有协程还是仅当前协程？
Coroutine::set 设置的是**进程级全局配置**，不是协程局部设置。一旦调用，它会影响该 Worker 进程内后续创建的所有协程，包括 go() 启动的、HTTP 客户端内部启动的、甚至 Co::sleep() 触发的调度行为。
常见误解是“在某个协程里调用 Coroutine::set 就只改这个协程”，实际完全不是——它没有作用域，也没有返回值，调了就生效，且不可回滚。
- 必须在任何协程创建前调用（如
onWorkerStart中），否则部分协程可能已按旧配置初始化，导致行为不一致 - 若在多个地方重复调用（比如不同模块都执行
Coroutine::set(['hook_flags' => ...])），后一次会覆盖前一次，容易引发 hook 缺失或重复 hook 导致的崩溃 - 修改
max_coroutine后，已存在的协程不受影响，但新go()调用会立即受新上限约束
hook_flags 设置错位会导致什么错误？
最典型的后果是：协程“假死”或“卡住”，表现为请求延迟飙升、coroutine_num 持续上涨、P99 延迟翻倍，但错误日志里几乎没报错。
这是因为未被 hook 的同步函数（如 file_get_contents()、curl_exec()、sleep()）会让当前协程阻塞整个 Worker 线程，其他协程全部排队等待——看起来像并发能力崩了，其实是调度器被堵死了。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
SWOOLE_HOOK_ALL是最稳妥的选择，尤其在业务逻辑不确定调用链路时 - 若只开
SWOOLE_HOOK_STDIO，连fopen()都不会协程化，文件读写直接阻塞 - 使用
SWOOLE_HOOK_CURL | SWOOLE_HOOK_FILE组合时，注意curl_setopt($ch, CURLOPT_RETURNTRANSFER, true)必须设，否则curl_exec()可能触发隐式输出，绕过 hook - 可通过
swoole_coroutine_stats()查看coroutine_peak_num是否远高于平均值，这是未释放协程或阻塞调用的典型信号
max_coroutine 和 memory_limit 怎么协同控制？
每个协程默认占用约 8 KB 栈空间，10 万个协程就占约 800 MB 内存。但 PHP 的 memory_limit 限制的是**堆内存**，而协程栈属于**C 堆外内存**，不受其约束——所以即使 memory_limit = 128M，max_coroutine = 100000 仍可能跑起来，但系统内存会被吃光。
- 真正起作用的是服务器物理内存和
ulimit -v（虚拟内存上限），而非 PHP 配置 - 压测时观察
swoole_server->stats()中的worker_memory_usage字段（Swoole ≥ 5.0.1），比靠估算更准 - 线上建议将
max_coroutine设为预估峰值并发的 1.5–2 倍，而不是盲目拉到 65536；例如平均并发 3000，可设5000，留出 buffer 防突发 - 如果频繁触发
"maximum coroutine count exceeded"错误，先查是否协程泄漏（比如go()启动后没 await 或没异常捕获导致退出失败），再考虑调大
为什么在 onReceive/onRequest 里调用 Coroutine::set 没用？
因为此时 Worker 进程早已启动，大量协程可能已在运行，Coroutine::set 的多数参数（尤其是 hook_flags 和 max_coroutine）**仅在进程初始化阶段生效**。运行时调用只会静默忽略，不报错也不生效。
你看到的“似乎生效了”，大概率是其他地方提前设置了，或者你误判了现象（比如以为某次请求变快是因为 set，其实是缓存或连接池复用带来的副作用）。
- 唯一可在运行时安全修改的参数是
trace_flags（用于开启/关闭协程追踪），但它本身不改变行为，只影响调试信息输出 - 所有关键配置必须在
onWorkerStart回调中完成，且最好只设一次 - 若需动态调整 hook 行为（如灰度启用某类 I/O 协程化），应改用中间件包装 + 条件判断，而不是 runtime 修改
Coroutine::set
Coroutine::set 的生效时机和作用域边界非常硬，不像普通变量可以层层覆盖。它是一次性写入进程上下文的开关，改错位置、改错顺序、改错时机，都会让整个协程调度模型悄悄失效。 
