FrankenPHP高并发调优须先确保opcache.enable=1生效、worker模式启用、线程数按内存约束合理设置（如num_threads×memory_limit＜可用内存－2GB），三者未对齐则其他优化无效；部署后必须opcache_reset()或重启，否则新代码不执行。
FrankenPHP 高并发场景下，别一上来就调 opcache.max_accelerated_files 或改 Caddyfile 里一堆嵌套配置——先稳住底座：线程数、Worker 数、OPcache 启用状态这三项不设对，其他优化全白搭。
确认 opcache.enable=1 且生效
worker 模式下若 opcache.enable=0，每个请求都会重新编译全部 PHP 文件，CPU 直接飙满，QPS 断崖下跌。这不是性能“差”，是根本没走缓存路径。
- 进容器执行
php -i | grep "opcache.enabled"，输出必须是On（不是 1 或 true） - 若为
Off，检查是否被php.ini中其他位置的opcache.enable=0覆盖（常见于多 ini 文件加载顺序） - 修改后必须重启 FrankenPHP 进程（
docker restart或kill -SIGUSR2），仅 reload Caddy 不生效
按内存上限反推 num_threads 和 worker.num
FrankenPHP 默认启动 CPU 核心数 × 2 个线程，但这个值在 8GB 内存的机器上跑 Laravel 可能直接 OOM——因为每个线程默认受 memory_limit=128M 约束，16 × 128M = 2GB 已占去四分之一，再叠加 OPcache、Composer autoload、框架实例，极易触发系统 kill。
- 先算硬约束：
num_threads × memory_limit必须 小于 服务器可用内存（建议留 2GB 余量） - 若用
php_server指令，加num_threads 4；若用frankenphp全局块中的worker，则设num 4 - 首次调优建议从 4 开始压测（哪怕你有 16 核），观察
oom_count是否归零、opcache_get_status()['memory_usage']['used_memory']是否稳定
部署后必须调用 opcache_reset() 或重启
worker 进程常驻，OPcache 不会自动感知文件变更。发版后若只替换 PHP 文件而不重置缓存，新代码根本不会执行——它还在跑旧字节码。
立即学习“PHP免费学习笔记（深入）”；
- 不要用
opcache_invalidate()逐文件清理：worker 模式下不同请求可能命中不同进程，导致部分请求跑新逻辑、部分跑旧逻辑，数据不一致 - 推荐在部署脚本末尾 curl 一个健康检查端点，该端点内调用
opcache_reset()并返回状态 - 若用 CI/CD 自动部署，确保该步骤失败时整个发布中断，而不是静默跳过
最容易被忽略的是：Symfony/Laravel 这类框架在 worker 模式下，$_SERVER 和数据库连接池的状态残留比 OPcache 失效更隐蔽——它们不会报错，只会让第 53 个并发请求开始变慢、超时、卡死。参数调得再细，不配合框架层的请求隔离，高并发就是纸糊的墙。
