webman 3协程上下文比hyperf 2更轻量，核心在于其采用php原生fiber、不强制加载di容器与注解、请求上下文不自动绑定、无运行时字节码增强，协程创建开销更低、内存占用更少、上下文查找延迟更小。
Webman 3 的协程上下文比 Hyperf 2 更轻量，核心原因不在“协程实现本身”，而在于运行模型、初始化粒度和框架职责边界的不同。
协程调度器开销更小
Webman 3 默认使用 PHP 原生 Fiber（PHP 8.1+）作为事件循环底层，Fiber 是语言级轻量协程，无独立栈内存预分配、无调度器线程管理、无跨协程信号同步机制。
Hyperf 2 默认依赖 Swoole 协程，需启动完整协程调度器（Swoole\Coroutine::create），每次创建协程会预留 256KB 栈空间（可调但默认值高），且调度器本身有约 0.03–0.06ms 固定初始化延迟。
→ 同一请求路径下，Webman 发起 100 个并发 HTTP 调用，协程创建总开销比 Hyperf 低 3–5ms。
框架启动与请求生命周期解耦更彻底
Webman 3 本质是 Workerman 上的 HTTP 封装层，不强制加载服务容器、AOP、注解扫描、配置中心等运行时组件。
Hyperf 2 启动即构建完整 DI 容器、解析全部注解、注册 20+ 中间件和事件监听器，每个协程内都隐式持有对容器、上下文对象、日志实例的引用。
→ Webman 单协程平均内存占用约 1.2MB（含 PHP 运行时），Hyperf 2 在同等逻辑下常达 2.8MB+，其中 40% 来自容器元数据与代理类缓存。
请求上下文不自动绑定全局状态
Webman 3 的 Request 和 Response 对象默认不注入到协程本地存储（Co-Context），开发者需显式传参或手动挂载。
Hyperf 2 默认通过 ApplicationContext::getContainer()->get(RequestInterface::class) 自动从协程上下文中提取，背后触发 ContextManager 的 get() → find() → make() 链路，涉及至少 7 层方法调用和反射判断。
→ 简单 GET 接口响应中，Hyperf 每次请求多出约 0.018ms 的上下文查找开销，高并发下易累积为可观延迟。
无运行时代码增强（No Runtime Bytecode Enhancement）
Hyperf 2 为支持注解路由、AOP 切面、JSON RPC 等特性，在运行时动态生成代理类、重写方法字节码（通过 hyperf/aop 和 hyperf/proxy-manager）。这些操作在协程首次调用目标方法时触发，且结果需缓存到协程隔离存储中。
Webman 3 不提供注解驱动开发，默认采用显式路由定义和传统 OOP 写法，无任何运行时类重写行为。
→ 新协程处理首个请求时，Hyperf 可能延迟 0.1–0.4ms（取决于代理类复杂度），Webman 保持稳定亚毫秒级进入业务逻辑。
不是协程“能力弱”，而是 Webman 选择把重量留给业务可控处——该轻的地方极轻，该重的地方靠插件按需加载。
