FrankenPHP通过常驻worker模式降低CPU开销，但高CPU多因OPcache未调优、worker数量失当、I/O阻塞或框架启动过重；需检查opcache命中率≥95%、worker数设为CPU核数1–1.5倍、关闭hot_reload、精简中间件并预热配置。
FrankenPHP 本身设计目标就是降低传统 PHP-FPM 的 CPU 开销，但如果运行时 CPU 占用仍偏高，说明瓶颈不在架构层面，而在配置、代码或资源协同上。它不像 PHP-FPM 那样有独立的进程池和冷启动开销，但常驻 worker 模式下，问题会更“聚焦”——比如某段代码在长生命周期里反复执行、OPcache未生效、或 I/O 等待被误判为 CPU 消耗。
检查 OPcache 是否真正启用并调优
FrankenPHP 默认启用 OPcache，但默认参数对中大型项目严重不足。若没调，等于裸跑 PHP，每次请求都重编译脚本，CPU 直接拉满。
-
确认已启用：运行
frankenphp -i | grep opcache，确保opcache.enable => On且opcache.huge_code_pages => Off（开启 huge pages 需内核支持，否则反而降速） -
调大内存与文件数：在
php.ini或 FrankenPHP 的php: ini_path指向的配置中设置：opcache.memory_consumption=256opcache.max_accelerated_files=20000opcache.revalidate_freq=60（生产环境别设为 0） -
验证效果：压测前后对比
opcache_get_status()['opcache_statistics']['opcache_hit_rate']，命中率应稳定在 95%+；低于 85% 就说明缓存没兜住
合理设置 worker 数量与生命周期
FrankenPHP 的 workers.count 不是“越多越好”。每个 worker 是常驻的 Go goroutine + PHP 执行上下文，过载会导致上下文切换激增、GC 压力变大，反推高 CPU。
- 数量建议：设为服务器逻辑 CPU 核数的 1–1.5 倍（例如 8 核设 8–12），避免超过物理核心数太多
-
限制单 worker 请求上限：通过
max_requests（如 1000–5000）主动回收 worker，防内存碎片和隐性泄漏累积导致的 CPU 持续爬升 -
禁用 hot_reload：开发阶段可开，生产务必关掉（
features: hot_reload: false），否则文件监控和重载逻辑会持续占用 CPU
排查阻塞型 I/O 和锁竞争
FrankenPHP 进程显示高 CPU，但实际可能卡在 MySQL 查询、Redis 等待、或文件句柄未关闭上。Linux top 的 %CPU 是采样值，容易误判。
立即学习“PHP免费学习笔记（深入）”；
-
换工具看本质：用
pidstat -u -w -d 1替代 top，重点观察：
—cswch/s（上下文切换）＞10k？→ worker 数过多或协程调度不均
—await（磁盘等待）＞10ms？→ 查慢 SQL、Redis 连接池耗尽、或fopen()日志未 fclose -
查数据库瓶颈：对高频接口开启 Laravel 的
DB::listen()或直接抓 slow log，警惕type=ALL全表扫描、N+1 查询（如循环里查关联表） -
检查扩展行为：GD、Imagick 等图像处理扩展在常驻模式下容易累积内存和 CPU，非必要不加载；确认
extension=gd.so等在 php.ini 中仅按需启用
精简框架启动与中间件链
传统 FPM 每次请求都重建容器，而 FrankenPHP 的 worker 是复用的——这本是优势，但若框架初始化逻辑重（如 Laravel 加载上百个服务提供者、扫描目录、解析大量 YAML），这些操作只做一次，却把 CPU 压力集中在启动瞬间，后续请求虽快，但启动卡顿会影响整体吞吐。
-
延迟加载非关键服务：在
config/app.php中将非核心中间件（如调试工具、日志钩子）移出默认栈，按需注册 -
预热关键类：利用 FrankenPHP 的
on_start钩子（若支持）或首次请求前执行一次php artisan config:cache、route:cache，把解析开销前置 -
关闭开发功能：确保
APP_DEBUG=false、debugbar未启用、异常堆栈不渲染全路径——这些在常驻进程中会持续消耗 CPU
