FrankenPHP是Go编写的自包含PHP应用服务器，开箱即用支持HTTP/2/3、TLS；Swoole是PHP扩展，需Octane配合HTTP服务层及反向代理，二者在Octane中定位不同。
FrankenPHP 和 Swoole 在 Octane 里根本不是同一类东西
FrankenPHP 是一个完整的、自包含的 PHP 应用服务器（Go 编写），它把 Web 服务（HTTP/2/3、TLS、静态文件）和 PHP 执行环境打包进一个二进制；Swoole 是一个 PHP 扩展，提供常驻内存、协程、异步 I/O 能力，但本身不处理 HTTP 协议或 TLS，得靠 Octane 启动一个 HTTP 服务层来兜底。
这意味着：FrankenPHP 启动后就是一个“开箱即用的 Web 服务器”，vendor/bin/frankenphp 直接监听 80/443；而 Swoole 模式下 Octane 启动的是一个纯 PHP 的 HTTP 服务（类似内置 server），通常需前置 Nginx 或 Caddy 做反向代理和 HTTPS 终止——否则你得自己配 TLS 证书、处理 HTTP/2 升级逻辑。
常见错误现象：php artisan octane:start --server=swoole 启动后访问 127.0.0.1:8000 没响应？大概率是没配反代，或浏览器强制 HTTPS 但你没开 TLS。
Swoole 下 $_SERVER 是快照，FrankenPHP 下是动态更新的
Swoole 的常驻进程模型导致 $_SERVER 在首次请求初始化后就“冻结”，后续请求不会刷新 $_SERVER['REQUEST_URI']、$_SERVER['HTTPS'] 等字段；FrankenPHP（Worker 模式）虽也常驻，但它每次请求都重建 $_SERVER 数组（通过 Go 层注入），行为更接近 FPM。
立即学习“PHP免费学习笔记（深入）”；
所以你在 Swoole 下必须替换所有 $_SERVER 读取：
- 用
request()->fullUrl()替代$_SERVER['REQUEST_URI'] - 用
request()->secure()替代$_SERVER['HTTPS'] === 'on' - 避免在
bootstrap/app.php或服务提供者register()中依赖 Host 或 UA 做配置分支
而 FrankenPHP 下这些代码可以不动——但别因此掉以轻心：如果你开了 FrankenPHP 的非 Worker 模式（即传统 CGI-like 模式），$_SERVER 就是每次新建的，完全不用改；可一旦启用 Worker 模式，它的 $_SERVER 注入机制虽然动态，仍可能漏掉某些自定义 header，建议统一走 request() 对象。
队列、事件、定时任务都得单独跑，跟用哪个 server 无关
php artisan octane:start 只接管 HTTP 请求生命周期，不管队列、广播、schedule。这点在 Swoole 和 FrankenPHP 下完全一致，但新手容易误以为“Octane 启动了，队列就自动跑了”。
典型表现：
- 调用
dispatch(new SendEmailJob)后数据库 jobs 表有记录，但邮件一直不发 -
broadcast(new OrderPlaced)返回 true，但前端没收到 WebSocket 消息
解决方式只有一条：队列必须独立进程运行。推荐命令：
- Laravel 10+：
php artisan queue:listen（注意不是--daemon，该选项已废弃） - 生产环境用 Supervisor 或 systemd 管理
queue:listen进程 - 如果用了 Horizon，它会自动拉起 worker，但也要确认 Horizon 进程本身在运行
FrankenPHP 用户尤其要注意：它的二进制默认不启动任何子进程，queue:listen 必须显式执行，不能指望它“顺带”帮你干这事。
本地开发选 FrankenPHP，高 IO 并发压测慎选 Swoole
FrankenPHP 安装即用：php artisan octane:install --server=frankenphp，无扩展依赖，PHP ≥ 8.1 就行；Swoole 需先装扩展（ZTS 版本）、确认线程安全、处理 pcntl 权限，Windows 用户还得走 WSL2。
但性能不是线性关系：压测数据显示，在纯 CPU 密集型场景（如大量数组计算、模板渲染），FrankenPHP 可达 3500 QPS；而在高并发 IO 场景（如同时查 10 个外部 API），Swoole 协程调度优势明显，TrueAsync 测试中甚至比 Octane+Swoole 高出 64% 吞吐量——但这建立在你真正用上了 Co::sleep、Co\Http\Client 等原生协程 API 的前提下。
多数 Laravel 项目没重写底层 HTTP 客户端，只是开了 Octane + Swoole，结果就是“看似异步，实则阻塞”，这时 FrankenPHP 的稳定性和调试友好性反而更实用。真正的瓶颈往往不在 server 选型，而在是否把 DB 查询、Redis 调用、第三方 API 全部切到协程驱动——而这一步，Swoole 提供了路径，FrankenPHP 目前还不支持。
