docker image inspect 用于显示一个或多个镜像的详细信息，支持镜像名称、标签、id或digest引用，可选 -f 自定义格式输出及 --platform 指定多平台检查（需api v1.49）。
确认 FrankenPHP 容器是否真被 OOMKilled
别急着查 PHP 配置，先看事实：退出码 137 且 OOMKilled 字段为 true 才是实锤。否则可能是宿主机全局 OOM、节点驱逐或信号误杀。
执行：docker inspect frankenphp-container-id | grep -A 5 "State"，盯住两行：
"OOMKilled": true"ExitCode": 137
如果其中任一为 false 或缺失，问题不在容器内存限制内，得去 dmesg -T 里翻宿主机级的 Killed process 记录。
FrankenPHP 的内存消耗特殊在哪
它不是传统 PHP-FPM —— 没有 master/worker 进程模型，而是基于 Swoole 或原生 Go HTTP server 启动单进程（常为 frankenphp 二进制本身），所有请求在同一个进程中处理。这意味着：
- 没有
pm.max_children这类缓冲机制，单个进程 RSS 会随并发请求线性增长（尤其带大文件上传、OPcache 失效、或未关闭的curl_multi句柄） - Go runtime 自身内存管理（如
runtime.mheap）和 PHP 堆外分配（malloc、GD 库、FFI 调用）都计入容器总内存，但完全不体现在memory_get_usage()中 - 默认不读取 cgroup limit，
memory_limitini 设置只管 PHP 堆，不管 Go runtime 和底层 C 分配
所以即使 phpinfo() 显示内存只用了 20MB，docker stats 里 RSS 可能已飙到 1.8GB —— 这就是被杀的真相。
快速抓取真实内存占用和触发点
不要等下次崩溃。现在就运行这三组命令，顺序不能错：
- 查当前内存水位：
docker stats --no-stream --format "{{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}" frankenphp-container-id - 进容器看 Go runtime 实际用量：
docker exec frankenphp-container-id cat /proc/$(pgrep frankenphp)/smaps | awk '/^Rss:/ {sum += $2} END {print sum/1024 " MB"}' - 同步查内核 OOM 时间锚点：
timestamp=$(dmesg -T | grep -i "killed process" | grep frankenphp | tail -1 | cut -d']' -f1 | sed 's/^\[ *//')，再用docker ps -a --since "$timestamp-60s" --until "$timestamp+60s"确认是不是它
注意：/proc/*/smaps 输出里的 Rss: 是真实物理内存占用，比 MemUsage 更准；而 MemPerc 如果接近 100%，基本可判定是它。
关键配置与修复动作
FrankenPHP 的 OOM 往往卡在三个地方，按优先级修复：
-
禁用 OPcache 文件检查：设
opcache.validate_timestamps=0（开发环境除外），否则每个请求都stat()所有 PHP 文件，高频 IO 触发 Go runtime 内存抖动 -
限制上传大小并清理临时文件：在
frankenphp.yaml或php.ini中设upload_max_filesize=8M、post_max_size=10M，并在请求结束时显式unlink($_FILES['x']['tmp_name']) -
强制 Go runtime 尊重 cgroup：启动时加环境变量
GODEBUG=madvdontneed=1（Linux 5.15+），并确保容器运行时启用--memory且内核支持 cgroups v2（FrankenPHP 0.9+ 默认依赖 v2）
最易被忽略的是最后一点：很多旧版 Kubernetes 节点仍用 cgroups v1，FrankenPHP 在 v1 下无法感知 memory limit，Go 会按宿主机内存分配 heap —— 此时哪怕容器只设了 512Mi，它也可能吃掉 4GB 后被杀。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
