Laravel 本身不原生支持多进程模型处理 HTTP 请求，但可通过 Octane（Swoole/RoadRunner）或队列 worker 多进程部署实现真正的并发利用率提升；盲目在传统 PHP-FPM 下“启多个进程”不仅无效，反而会压垮数据库连接和内存。

直接说结论：Laravel 本身不原生支持多进程模型处理 HTTP 请求，但可通过 Octane（Swoole / RoadRunner）或队列 worker 多进程部署实现真正的并发利用率提升；盲目在传统 PHP-FPM 下“启多个进程”不仅无效，反而会压垮数据库连接和内存。

Octane 启动 Swoole 多进程时必须改 octane.php 的 server 配置

Octane 默认用的是 frankenphp（Laravel 12+），但多数生产环境仍依赖 swoole 的成熟多进程能力。若不显式指定，php artisan octane:start 会 fallback 到单线程模式，完全浪费 CPU 核心。

打开 config/octane.php，确认 'server' => 'swoole' 已启用

'concurrent_requests' => 100 是每 worker 进程能并行处理的协程数，不是总并发 —— 真正决定总吞吐的是 'workers' => 4（对应 CPU 核心数）

别漏掉 'max_requests' => 1000，防止长时驻留导致内存缓慢泄漏

启动命令要带 --workers=4： php artisan octane:start --workers=4 --watch

队列 worker 并发必须靠 numprocs + Supervisor 管理

很多人本地开 3 个终端跑 php artisan queue:work 就以为是“多进程”，但生产环境一重启就全挂——没进程管理器，worker 就是裸奔。

Supervisor 的 numprocs=4 才真正启动 4 个独立 PHP 进程，每个都持有自己的数据库连接、缓存实例和内存空间

--timeout=90 必须大于你最慢 Job 的执行时间（比如调第三方验证码接口超时设为 15s，这里至少填 20）

--max-jobs=500 不是越大越好：Eloquent 模型静态属性、全局变量可能累积，500 是较安全的重启阈值

Redis 驱动下，多个 worker 能靠 LPOP 原子性保证任务不重复消费；database 驱动则依赖 FOR UPDATE，高并发下容易锁表

数据库连接池配置被忽略，多进程反而加速崩溃

开了 4 个 Octane worker 或 4 个 queue worker，却还用默认 MySQL 配置？那瞬间就是 4 × 10 = 40 个连接打到 DB，再加 Nginx+PHP-FPM 的连接，MySQL 很快报 Too many connections。

在 config/database.php 的 mysql 配置里补上 'pool' 段（仅 Swoole/RoadRunner 有效）：

'pool' => ['min_connections' => 4, 'max_connections' => 32] —— 这样 4 个 worker 共享最多 32 连接，而非各自独占 10 个

没配连接池时，每个 worker 初始化都会新建连接，且不会自动释放空闲连接；配了之后由 Swoole 内部管理复用

如果用的是 RoadRunner，需额外装 spiral/roadrunner-binary 并启用 mysql-pool 插件

最关键的一点：多进程 ≠ 自动高性能。worker 数量超过 CPU 核心数后，上下文切换开销会反超收益；而连接池、日志驱动（别用 single）、OPCache JIT 这些底层配置，才是让多进程真正稳住的隐性支柱。

Tags: Laravel如何利用多进程模型提升并发利用率

分享到：