FrankenPHP线上必须用systemd管理，service文件需设Type=simple、Restart=always、MemoryMax=1G、MemoryLow=256M，并配置StandardOutput/Error日志路径，禁用--worker用于Web服务，worker应单独建service。
怎么写 frankenphp.service 文件
FrankenPHP 本身是单二进制，但线上必须用 systemd 管理生命周期、日志、内存和重启策略。直接 ./frankenphp 启动只适合本地验证，线上会丢进程、无日志归档、OOM 时被 kernel 杀掉也不通知。
关键点不是“能不能跑”，而是“崩溃后能否自动拉起”“内存爆了会不会被杀”“日志写满磁盘怎么办”。systemd 是唯一能统一兜住这三件事的方案。
-
ExecStart必须用绝对路径，例如/opt/frankenphp/frankenphp；别用~/frankenphp或./frankenphp，systemd 不认 shell 展开 - Web 模式下加
--worker是错的——那是后台常驻脚本模式；线上 Web 服务该用--server（默认行为），否则 Caddy HTTP 路由不生效 - 推荐显式指定
--addr :8000（或 Unix socket 路径），避免端口冲突或绑定失败静默退出 -
Type=notify不适用：FrankenPHP 没实现 systemd notify 协议；改用Type=simple，并配Restart=always和RestartSec=5
怎么限制内存防止 OOM Killer 杀进程
FrankenPHP 进程吃内存很实在：每个 PHP 线程都带完整 Zend 引擎，memory_limit 设 512M，10 个线程就占 5G。systemd 的 MemoryMax 是硬隔离手段，比 PHP 层面的配置更早生效。
在 service 文件的 [Service] 段加：
立即学习“PHP免费学习笔记（深入）”；
MemoryMax=1G MemoryLow=256M
这两行让内核在内存紧张时优先回收 FrankenPHP 的 page cache，而不是等它 malloc 失败后直接触发 OOM Killer。实测中，没加这俩参数的服务在流量突增时大概率被 Killed process，加了之后只会变慢、不会挂。
- 别只设
MemoryMax：单独设它会导致进程被 abrupt kill，MemoryLow才是柔性降级的关键 - 值要留余量：如果服务器总内存 4G，别把
MemoryMax设成 3.8G，预留至少 512M 给系统和其他进程 - 容器环境注意：Docker/Kubernetes 里也得在 cgroup 层设限，systemd 的 MemoryMax 不会穿透容器边界
日志怎么切分才不丢数据
FrankenPHP 自身不轮转日志，Caddy 也只支持简单 roll（v2.8+），但生产环境必须按天/按大小切、压缩、保留份数、清空时不中断写入。logrotate 是唯一靠谱选择。
使用 Kadence 主题作为 WordPress 项目的设计系统，涵盖设计令牌、布局系统、页头/页脚/导航设置以及页面/归档/单篇文章模板。
先确保 service 文件里日志输出路径明确：
StandardOutput=append:/var/log/frankenphp/access.log StandardError=append:/var/log/frankenphp/error.log
再配 /etc/logrotate.d/frankenphp：
/var/log/frankenphp/*.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 644 www-data www-data
copytruncate
}
-
copytruncate是核心：先拷贝再清空原文件，FrankenPHP 不需要 reload 或 reopen fd - 别信 Caddyfile 里的
log { roll 100MB }：它不支持postrotate，高并发下容易丢最后几条日志 - 权限要对：Ubuntu/Debian 用
www-data，CentOS/RHEL 改成apache或nginx，否则create失败导致后续轮转卡住
worker 模式要不要放进同一个 service
不要。FrankenPHP 的 --worker 模式本质是启动一个长期运行的 PHP 脚本（如队列监听），它和 Web 服务完全无关，也不共享任何状态。把它和 Web 实例塞进同一个 systemd service，等于把两个不同生命周期、不同资源模型、不同故障域的东西强行绑在一起。
正确做法是拆成两个 service：
-
frankenphp-web.service：只跑--server，监听 HTTP 端口，处理请求 -
frankenphp-worker-queue.service：只跑--worker --script /var/www/app/queue.php，绑定独立端口或不监听端口
它们之间不能通信，也不能互相影响——这是设计使然，不是缺陷。想让 Web 请求触发 worker 逻辑？走 Redis pub/sub、HTTP API 或数据库轮询，别试图在 queue.php 里 include index.php，那会破坏进程隔离，导致内存泄漏和信号处理异常。
真正容易被忽略的是：每个 worker service 都要单独配 MemoryMax 和 logrotate。两个实例，就是两份内存上限、两套日志路径、两个独立的崩溃恢复周期。
