frankenphp 的请求体大小限制由 php 的 post_max_size 和 upload_max_filesize 控制，不依赖 client_max_body_size；修改 ini 后无需重启，但需确保 memory_limit 和 max_execution_time 匹配；细粒度拦截需在框架中间件中通过 content-length 头实现。
FrankenPHP 的请求体大小限制由 SAPI 层直接控制
FrankenPHP 不走传统 PHP-FPM 或 Apache 模块路径，而是以 Go 为宿主、内嵌 PHP 解析器运行——这意味着它绕过了 php-fpm.conf 和 Web 服务器的间接转发逻辑，但**仍完全遵守 PHP 的底层 ini 配置**。真正起效的仍是 post_max_size 和 upload_max_filesize，且修改后无需重启 FrankenPHP 进程（它会在每个请求开始时读取当前 ini 值）。
client_max_body_size 在 FrankenPHP 中不生效
FrankenPHP 自带 HTTP 服务器（基于 Go 的 net/http），不依赖 Nginx/Apache 作前置代理——所以你在 Nginx 配置里写的 client_max_body_size 完全没机会触发。FrankenPHP 的请求体拦截发生在 Go 层，但它默认不限制 body 大小；实际拦截权交还给了 PHP 解析阶段。
- 如果你用 FrankenPHP 直连（
frankenphp serve或嵌入 Go 服务），client_max_body_size这个配置根本不存在，也不需要配 - 如果你把 FrankenPHP 当作 FastCGI 后端挂给 Nginx，则 Nginx 的
client_max_body_size会先拦一次（返回 413），PHP 层根本收不到请求 —— 这不是 FrankenPHP 的问题，是反向代理链路的责任划分 - 验证方式：curl -X POST --data-binary @huge.json http://localhost:8080/api，同时观察 PHP 错误日志是否出现
PHP Warning: POST Content-Length ... exceeds the limit
如何在 FrankenPHP 中做细粒度请求体拦截
PHP 层限制太粗（全局生效、无法 per-route），而 FrankenPHP 又不提供类似 EventHttp::setMaxBodySize() 的原生 API。此时唯一轻量可控的方式，是在 Laravel/ThinkPHP 等框架中间件里读 Content-Length 头提前 abort。
- 必须用
$request->header('Content-Length')，不能调$request->getContent()或$request->all()，否则已分配内存，失去拦截意义 - 注意：HTTP/2 或分块传输（chunked encoding）下
Content-Length为 null，此时只能依赖 PHP 层 fallback（即等它报 400） - FrankenPHP 对
Content-Length的透传是可靠的，它不会像某些 CDN 那样删除或改写该头 - 示例判断：
if ($contentLength > 5 * 1024 * 1024) { abort(413); }
memory_limit 和 max_execution_time 是隐藏瓶颈
即使你把 post_max_size 放到 200M，若 memory_limit 仍为 128M，PHP 在解析超大 JSON 或 multipart 时可能直接 OOM crash；同样，上传耗时超过 max_execution_time 会导致连接中断而非 413。
-
memory_limit应 ≥post_max_size× 1.5（解析开销+业务处理） -
max_execution_time建议设为 600（10 分钟），尤其对慢网用户 - FrankenPHP 不支持动态调整这些值（如
ini_set()对post_max_size无效），必须写进 php.ini 或通过frankenphp.Config加载 ini 文件
FrankenPHP 的 body 限制看似“无感”，实则把控制权更彻底地交还给了 PHP 本身——你容易忽略的是：它不帮你兜底，也不替你做二次决策，所有限制都发生在最底层，且不可绕过。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
