FrankenPHP压测不能轻信ab或wrk默认配置，因其基于嵌入式SAPI，HTTP/2、连接复用与PHP生命周期行为与传统FPM完全不同；应使用vegeta配合HTTP/2、响应体校验及status endpoint监控，并通过terminate()埋点和opcache.oom_restarts验证执行完整性。
FrankenPHP 跑 Laravel 压测，**不能直接信 ab（Apache Bench）或 wrk 的默认配置**——因为 FrankenPHP 是基于 SAPI 的嵌入式 PHP 运行时，不走传统 FPM + Nginx 架构，HTTP 层行为、连接复用、TLS 处理、请求生命周期都不同。压测工具若忽略这些差异，结果会严重失真。
为什么 ab 和 hey 在 FrankenPHP 上容易失真
ab 默认不支持 HTTP/2，而 FrankenPHP 启用 quic 或 http2 时，连接模型完全不同；它还会复用 PHP 进程生命周期，但 ab 每次请求都新建 CGI 上下文模拟，导致测的是“启动开销”而非真实吞吐。hey 虽支持 HTTP/2，但默认不校验响应体完整性，遇到 Laravel 中间件抛出的 500 或 JSON 格式错误时静默跳过，掩盖稳定性问题。
推荐用 vegeta + 自定义指标验证
vegeta 是目前对 FrankenPHP 最可信的 CLI 压测工具，原因有三：支持 HTTP/2/QUIC、可导出详细延迟分布、能用 -include-body 捕获响应体用于断言。关键不是跑高 QPS，而是验证「在持续负载下是否维持预期状态」：
- 用
vegeta attack -targets=targets.txt -rate=100 -duration=30s -http2 -include-body发起请求，其中targets.txt写GET http://localhost:8000/api/health - 用
vegeta report -type=json输出原始数据，检查latencies.95和errors字段——FrankenPHP 下常见错误是context deadline exceeded（超时），说明 PHP worker 队列阻塞，不是网络问题 - 配合
curl -s http://localhost:8000/fpm-status?json（需启用 FrankenPHP 的 status endpoint）实时看active_workers和queue_length，比单纯看 QPS 更反映真实瓶颈
必须补一手 Laravel 应用层埋点验证
FrankenPHP 的优势在于零 FPM 管理开销，但 Laravel 的 Kernel::terminate() 回调、队列监听、日志刷盘等异步行为，在压测中极易被忽略。光看 HTTP 响应码和延迟不够：
- 在
App\Http\Kernel的terminate()方法里加一行file_put_contents('/tmp/terminate.log', date('H:i:s') . "\n", FILE_APPEND);，压测后检查该文件行数是否 ≈ 请求总数——若明显偏少，说明 terminate 未执行，是 FrankenPHP 的 worker 生命周期或信号处理异常 - 禁用
opcache.validate_timestamps=0后压测，观察opcache_get_status()['opcache_statistics']['oom_restarts']是否增长——FrankenPHP 的内存预分配策略对 OPcache 缓冲区敏感，OOM 重启会导致冷启动抖动 - 避免用
php artisan serve对比——它和 FrankenPHP 的 SAPI 完全不同，无参考价值
terminate() 调用次数、opcache.oom_restarts 和 queue_length 的时间序列里。 
