单个frankenphp worker真实内存开销远超memory_limit，因其包含opcache、框架类加载、扩展静态数据及go运行时开销，通常为memory_limit的1.5–2.5倍；memory_get_usage(true)比memory_limit更准，因它返回实际堆内存字节数（含预留块），而memory_limit仅为触发错误的软限制，不反映真实rss。
怎么估算单个 FrankenPHP Worker 的真实内存开销
不能只看 memory_limit，它只是 PHP 请求层的软限制；Worker 的实际内存占用 = OPcache 占用 + 框架类加载常驻内存 + 扩展静态数据 + Go 运行时开销，通常比 memory_limit 高 1.5–2.5 倍。
为什么 memory_get_usage(true) 比 memory_limit 更准
memory_get_usage(true) 返回当前分配的**实际堆内存字节数**（含未使用的预留块），而 memory_limit 是 ini 配置项，仅用于触发 fatal error，不反映真实 RSS。在 worker 模式下，框架初始化后这部分内存会长期驻留。
- 在 Symfony/Laravel 入口脚本末尾加：
error_log('RSS: ' . memory_get_usage(true)); - 用
curl -s http://localhost/ | grep RSS抓日志，多刷几次取稳定值（排除首次 autoload 波动） - 对比
cat /proc/$(pgrep -f frankenphp)/status | grep VmRSS，若两者差值
OPcache 和扩展对 Worker 内存的影响有多大
OPcache 启用后，每个 Worker 会独占一份 opcode 缓存和字符串表；gd、imagick 等扩展自带大块静态缓冲区，即使没调用也会提前分配。
- 关闭非必要扩展：禁用
gd、imagick、soap、xmlrpc，只留opcache、pdo_mysql、mbstring - 收紧 OPcache：
opcache.memory_consumption=64（不是 128），opcache.interned_strings_buffer=8 - 验证效果：改完重启后执行
php -r "echo opcache_get_status()['memory_usage']['used_memory'];"，应 ≤ 50MB
容器环境下必须叠加线程数来算总内存
Docker 的 --memory 或 Kubernetes 的 resources.limits.memory 控制的是整个容器 cgroup 总量，FrankenPHP 多线程共享这个边界。一个 num_threads 4 的实例，哪怕每个 Worker 平均只占 35MB，总 RSS 也容易突破 160MB —— 这还没算 Caddy 自身和系统开销。
- 公式：预估总内存 ≈
num_threads × (memory_get_usage(true) + 10MB)（+10MB 是 Go runtime 和 PHP SAPI 层开销） - 实测参考：Laravel + OPcache + MySQL PDO，在
num_threads 2下，memory_get_usage(true)稳定在 28–32MB → 容器建议设--memory=256M - 关键提醒：别信
docker stats显示的“MEM USAGE”，它包含缓存页；要看VmRSS或 Prometheus 的process_resident_memory_bytes
num_threads 和 workers.count 混用造成线程数翻倍——这两个点一错，内存估算就全偏了。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
