frankenphp 1.4 worker数需兼顾内存、cpu与i/o：内存是硬约束，worker×memory_limit＜可用内存－2gb；cpu核数仅作参考，1–2核设1–2个，4核起始6个，8核以上试12–16个；i/o密集型可增1–2个；与laravel octane配合时，--workers≤frankenphp worker数。
FrankenPHP 1.4 的 worker 模式下，worker 数量不是“越多越好”，也不是简单等于 CPU 核心数。它本质是预分配的、可并行执行 PHP 请求的独立线程数，每个 worker 同一时刻只处理一个请求，靠数量堆出并发能力。设得不合理，轻则浪费内存、拖慢响应，重则触发 OOM 或频繁重启。
核心约束：内存必须兜得住
这是硬性底线，优先级最高：
-
公式必须成立：worker 数 ×
memory_limit＜ 服务器可用内存（不含 swap），建议预留至少 2GB 余量 - 例如：4GB 内存机器，
memory_limit = 128M，理论最大 worker 数为 4096 ÷ 128 ≈ 32，但实际应压到 12～16；若用 256M，则最多只能设 8～10 - 别忽略 OPcache、Composer autoloader、框架实例等额外内存开销——它们也吃在每个 worker 进程里
按 CPU 规模起步，再看 I/O 特征
CPU 核心数提供的是调度上限参考，真实负载类型决定是否加减：
- 1–2 核：设 1 或 2，再多会因上下文切换反拖慢响应
- 4 核：从 6 开始压测，不建议直接用默认的 8（CPU×2）
-
8 核及以上：可试 12～16，但必须盯紧
frankenphp_busy_threads指标 - 大量依赖 MySQL/Redis 等外部 I/O？可比纯 CPU 密集型多加 1–2 个 worker，让等待不空转
和 Laravel Octane 配合时，必须对齐层级
Octane 的 --workers 是应用层子进程数，FrankenPHP 的 worker 数是底层执行单元上限，二者不能混为一谈：
- Octane 启动命令必须带
--server=frankenphp，否则完全绕过 FrankenPHP，workers.count对它无效 -
--workers=N必须 ≤ FrankenPHP 的 worker 数，否则报resource temporarily unavailable - 推荐起步值：
--workers=min(4, worker数)，再根据busy/total比值调优：长期 >0.9 且 QPS 上不去 → 加 worker 数；长期
验证是否合理，盯三个信号
别只看平均延迟或 RPS，重点看系统是否“稳”：
- 用
watch -n 1 'ps aux | grep frankenphp-worker | wc -l'看 worker 进程数是否稳定（波动 ±1 正常，持续增减说明配置冲突） - 压测时观察
frankenphp_queue_depth是否持续上涨：涨了说明 worker 不够，请求排队 - 查日志中
Worker #X restarted after max_requests出现频率：每分钟都重启，大概率是memory_limit太紧或max_requests设太小
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
