提升FrankenPHP worker模式并发能力的核心是让每个worker轻装上阵、不卡不堵、复用到位，须优先设定合理线程与worker数、启用并验证OPcache及持久连接、严防锁与资源泄漏；默认CPU核数×2易致OOM，应按内存反推num_threads×memory_limit＜可用内存−2GB，首次压测从4起步，OPcache必须生效（php -i输出On），MySQL max_connections需≥num_threads×连接池大小×1.5，日志用RotatingFileHandler，所有资源操作须有明确close/unset路径。
提升 FrankenPHP worker 模式下的并发处理能力，核心不是堆线程或加核，而是让每个常驻 worker 真正“轻装上阵、不卡不堵、复用到位”。关键动作集中在三块：线程与 worker 数量合理设定、OPcache 和连接池必须显式启用并验证生效、避免锁和资源泄漏拖垮全局。
先稳住底座：调对 num_threads 和 worker.num
默认值（CPU 核数 × 2）在多数业务场景下会直接导致 OOM 或响应抖动。必须按内存反推：
- 实测单请求峰值内存：在 worker 入口加
memory_get_peak_usage(true)，别只看memory_limit配置值 - 确保
num_threads × memory_limit < 可用内存 − 2GB（留出系统与 OPcache 缓存余量） - 首次压测建议从
num_threads 4或worker.num 4起步，观察oom_count是否为 0、opcache_get_status()['memory_usage']['used_memory']是否稳定 -
max_threads设为num_threads + 4即可，不是越大越好——自动扩容会加剧 GC 和上下文切换开销
必须启用并验证 OPcache 和持久连接
worker 模式下这两项若未生效，高并发等于裸奔：
- 执行
php -i | grep "opcache.enabled"，输出必须是 On（不是 1 或 true），否则每个请求重编译全部文件，CPU 飙满但 QPS 断崖下跌 - 修改 php.ini 后必须重启 FrankenPHP 进程（
docker restart或kill -SIGUSR2），仅 reload Caddy 不生效 - Symfony/Laravel 必须在 Doctrine 配置中显式写死：
pdo::ATTR_PERSISTENT: true，同时禁用doctrine.dbal.auto_close - MySQL 的
max_connections至少设为num_threads × 连接池大小 × 1.5（例如 8 个 worker × 5 连接 = 40，建议 MySQL 设为 60 起步）
防住隐性瓶颈：锁、句柄、I/O 阻塞
这些不报错，但会让第 53 个并发开始明显变慢：
立即学习“PHP免费学习笔记（深入）”；
- 文件锁必须用非阻塞模式：
flock($fp, LOCK_EX | LOCK_NB)，失败后最多重试 3 次、总等待 ≤100ms，超时返回 503 - 锁粒度下沉到业务键，如
storage/locks/inventory_123.lock，避免全局锁争用 - 日志必须用
RotatingFileHandler，禁用StreamHandler；所有curl_init()、new PDO()、fopen()都要有明确的close/unset路径 - 外部调用强制加硬超时：
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 2000)，禁用CURLOPT_RETURNTRANSFER以外的阻塞行为
上线前必做两件事
部署脚本末尾必须包含：
- 调用
opcache_reset()的健康检查端点（不能用opcache_invalidate()逐文件清理，worker 多进程下会导致新旧逻辑混跑） - 用
netstat -an | grep :3306 | wc -l和lsof -p $(pgrep -f frankenphp) | wc -l持续观察连接数与文件句柄增长趋势，缓慢上涨就是泄漏信号
