FrankenPHP已是生产可用的现在时，其worker模式让PHP进程常驻内存，复用类加载、服务注册和数据库连接池，大幅削减请求初始化开销；内置Caddy原生支持HTTP/3与自动HTTPS，协议栈层面重构部署；Go扩展机制可实现真正并行异步调用，突破PHP传统并发瓶颈。
FrankenPHP 不是 PHP 的“未来”——它已经是生产可用的现在时。如果你还在用 nginx + php-fpm 部署 Laravel 或 WordPress，而没试过 frankenphp php-server 一行启动，那不是技术选型问题，是部署惯性在拖后腿。
worker 模式到底省了什么？不是“快一点”，而是砍掉整个生命周期
传统 PHP-FPM 每个请求都要：加载 composer/autoload.php → 初始化框架容器 → 建 DB 连接 → 解析路由 → 执行中间件 → 渲染响应 → 销毁全部对象。这个过程在 Laravel 上常耗 30–60ms，纯框架开销。
FrankenPHP 的 worker 模式让 PHP 进程常驻内存，只在首次请求时执行完整初始化；后续请求复用已加载的类、已注册的服务、已建立的连接池（需配合 PDO::ATTR_PERSISTENT）。
- 必须显式启用：
frankenphp php-server --worker，不加--worker默认走classic模式（行为接近 FPM） - 框架需支持“请求间状态隔离”：Laravel 8+、Symfony 6+ 原生兼容；ThinkPHP 6 需关闭
APP_DEBUG并禁用运行时缓存重载 - 全局变量、静态属性不会自动清空——
$_SESSION、static::$cache会跨请求残留，这是最容易踩的坑
Caddy 内置 Web 服务器 ≠ 简单替代 Nginx，而是协议栈重定义
很多人以为换 frankenphp 就是把 nginx.conf 改成 Caddyfile，其实错在底层：Caddy 是 HTTP/3 原生支持者，而 Nginx 目前仍需打补丁或依赖 QUIC 试验版。
立即学习“PHP免费学习笔记（深入）”；
这意味着：
- 无需配置
ssl_certificate和ssl_certificate_key—— Caddy 自动申请 Let’s Encrypt 证书并续期 -
HTTP/2 Server Push和HTTP/3 DATAGRAM可直接用于资源预加载，Nginx 无法原生支持后者 - 静态文件服务由 Caddy 直接处理，PHP worker 不参与；但若在 PHP 中用
readfile()输出大文件，会阻塞 worker，应改用http.ServeFile或 Caddy 的file_server指令
用 Go 写 PHP 扩展不是炫技，而是解决真实并发瓶颈
当你需要在 PHP 中调用一个耗时 500ms 的外部 API，又不想阻塞整个请求，传统方案只能上消息队列或 Swoole 协程——但这两者都要求重构业务逻辑。
FrankenPHP 提供的 Go 扩展机制允许你写一个 go_http_get_async() 函数，内部用 goroutine 发起请求，再通过 channel 回传结果，PHP 层只需：
$ch = go_http_get_async("https://api.example.com/data");
// 继续做其他事
$data = go_wait($ch);关键限制在于：
- Go 函数必须用
//export注释导出，且参数/返回值仅支持基本类型（int、*C.char、uintptr），复杂结构需 JSON 序列化中转 - 扩展编译依赖
CGO_ENABLED=1，不能在 Alpine 的 musl 环境下直接构建，推荐用debian:slim基础镜像 - PHP 调用 Go 函数时，GIL 不生效——Go 的 goroutine 是真正并行的，但也要小心竞态：比如多个请求同时写同一个
mmap共享内存区域
真正的复杂点不在安装或配置，而在于你是否愿意重新思考“PHP 请求”的边界：它不再是一次性脚本执行，而是一个长期存活、可跨请求共享、能被 Go 协程穿透的运行时环境。习惯它，比学会命令更重要。
