协程创建本身不慢，慢在初始化和上下文切换；应避免在go()回调中重复实例化、文件加载或全局钩子滥用，优先使用co\run、连接池与预热，并警惕协程泄漏与内存增长。
协程创建本身不慢，慢在初始化和上下文切换
协程启动开销低是事实，但实际项目中感知到“慢”，往往不是go()调用本身耗时，而是每次协程启动时重复加载类、重建连接、解析配置等隐式操作。Swoole底层协程栈默认仅2KB，创建成本确实极小，但若每个协程都执行new Swoole\Coroutine\MySQL()或require_once同一文件，开销就迅速累积。
常见错误现象：压测时QPS上不去、CPU使用率低但响应延迟高、strace显示大量openat或stat系统调用。
- 避免在
go()回调内重复实例化客户端（如MySQL、HttpClient），改用连接池或复用已创建对象 - 禁用
opcache.validate_timestamps = 1，否则每次require都会触发文件时间戳校验，协程会在PHP加载阶段卡住数百毫秒 - 不要在协程里做
file_get_contents读取配置文件——应提前加载并注入，或用Swoole\Coroutine\WaitGroup统一预热
用Co\run()替代多次go()嵌套
频繁调用go()本身无性能问题，但嵌套调用（比如A协程里再go() B，B里又go() C）会增加调度层级和栈管理负担。更关键的是，它掩盖了任务边界，导致Swoole\Coroutine::getCid()难以追踪、defer清理逻辑混乱。
使用场景：批量HTTP请求、微服务并行调用、设备状态轮询等需统一生命周期管理的场景。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 优先用
Co\run(function () { ... })包裹整个并发逻辑，而非分散多个go() - 配合
Swoole\Coroutine\Channel或WaitGroup做同步，避免在回调里层层go() - 若必须动态启协程（如消息队列消费），确保
go()内无阻塞逻辑，且及时clear不再需要的定时器或资源
慎用Runtime::enableCoroutine()全局钩子
Swoole\Runtime::enableCoroutine()会让所有IO函数（包括curl_exec、pdo_mysql等）自动协程化，看似省事，实则引入不可控开销：它需在每次调用前做函数签名检查、上下文切换判断，并可能触发额外的Hook注册与内存分配。
典型陷阱：Laravel Octane默认启用该模式，但其底层DB驱动未适配协程，导致MySQL仍走同步PDO，反而因Hook层多了一道拦截而变慢。
- 只对明确支持协程的扩展（如
Swoole\Coroutine\MySQL、Swoole\Coroutine\Http\Client）显式调用，不依赖全局钩子 - 第三方SDK（如Redis客户端、Elasticsearch SDK）务必确认是否原生协程兼容，否则宁可手动投递到
Task Worker处理 - 用
var_dump(Swoole\Coroutine::getPcid())验证每条路径是否真在协程内，输出false或0说明钩子未生效或被绕过
协程ID和内存泄漏比启动开销更值得警惕
真正拖垮系统的往往不是协程启动慢，而是协程没退出、资源没释放、变量意外闭包导致内存持续增长。Swoole不会自动回收长期运行却无IO挂起的协程，go(function () { while (true) { ... } })这类写法极易造成协程泄漏。
容易被忽略的地方：协程内引用了外部大数组、闭包捕获了$this或静态变量、defer函数里抛出异常未被捕获导致清理逻辑中断。
