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 这些底层配置，才是让多进程真正稳住的隐性支柱。
