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 测试容易误判“跑通了”,其实只是单次请求侥幸成功。
- 入口脚本(如
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()了
php免费学习视频:立即使用
踏上前端学习之旅,开启通往精通之路!从前端基础到项目实战,循序渐进,一步一个脚印,迈向巅峰!











