最直接证据是访问/metrics端点验证指标：frankenphp_threads_total应等于num_threads配置值，frankenphp_workers_total对应worker数，frankenphp_threads_busy随请求上升；需先启用prometheus指令，否则404。
查 /metrics 端点看实时线程数是否匹配配置
FrankenPHP 的线程配置是否生效，最直接的证据不是 Caddyfile 里写了什么，而是运行时暴露的指标。必须先在 Caddyfile 中启用 prometheus 指令，否则 /metrics 返回 404。
访问 http://localhost:2019/metrics（默认端口），搜索以下指标：
-
frankenphp_threads_total：应等于你配置的num_threads值（或auto推导出的值） -
frankenphp_workers_total：若启用了 worker 模式，该值应等于frankenphp { worker { num X } }中的num -
frankenphp_threads_busy：初始应为 0，发起请求后缓慢上升，证明线程确实在被调度
如果 frankenphp_threads_total 明显小于预期（比如配了 8 却只显示 4），常见原因有：num_threads 写在了错误区块（如放在 php_server 块内而非顶层 frankenphp 块）、Caddy 未重载配置、或系统资源限制（ulimit -u 限制了进程内线程数）。
用 ps 和 htop 看真实线程数量
指标可能缓存或延迟，最终裁决得看 OS 层面的线程实体。FrankenPHP 主进程本身是 Go 程序，它拉起的 PHP 线程会以子线程形式存在，不是独立进程。
立即学习“PHP免费学习笔记（深入）”；
执行：ps -T -p $(pgrep -f frankenphp) | wc -l
结果减去 1（主 goroutine），就是当前活跃的 PHP 线程数。注意：ps 默认不显示线程，必须加 -T；若返回 0，说明没找到 FrankenPHP 进程，可能是 Caddy 启动失败或没加载 frankenphp 模块。
更直观的方式是：htop -p $(pgrep -f frankenphp)
然后按 H 切换线程视图，观察线程状态列（STATE）：大量 S（sleep）是正常等待请求，大量 R（running）说明 CPU 密集型负载已起量。
验证 num_threads auto 是否真按 CPU 核心数推导
num_threads auto 不是魔法，它由 FrankenPHP 的 Go 层调用 runtime.NumCPU() 获取逻辑核心数，再乘以 2。但这个值可能被容器环境欺骗——比如 Docker 限制了 --cpus=2，但 /proc/cpuinfo 仍显示宿主机 64 核。
确认方式：frankenphp -v 输出末尾会打印类似 Using 8 PHP threads (auto mode, 4 cores detected) 的提示。
若没看到，说明启动时没读到配置，或 frankenphp 模块根本没加载成功。
更底层验证：cat /proc/$(pgrep -f frankenphp)/status | grep -i "threads:"
该值应 ≈ frankenphp_threads_total + 若干 Go runtime 线程（通常 5–10 个）。若远大于前者，说明 Go 层有 goroutine 泄漏，不是 PHP 线程配置问题。
压测时观察 frankenphp_queue_depth 是否随线程数变化
线程数是否“有效”，最终体现在排队能力上。用 wrk -t4 -c200 -d10s http://localhost/health 压一个轻量接口，同时刷新 /metrics。
对比不同 num_threads 配置下的表现：
- 设为 2：压测中
frankenphp_queue_depth持续 > 50，frankenphp_threads_busy长期为 2 → 线程池彻底打满 - 设为 8：同一压测下
queue_depth大部分时间 = 0，threads_busy在 3–7 波动 → 线程扩容生效
注意：如果增大 num_threads 后 queue_depth 无改善，问题大概率不在线程数，而在下游阻塞（如数据库连接池耗尽、curl 无超时），此时线程只是“空闲地等”，不是“没线程可用”。
真正容易被忽略的是：FrankenPHP 的线程池一旦启动，就不会动态缩容。即使流量归零，frankenphp_threads_total 也始终是配置值。所以“生效”不等于“智能”，它只是忠实地按配置拉起固定数量的线程并长期持有——你要确保这个数字既够用，又不至于吃光内存。
