num_threads必须按容器内存反推，不能按cpu核数硬设：每个线程常驻内存（含opcache、autoload等），预分配不释放；设16线程即恒占内存，易触发oom；应实测单请求常驻内存，按（容器mem_limit−opcache.memory_consumption）÷单请求内存反推上限。
num_threads 必须按容器内存反推，不能按 CPU 核数硬设
FrankenPHP 的 num_threads 不是“越多越好”，它直接决定常驻线程数，而每个线程都会吃掉一份常驻内存（含 OPcache、autoload 类、扩展初始化数据等）。你设 num_threads = 16，哪怕请求量很低，这 16 个线程也一直占着内存——和 PHP-FPM 的“空闲进程”不同，FrankenPHP 线程池是预分配、不释放的。
常见错误是看到 16 核就设 num_threads = 32，结果容器 RSS 内存瞬间突破 2GB，触发 OOM Killer 杀进程，dmesg | grep -i "killed process" 显示 FrankenPHP 被干掉，但 PHP 日志里什么都没有。
实操建议：
- 先测单请求常驻内存：在入口脚本加
memory_get_peak_usage(true)，跑几次典型请求（如 Laravel API、WordPress 首页），取稳定值（非峰值） - 用公式反推上限：
num_threads ≤ (容器 mem_limit - opcache.memory_consumption) ÷ 单请求常驻内存 - 纯 API 服务（Laravel/Symfony + OPcache=128M）：单请求约 30MB → mem_limit=512m 时，
num_threads最大取 12（(512−128)÷30≈12.8） - WordPress 或启用 Mercure：单请求常驻 40MB+，同样 512m 容器下，
num_threads应压到 8 甚至 6
max_threads 要严控，超了等于主动制造雪崩
max_threads 是运行时可临时拉起的线程上限，它不包含 num_threads。比如 num_threads = 8、max_threads = 12，那最多只允许额外加 4 个线程，总数封顶 12。
很多人设 max_threads = 64 图“保险”，结果一遇流量毛刺，线程数飙到 50+，上下文切换暴涨，Go runtime 调度失衡，frankenphp_busy_threads 滞留 1–2 个，其余全卡在 S 状态排队，Caddy 开始报 context deadline exceeded 或直接 503。
实操建议：
- I/O 密集型（如调外部 API、DB 查询多）：可设
max_threads = num_threads + 4，再加max_wait_time = 100ms防队列积压 - CPU 密集型（如图像处理、大量计算）：
max_threads ≤ num_threads，甚至禁用扩容（设为num_threads） - 绝对不要用
auto—— 它会让 FrankenPHP 自行扩到失控，尤其在内存受限时
memory_limit 和容器 mem_limit 必须配对校验
memory_limit 在 FrankenPHP 中只管单请求，但它和 num_threads 共同决定总内存下限。比如 memory_limit = 512M、num_threads = 8，光是“理论峰值”就达 4GB，远超大多数生产容器配置。
更危险的是：实际单请求常驻内存可能只有 35MB，但 memory_limit 设太高会让一个异常请求（如循环加载大文件）拖垮整个线程池，连带挤占 OPcache 空间，引发 opcache_get_status()['oom_restarts'] > 0，进一步放大内存抖动。
实操建议：
-
memory_limit取值原则：够用 + 留 20% 余量。Laravel API 建议 256M，WordPress 建议 512M，CLI Worker（如清算任务）可设 1024M 但必须配mem_limit封顶 - Docker Compose 中必须显式写：
mem_limit: 1g、mem_reservation: 768m，否则等于裸奔 - 验证是否匹配：启动后执行
ps aux --sort=-rss | head -5，看 FrankenPHP 进程 RSS 是否稳定在mem_limit × 0.8以内
多个应用共用 FrankenPHP 容器时，线程上限得按“最重应用”算
FrankenPHP 多线程模型下，所有应用共享同一进程地址空间。你给 Laravel 设 memory_limit = 256M、WordPress 设 memory_limit = 512M，不代表总内存就是 768MB——OPcache 是全局共享的，autoload 类表会叠加，静态资源缓存互不感知，最终 RSS 往往是单应用的 2–3 倍。
典型现象：两个应用各自压测都稳，合起来跑半天就 OOM；frankenphp_queue_depth 持续 > 10，但 frankenphp_busy_threads 却不上升，说明线程全被内存卡住，进不了执行队列。
实操建议：
- 共用容器时，
num_threads必须按“内存占用最高的那个应用”来反推，不能取平均 - OPcache 配置必须统一：
opcache.memory_consumption全局只设一个值（如 128），禁止各应用自己改 - 每个应用入口（
.frankenphp.router.php）里显式加载对应环境变量，避免框架自动加载冗余模块（如 WordPress 加载 Laravel 的 Service Provider）
线程数不是性能指标，而是内存锚点。FrankenPHP 容器里没设 mem_limit，或者 num_threads 没按实测常驻内存反推，其他所有调优都是在给 OOM Killer 打配合。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
