Swoole 4 是协程用于真实业务的分水岭，因它修复了 Swoole 3 在 __destruct 等场景调用协程导致崩溃的问题，采用双栈模型解耦协程与 ZendVM，支持安全嵌套调度及内置连接池，而 Swoole 3 存在调度语义、连接复用和兼容性等根本缺陷。
Swoole 3 和 4 不是“小升级”，而是协程能否用在真实业务里的分水岭——Swoole 3 在 __destruct、call_user_func、魔术方法里用协程会崩溃，Swoole 4 才算真正可用。
为什么 __destruct 里调 Co::sleep() 在 Swoole 3 会段错误？
这是 Swoole 3 最典型的兼容性崩点：协程调度器依赖 setjmp/longjmp，而 PHP 析构函数执行时 ZendVM 的栈状态不稳定，longjmp 直接跳回已销毁的协程栈，触发内存非法访问。
- Swoole 4 改用 PHP+C 双栈模型，协程上下文与 ZendVM 生命周期解耦，
__destruct中调Co::sleep()、Co::httpGet()完全安全 - 但注意：Swoole 3 的扩展编译时若没加
--enable-swoole-curl，连curl_init()都可能被协程 hijack 导致阻塞，这点 Swoole 4 已默认隔离 - 验证方式：写个带
__destruct的类，在onRequest中 new 后 return，Swoole 3 下压测必 core，Swoole 4 下稳定
Co::create() 和 go() 在 Swoole 3 vs 4 中的行为差异
表面只是函数名不同，背后是调度语义的根本变化。Swoole 3 的 Co::create() 是“手动创建+手动 resume”，而 Swoole 4 的 go() 是“声明即调度”，且支持嵌套协程。
- Swoole 3：
Co::create()返回协程 ID，必须显式调Co::resume($cid)才会跑；漏调就永远挂起 - Swoole 4：
go(function () { ... })立即入调度队列，无需手动 resume，且内部可再go()，形成真正的协程树 - 兼容陷阱：从 Swoole 3 迁移时，若代码里混用了
Co::create()+Co::yield()，直接改成go()会逻辑错乱——因为yield()在 Swoole 4 中语义已变为“让出当前协程”，不是“挂起指定协程”
协程 MySQL 客户端在 Swoole 3 和 4 中的连接复用表现
两者都支持 Co::mysql()->connect()，但连接池行为和超时控制差异极大，直接影响高并发下的 DB 连接数爆炸风险。
- Swoole 3 的
Co::mysql没内置连接池，每次connect()都新建 TCP 连接，close()后连接立即释放；高频请求下容易打满 MySQL 的max_connections - Swoole 4 的
Swoole\Coroutine\MySQL默认启用短连接池（基于协程 ID 哈希），同一协程内重复connect()会复用连接，且支持timeout参数精确控制握手/查询超时 - 坑点：Swoole 3 时代习惯写
$db = new Co::mysql(); $db->connect(...);，迁移到 Swoole 4 后必须改用$db = new Swoole\Coroutine\MySQL();，否则会报Class 'Co' not found——因为Co::命名空间在 4.x 中已被废弃
真正要命的不是版本号，是那些藏在 array_map() 回调、__call()、甚至 json_encode() 的内部递归调用里的协程——Swoole 3 一碰就崩，Swoole 4 能稳住。别只看文档说“支持协程”，得真把业务代码里的每个钩子点都跑一遍压测。
