用 RoadRunner 为 PHP 应用扩容提速
RoadRunner 通过长驻 PHP worker 复用应用状态，减少重复引导。本文区分它与 PHP-FPM 的进程生命周期，介绍 Laravel Octane 接入及内存、请求隔离注意事项。
本文依据官方文档整理，未执行运行验证或性能基准。代码片段展示局部用法，业务函数、数据和环境需按项目补齐；版本与配置以所引文档为准。
直接回答：RoadRunner 用长生命周期 PHP 进程处理连续请求，复用已引导的应用状态，减少每个请求的框架初始化工作；收益取决于实际负载。它是 Go 写的应用服务器，经 goridge 桥接 PHP worker，替代 Nginx+FPM 组合中的 FPM 角色。
传统 FPM 架构的开销
经典生产架构：Nginx/Caddy → FastCGI → PHP-FPM。FPM worker 进程也会复用，但通常在每次请求中重新引导应用并在请求结束时清理请求级状态；不是每次请求都启动、销毁 OS 进程。
OPcache、APCu 能缓存部分编译产物与数据，但引导阶段无法完全消除——框架启动（容器初始化、服务注册）在每个请求上重复付费。
RoadRunner 的做法
worker 进程常驻：环境引导一次，连续处理成百上千个请求后才回收重启。框架启动成本可以被摊薄，但每请求的处理、清理和外部依赖成本依然存在——这正是 Node.js/Go 服务天然享有的优势，RoadRunner 把它带给 PHP。
上手
composer require laravel/octane
php artisan octane:install --server=roadrunner
php artisan octane:start --server=roadrunner
以上以 Laravel 12 + Octane 为例，在已有兼容 Laravel 项目中执行，并按安装提示准备匹配的 RoadRunner 二进制。非 Laravel 应用还需提供 HTTP worker 循环、PSR-7 依赖与 .rr.yaml，不能只装 CLI 就启动。.rr.yaml 配置 worker 数量、内存上限与回收策略（max_jobs 控制单 worker 处理多少请求后重启，防内存泄漏累积）。
注意事项
- 内存泄漏敏感：长驻进程把框架/代码里的泄漏放大——可按负载设置请求数和内存回收阈值，并修复泄漏根因
- 全局状态陷阱：静态变量跨请求存活，写代码时不能再假设"每请求干净环境"
- 框架适配：Laravel Octane、Symfony 可通过相应 Runtime/社区适配器接入，需核对包的维护状态与兼容版本，别裸改核心
什么时候值得上
框架引导占比较高时值得评估。本文未执行性能基准；应以相同流量、扩展、数据库及资源限制比较吞吐、尾延迟和常驻内存，再判断迁移收益。
常见问题（FAQ）
Q：RoadRunner 和 Swoole/OpenSwoole 怎么选？
A：Swoole 是 PHP 扩展（协程能力强但侵入深）；RoadRunner 是外部 Go 进程，仍需兼容的 worker/框架适配，并审查请求状态与依赖。不能以外部进程形态推断迁移无改动；按运行模式、扩展兼容性和运维要求选型。
Q：现有 Laravel 项目迁移成本高吗？
A：走 Laravel Octane（官方包）选择 RoadRunner 驱动，工期取决于框架版本、第三方包和常驻状态审计；踩坑主要在全局状态与单例污染。
Q：Nginx 还需要吗？
A：建议保留做 TLS 终止与静态资源，RoadRunner 专注 PHP 请求；小项目也可让 RoadRunner 直接扛 HTTP。
官方参考
资料核对日期：2026-09-29。
