curl测试需先明确启动模式：frankenphp run依Caddyfile路由控制，静态文件直送、PHP请求走php_server；frankenphp php-server则所有请求强制交PHP解析，无区分逻辑。
curl 测试时如何区分静态文件和 PHP 脚本响应
FrankenPHP 本身不按文件后缀“自动切换模式”，而是由 Caddy 的路由规则或 php_server 指令显式控制——所以测试前必须清楚当前是用 frankenphp run（走 Caddyfile）还是 frankenphp php-server（无配置、默认全 PHP）。否则你 curl 的结果可能根本不是你预期的处理路径。
- 用
frankenphp php-server启动时：所有请求都交给 PHP 解析，index.html也会被当成 PHP 执行（若没报错就输出原内容，但<?php不会被解析） - 用
frankenphp run启动时：行为完全取决于 Caddyfile —— 若没配php_server，.php文件会返回 404 或直接下载；若配了但没写try_files，静态资源可能被错误转发给 PHP - 关键看响应头：
Content-Type: text/html+Server: FrankenPHP是基础达标；若还看到X-Powered-By: PHP/8.x，说明 PHP 确实参与了输出（哪怕只是 echo 了 HTML）
验证静态请求是否真由 Caddy 直接服务
静态请求不该触发 PHP 解析器，否则会浪费 CPU、绕过缓存、甚至暴露源码（比如访问 /config.php 本该 404，却意外执行了它）。
- 放一个纯文本文件
hello.txt在文档根目录（如public/hello.txt），内容为static ok - 执行：
curl -I http://localhost:8000/hello.txt，检查响应头：- 状态码必须是
200（不是500或404） -
Content-Type应为text/plain; charset=utf-8（不是text/html） - 不应出现
X-Powered-By或PHP相关 header
- 状态码必须是
- 再试一个不存在的路径：
curl -I http://localhost:8000/missing.css，应返回404，且响应体为空或只有默认 Caddy 404 页面 —— 如果返回了 PHP 的错误堆栈，说明php_server把所有路径都 fallback 到了index.php，配置太宽泛
确认 PHP 请求是否进入正确执行流程
不能只看 echo "ok" 有输出，还要排除“PHP 进程没启动”“脚本被当静态文件返回源码”“入口路径错位导致 404”这三类典型假阳性。
- 在文档根下放
info.php，内容为<?php phpinfo(); ?> - 用
curl -s http://localhost:8000/info.php | head -20，确认输出里有<title>PHP Version</title>，而非原始 PHP 代码 - 如果返回的是纯文本
<?php phpinfo(); ?>，说明：- 你用的是
php-server但文件不在当前目录（它不递归找） - 或用的是
run但 Caddyfile 里漏了php_server块，或root指向了错误目录
- 你用的是
- 加
-v看完整交互：curl -v http://localhost:8000/info.php 2>&1 | grep -E "(HTTP/|Server:|X-Powered-By)"，重点确认Server: FrankenPHP出现在响应头里 —— 这能排除本地 Nginx/Apache 拦截了请求
worker 模式下 PHP 请求的特殊验证点
worker 模式不走传统 CGI 流程，$_SERVER 变量、请求生命周期、甚至 exit() 行为都不同。普通 curl 测试容易误判“跑通了”，其实只是单次请求侥幸成功。
立即学习“PHP免费学习笔记（深入）”；
- 入口脚本（如
public/index.php）必须包裹frankenphp_handle_request()循环，否则第二次请求就会失败 - 测试时别只发一次：
for i in {1..3}; do curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8000/; done，连续三次都返回200才算稳定 - 观察进程是否常驻：
ps aux | grep frankenphp，worker 模式下主进程应一直存在，且子进程数不会随请求数线性增长（区别于 php-server 的 per-request fork） - 如果第二次请求卡住或返回空，大概率是你的
$handler回调里漏了$http->end($response)或提前exit()了
