memory_limit必须与容器内存限制、线程数、应用类型三者对齐，否则易触发oom killer；frankenphp中它限制单请求内存而非进程总内存，cli模式下则约束常驻进程堆上限。
memory_limit 不是单设一个值就能通用的，它必须和容器内存限制、线程数、应用类型三者对齐，否则不是浪费资源就是被 OOM Killer 杀掉。
为什么不能只看 php.ini 里的 memory_limit
FrankenPHP 是多线程模型，memory_limit 控制的是「单个请求」的 PHP 内存上限，不是整个进程；而容器总内存由 Docker/cgroup 硬限制——这两个值不联动。比如你设 memory_limit = 512M，但容器只给了 512m，8 个线程一并发，立刻超限被杀，连错误日志都来不及写。
常见错误现象：Killed 进程退出、dmesg | grep -i "killed process" 显示 FrankenPHP 被 OOM Killer 终止、Caddy 访问返回空响应或 502。
- CLI 模式（如 Worker）下，
memory_limit实际约束的是整个常驻进程的堆上限，不是“每次请求重置” - OPcache、autoload classmap、框架静态缓存都会额外吃内存，实测 Laravel + OPcache 单请求常驻约 25–40MB，峰值可能翻倍
- WordPress 插件多时，
memory_limit = 256M都可能不够，建议起步512M
不同场景下的推荐值与依据
数值不是拍脑袋定的，得按 num_threads × memory_limit 反推（留 20% 缓冲给系统和 OPcache）：
- Symfony Worker 模式（生产）：
memory_limit = 256M或384M，配合opcache.memory_consumption = 128；绝不要在public/index.php里用ini_set('memory_limit', ...)，worker 启动后修改无效 - 纯 API 服务（Laravel/Lumen 轻量）：
memory_limit = 192M～256M，前提是关掉 debug 组件、禁用 profiler-pack - WordPress（含 WooCommerce/插件生态）：
memory_limit = 512M，并确保opcache.enable = 1、opcache.max_accelerated_files = 10000 - Docker 中容器设
mem_limit: 512m→ PHP 层memory_limit最高只能设400M；设1g容器 → PHP 层可设768M
容易踩的坑：动态设置和 CLI 特性
很多人想“按需提内存”，但在 FrankenPHP 里这么干风险很高：
-
ini_set('memory_limit', '1G')必须在脚本开头、任何类加载或数据库连接前执行；一旦 autoload 已触发，再调就晚了 - CLI 环境下允许设
-1（不限制），但仅限可信、短时任务（如命令行导出），绝不用于 Web 请求或 Worker - Worker 模式下，
php_ini memory_limit在 Caddyfile 里配置（如php_ini memory_limit 256M）比改 php.ini 更可靠，优先级更高 - 别信 “设大点没事”——PHP 垃圾回收在 >512MB 堆上效率会断崖下跌，反而更容易卡住
真正关键的不是数字本身，而是它和 num_threads、容器 mem_limit、OPcache 配置是否构成闭环。漏掉任意一环，优化就白做。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
