swoole 5.1 迁移需重适配而非升级：协程启用须显式指定钩子（如swoole_hook_file | swoole_hook_socket），swoole_hook_all已移除；websocket配置中enable_coroutine废弃；guzzle-swoole须升至v3.0且runtime::enablecoroutine()需先于client初始化。
Swoole 4 到 5 的迁移不是“升级”，而是“重适配”——v4.4.x 仍受官方维护（至2026年3月7日），但 v5.1 引入了协程调度器重构、WebSocket 底层重写、SWOOLE_HOOK_ALL 行为变更等不兼容改动，直接替换 composer update 极大概率导致协程卡死、连接泄露或 file_get_contents 阻塞。
协程启用方式变了：Runtime::enableCoroutine() 不再“全钩”安全
v4.4 中常用 Swoole\Runtime::enableCoroutine(true, SWOOLE_HOOK_ALL) 一键协程化所有 IO；v5.1 起，SWOOLE_HOOK_ALL 已移除，强制要求显式指定钩子范围。盲目保留旧写法会触发警告甚至静默失效。
- 必须改用细粒度钩子，例如：
Swoole\Runtime::enableCoroutine(true, SWOOLE_HOOK_FILE | SWOOLE_HOOK_SOCKET | SWOOLE_HOOK_CURL) -
SWOOLE_HOOK_CURL在 v5.1 中不再自动覆盖curl_exec，需配合guzzle-swoole使用（否则 Guzzle 仍走阻塞调用） - 若项目用了
pdo_mysql原生扩展，v5.1 默认不 hook，得手动加SWOOLE_HOOK_PDO，且确认 PDO 实例是协程安全的（非全局单例）
WebSocket 服务配置项语义调整：enable_coroutine 已废弃
v5.1 中 enable_coroutine 配置项被彻底移除，协程支持由 Server 启动时自动判断，但行为更严格：Worker 进程内所有回调（onOpen、onMessage）默认运行在协程中，且禁止在回调里执行同步阻塞操作（如 sleep()、file_put_contents 不带 SWOOLE_HOOK_FILE）。
- 原 v4.4 写法：
'enable_coroutine' => true→ 必须删除，否则启动报错Unknown option enable_coroutine - 广播逻辑需检查：
$server->push()在 v5.1 中已协程安全，但若循环中混用curl_exec或未 hook 的 DB 操作，会导致整个 Worker 协程挂起 - 长连接稳定性提升明显，但代价是：任何未被 hook 的同步调用都会让该协程“卡住”，影响其他连接
guzzle-swoole 必须升级到 v3.x，且初始化时机不能晚于 Runtime::enableCoroutine()
v4.4 下可用 yurunsoft/guzzle-swoole:^2.2，但 v5.1 要求 v3.0+，否则 GuzzleHttp\Client 构造时会因协程上下文缺失而 fallback 到阻塞模式，且无任何提示。
- 安装命令必须更新：
composer require yurunsoft/guzzle-swoole:^3.0 - 初始化代码顺序关键：
Runtime::enableCoroutine()必须在new Client()之前执行，否则协程处理器注册失败 - 验证是否生效：发起一个 HTTP 请求后，用
swoole_coroutine::stats()查看coroutine_num是否增长，而非只看响应时间
最易忽略的一点：Swoole 5.1 的 worker_num 和 max_connection 关系更敏感——当并发连接数接近 max_connection 时，若某个协程因未 hook 的 IO 卡住，新连接可能被直接拒绝，而不是排队等待。务必结合 swoole_server::stats() 中的 connection_num 和 coroutine_num 对比监控，不能只看 QPS。
