FrankenPHP 1.8 默认不加载 php.ini，memory_limit 需通过 -php-flags "-d memory_limit=256M" 显式注入，或在 PHP 入口用 ini_set() 设置，.htaccess 和 Nginx fastcgi_param 无效。
FrankenPHP 1.8 的内存限制不能通过传统 php.ini 的 memory_limit 直接生效——它默认忽略该配置项，除非你显式启用 PHP 配置加载。这是最容易踩坑的地方。
FrankenPHP 默认不读取 php.ini 的 memory_limit
FrankenPHP 基于 Caddy 和 SAPI 的嵌入式设计，默认使用“精简模式”启动 PHP，跳过常规的 php.ini 加载流程。这意味着即使你改了 /etc/php/8.3/cli/php.ini 或项目根目录下的 php.ini，memory_limit 也不会被应用。
验证方式：在脚本中执行 var_dump(ini_get('memory_limit'));，大概率返回空字符串或默认的 -1（无限制），而非你期望的 256M。
- 根本原因：FrankenPHP 启动时未调用
php_ini_scanned_files()，也未主动加载 ini 文件 - 影响范围：所有通过
frankenphp.ServeHTTP或命令行frankenphp run启动的 PHP 请求 - 安全提示：默认
-1在生产环境极危险，尤其处理上传、导出、图像缩放等操作时易触发 OOM
必须用 -php-flags 显式传入 memory_limit
FrankenPHP 1.8 提供了 -php-flags 参数，用于向嵌入式 PHP 引擎传递运行时配置，这是目前最可靠、最推荐的方式。
立即学习“PHP免费学习笔记（深入）”；
例如，在启动服务时：
frankenphp run -php-flags "-d memory_limit=256M" -c ./Caddyfile
或在 Caddyfile 中配置 PHP 服务时（适用于 php 指令）：
php {
php_flag memory_limit 256M
}
-
-d是 PHP CLI 的标准选项，等价于ini_set()，优先级高于php.ini - 单位必须带后缀：
128M、512M、2G；256（无单位）会被解释为字节，极易误设 - 若同时使用多个 flag，用空格分隔：
-php-flags "-d memory_limit=256M -d max_execution_time=300"
在 PHP 脚本内用 ini_set() 仍有效，但有局限
虽然 FrankenPHP 不加载 php.ini，但 ini_set() 函数本身仍可用，只要不是被 php_admin_flag 锁定的配置项（memory_limit 不在此列）。
在入口文件（如 index.php）顶部尽早调用：
<?php
ini_set('memory_limit', '256M');
// 后续逻辑...
- 仅对当前请求生命周期生效，无法覆盖 CLI 子进程（如
exec()启动的 PHP 脚本） - 若脚本在
ini_set()前已分配大量内存（比如自动加载器加载数百个类），可能来不及生效就崩溃 - 不适用于静态资源路由、中间件前置逻辑等未进入 PHP 执行上下文的场景
不要依赖 .htaccess 或 Apache/Nginx 指令
FrankenPHP 是独立 Web 服务器（基于 Caddy），完全不兼容 .htaccess、php_value、php_admin_value 等 Apache/Nginx 特有指令。尝试添加这些配置不会报错，但也不会起作用。
同样，Nginx 的 fastcgi_param PHP_VALUE "memory_limit=256M" 对 FrankenPHP 无效——它不走 FastCGI 协议，而是直接嵌入 PHP 解释器。
- 常见误操作：把旧 Apache 项目直接迁移到 FrankenPHP，保留
.htaccess里的php_value memory_limit，结果内存错误照旧 - 替代方案：统一收口到
-php-flags或ini_set()，避免环境混淆
FrankenPHP 1.8 的内存控制本质是“启动时注入”，不是“配置文件加载”。漏掉 -php-flags 或写错单位后缀（比如写成 256 而非 256M），是线上出现 Allowed memory size exhausted 错误的最常见原因。
