Workerman 5.x 是架构级升级，HTTP 被重构为可插拔组件 workerman-http，需手动安装注册；协程支持要求 PHP ≥ 8.1 且 workerman ≥ 5.1.0，支持 Swoole/Swow/Fiber 驱动；Session 和 SSE 需单独引入并显式初始化。
Workerman 5.x 是一次架构级升级，4.x 的 HTTP 能力在 5.x 中被整体重构并下沉为可插拔组件；如果你用的是 workerman 做 HTTP 服务，不升级到 5.1+ 就无法使用协程上下文（Context）、自动协程化、多驱动切换等关键能力。
HTTP 服务从“内置”变成“可选组件”
Workerman 4.x 把 HTTP 支持直接集成进核心，Worker 构造时传 'http://0.0.0.0:8080' 就能跑请求/响应对象。但 5.x 开始，HTTP 协议栈被拆成独立的 workerman-http 包，必须显式安装和注册：
- 4.x：无需额外依赖，
use Workerman\Protocols\Http\Request直接可用 - 5.x：
composer require workerman/http后，还需调用HttpServer::addRouter()或手动绑定中间件 - 不装
workerman-http，即使写new Worker('http://...')也会报错：Class "Workerman\Http\Server" not found - 好处是协议解耦——你可以只用 TCP Worker，完全不加载 HTTP 相关代码，内存占用更低
协程支持机制完全不同
4.x 根本没有协程抽象层，所有异步操作靠回调或 async-redis 这类专用客户端实现；5.x 则统一了协程驱动模型，但要求明确指定底层引擎：
- 必须满足 PHP ≥ 8.1 +
workerman >= 5.1.0才支持Coroutine和Context - 可选驱动：
Swoole::class（需 Swoole ≥ 5.0）、Swow::class、Fiber::class（仅 PHP 8.1+ 原生 Fiber） -
Fiber驱动下，file_get_contents()、curl_exec()等原生阻塞函数不会自动协程化，会卡死整个进程——这点和 Swoole 完全不同 - 示例中若把
$worker1->eventLoop = Swoole::class换成Fiber::class，又没加revolt/event-loop，启动就抛EventLoop not available
Session 和 SSE 不再开箱即用
4.x 的 Session 类和 SSE 支持是 HTTP 模块的一部分，5.x 中它们变成了需要手动启用的“功能模块”：
-
Session需要单独composer require workerman/session，且必须调用Session::init()并配置存储驱动（如 Redis） -
SSE接口不再自动识别text/event-stream，得自己在路由里写逻辑：$response->header('Content-Type', 'text/event-stream');+$response->end("data: ...\n\n") - 4.x 中
$request->session()->set('key', 'val')直接生效；5.x 忘记调Session::init()就会静默失败，没有任何错误提示 - 升级后发现 session 数据丢了、SSE 连接秒断，八成是漏了初始化或 header 设置不完整
真正麻烦的不是 API 变了，而是 4.x 项目迁移到 5.x 时，那些散落在 onMessage 回调里的同步 HTTP 请求、Redis 操作、文件读写，一旦没配对协程驱动或没换异步客户端，就会在高并发下突然变慢甚至阻塞——这种问题不会报错，只会让 QPS 掉一半，排查起来特别费时间。
