hyperf 在协程 i/o 密集场景下性能明显优于 laravel，但该优势仅在 swoole 环境就绪、代码无同步阻塞调用且业务模型适配协程生命周期时才真实生效；laravel 的性能短板源于 php-fpm 重复加载开销，octane 可将其 rps 提升至 800–1500，接近 hyperf 基准线。
Hyperf 在协程 I/O 密集场景下性能明显优于 Laravel，但这种优势只在 Swoole 环境就绪、代码无同步阻塞调用、且业务模型适配协程生命周期时才真实生效；Laravel 的性能短板主要来自 PHP-FPM 模式下的重复加载开销，而 Octane 已能将其 RPS 提升至 800–1500，接近 Hyperf 基准线。
确认 Swoole 协程是否真正启用
Hyperf 启动失败或性能未达预期，八成问题出在 Swoole 环境配置上。不是装了 Swoole 就等于协程可用——必须验证 coroutine 是否 enabled 且版本 ≥ 5.1。
- 运行
php --ri swoole，检查输出中是否有coroutine => enabled和version => 5.1.0（或更高） - 若显示
coroutine => disabled，需重编译 Swoole 并启用--enable-coroutine - Hyperf 3.x 默认使用
co::sleep()替代sleep()，但若你在协程中手动调用file_get_contents()或curl_exec()，仍会触发同步阻塞，必须改用Hyperf\HttpClient\CoroutineHttpClient
Laravel Octane 不是“伪协程”，但有边界
Laravel Octane 把框架启动层常驻内存，但它不改变底层组件的同步行为。Eloquent 查询、Redis get()、队列 push() 等仍走传统阻塞路径，只是省掉了 autoloader、配置解析、服务提供者注册这些重复开销。
- Octane 支持 Swoole 和 RoadRunner 两种驱动，Swoole 模式下可启用
async_signals和max_coroutine提升并发上限 - 若项目重度依赖
spatie/laravel-permission这类未做协程适配的包，Hyperf 中需替换为hyperf/permission，而 Laravel + Octane 可照常使用，无兼容风险 - 压测时注意：Laravel 默认 session 存文件，高并发下
flock()会成为瓶颈；切到 Redis session 后，Octane 性能提升更明显
协程泄漏比性能更重要
Hyperf 的高 RPS 很容易掩盖一个致命问题：协程上下文污染。静态变量、全局缓存、未关闭的 PDO 连接，在短生命周期的 Laravel 中自动回收；但在常驻进程里，它们会跨请求累积，最终导致内存溢出或数据错乱。
- 避免在协程内直接赋值
static $cache = []，改用Co::getContext()或容器注入的ApplicationContext - 数据库连接池由
hyperf/database自动管理，但自定义 PDO 实例必须显式$pdo->close() - Hyperf 日志默认异步写入，但若你用
file_put_contents('debug.log', ...)手动打日志，会阻塞当前协程——应统一走LoggerInterface
选型真正卡点不在“谁更快”，而在“谁更可控”：Hyperf 要求你对协程调度、资源生命周期、错误传播链有明确掌控；Laravel 则把复杂性藏在框架内部，用可预测性换开发效率。如果团队里没人 debug 过 Co::stats() 输出的协程数暴涨，或者没看过 strace -p $(pgrep -f 'hyperf:server') 的系统调用堆栈，那 Hyperf 的性能优势大概率会变成线上事故温床。
