1核2G能跑通FrankenPHP但非推荐配置，需将workers设为1、禁用hot_reload和非必要扩展、收紧OPcache、关闭HTTP/3与自动HTTPS、禁用日志，并规范PHP代码避免协议误判和耗时注册。
完全带得动，但必须关掉默认的 workers 模式、禁用不必要的扩展、并严格限制并发连接数。1核2G 不是 FrankenPHP 的推荐配置，但它是能跑通生产流量的底线——前提是别把它当 Nginx+PHP-FPM 那样惯着用。
为什么 1 核 2G 能跑 FrankenPHP，但不能照搬默认配置
FrankenPHP 默认启动 4 个 PHP worker（workers.count: 4），每个 worker 占用约 30–50MB 内存（含 OPcache、框架类加载缓存等）。4 个就是 120–200MB，看起来不多，但加上 Caddy 自身、系统预留、MySQL/Redis 进程，2G 内存很快见底。更关键的是：1 个 CPU 核心根本调度不过来 4 个常驻 PHP 线程，上下文切换开销反而拖慢响应。
常见错误现象：frankenphp 启动后内存持续上涨到 1.8G+、top 显示 %CPU 长期 95%+、HTTP 请求开始超时或返回 502。
- 必须把
workers.count改成1或2（推荐1） - 关闭
hot_reload: true（开发功能，生产无意义且吃内存） - 禁用非必要 PHP 扩展，比如
gd、imagick、soap；只留opcache、pdo_mysql、mbstring - OPcache 配置要收紧：
opcache.memory_consumption=64（不是 128 或 256）
Caddyfile 里必须砍掉的功能
小服务器上，Caddy 的“全自动”特性反而是负担。自动 HTTPS、HTTP/3、Mercure 推送这些功能在 1 核 2G 上会显著增加 TLS 握手和协议协商开销。
立即学习“PHP免费学习笔记（深入）”；
正确做法是手动管理证书（用 certbot 获取后静态挂载），并显式禁用 HTTP/3 和 Mercure：
{
# 关掉 metrics（监控端口也占资源）
servers {
metrics off
}
}
<p>your-domain.com {<br />
tls /data/certs/fullchain.pem /data/certs/privkey.pem </p><h1>显式禁用 HTTP/3</h1><p>@http3 {<br />
header Connection <em>h3</em><br />
}<br />
handle @http3 {<br />
respond "HTTP/3 disabled" 404<br />
} </p><h1>PHP 路由只走最小路径</h1><p>php_backend {<br />
php </p><h1>不加任何额外中间件或重写</h1><p>}<br />
}注意：php 指令本身已启用 classic 模式；如果硬要用 worker 模式，必须配 php_worker 并确保入口文件包裹了 frankenphp_handle_request()，但 1 核下 worker 模式收益极低，还更容易 OOM。
PHP 应用层必须做的三件事
FrankenPHP 在小机器上能不能稳，70% 取决于 PHP 代码是否“守规矩”。Laravel/Symfony 项目最容易踩坑的地方有三个：
-
$_SERVER直接读取必须改掉：比如判断 HTTPS 不能用$_SERVER['HTTPS'] === 'on'，得用request()->secure()；否则在复用 worker 时会错判协议 - 避免在
AppServiceProvider::register()里做耗时操作（如远程配置拉取、数据库查询），worker 常驻后这些代码只执行一次，后续请求全靠缓存，出错难排查 - 队列必须单独起进程：
php artisan queue:work --once配合supervisor，不能指望 FrankenPHP 自己管队列——它只处理 HTTP 请求
真正容易被忽略的点是：FrankenPHP 的日志默认全开，error_log 和 access_log 在小内存机器上会快速打满磁盘并拖慢 I/O。务必在 php.ini 里设 log_errors = Off，线上只保留 error_log = /dev/null；Caddy 的访问日志也必须关掉（log { output stdout } 改成注释或删掉）。
