Laravel Octane性能并非自动提升，而是依赖内存复用、协程调度与状态隔离的精准平衡；配置不当或状态污染会导致比PHP-FPM更慢更不稳定。
直接说结论：Laravel + Octane + Swoole 的性能不是“自动起飞”，而是靠精准控制内存复用、协程调度和状态隔离三者之间的平衡。没做对配置或忽略状态污染，反而比 FPM 更慢、更不稳定。
为什么 Octane::concurrently() 有时比串行还慢
这个函数表面是并发，实际依赖 Swoole 协程调度器的公平性与 I/O 阻塞点识别。如果被调用的代码里混入了非协程安全的操作（比如 file_get_contents()、curl_exec() 或未适配协程的 DB 驱动），Swoole 会退化为同步阻塞，所有协程卡在同一处。
- 必须确认你用的是
swoole/ide-helper或hyperf/database这类协程兼容的客户端，原生 PDO 默认不支持协程 -
Octane::concurrently()内部没有超时控制，一个慢请求会拖垮整组，建议外层包一层Co::sleep(3)或用Swoole\Coroutine\Http\Client自定义 timeout - 高频调用时，协程栈深度过大会触发
coroutine stack overflow错误，可在config/octane.php中调大'coroutine' => ['stack_size' => 2097152]
workers 和 task_worker_num 怎么设才不翻车
这两个参数不是越大越好。Swoole 的 worker 进程负责处理 HTTP 请求，task_worker 进程专用于异步任务（如发邮件、写日志）。设错会导致 CPU 空转或任务积压。
-
workers建议设为cpu_count * 1.5，超过 24 个后上下文切换开销会明显上升；实测在 16 核机器上设 24 比设 32 吞吐高 12% -
task_worker_num只在你显式调用Octane::task()时生效，纯 API 场景通常设 0；若启用，建议 ≤workers的 1/3，避免 task 进程抢走 worker 的 CPU 时间片 - 必须配合系统级限制：
ulimit -n 65535，否则 worker 启动时会报Too many open files
数据库连接池不是开个开关就完事
Octane 常驻内存后，Eloquent 默认的连接不会自动释放，短连接模式下容易耗尽 MySQL 的 max_connections。光设 PDO::ATTR_PERSISTENT => true 不够，它只是复用连接句柄，不是真正的连接池。
- 推荐用
hyperf/database替代原生 Eloquent，它内置协程连接池，通过pool.max_connections控制上限 - 在
config/database.php中为 MySQL 驱动加'attributes' => [PDO::ATTR_TIMEOUT => 3]，防止协程卡死在慢查询上 - 务必关闭
DB::listen()类调试钩子——它们在常驻进程里会累积监听器实例，引发内存泄漏
缓存失效和 opcache.preload 的坑
php artisan octane:preload 生成的预加载脚本，本质是把类文件 dump 成 OPcache 可执行字节码。但它不会自动感知 .env 或配置变更，改了 APP_ENV 或缓存驱动后必须手动重跑。
- 预加载脚本默认只包含
app/和config/目录，第三方包里的服务提供者（如laravel/sanctum）需手动加到config/octane.php的warmup数组里 -
Cache::forget()在 Octane 下可能失效——因为多个 worker 进程各自持有独立的本地缓存副本，要用 Redis 或 APCu 这类共享后端 - 别在
AppServiceProvider::boot()里写Cache::rememberForever()，常驻进程会让这个“forever”真的 forever，直到 reload
最麻烦的从来不是启动命令写几遍，而是每个请求之间怎么保证干净——静态属性、全局变量、单例容器绑定、甚至 $_SESSION 残留，都会在 worker 复用中悄悄污染下一个请求。这点没法靠文档覆盖，只能靠 WorkerStarting 事件监听器一层层清理。
