frankenphp的upload_max_filesize常失效，因默认加载自身绑定的php.ini路径（如/etc/php/8.2/franken/php.ini），而非fpm配置；需用frankenphp -i确认路径并同步调整upload_max_filesize、post_max_size，且caddy层request_body max_size也须放开。
稳，但得调对地方。FrankenPHP 本身不改 PHP 的上传机制，upload_max_filesize、post_max_size 这些参数照常生效，直接沿用原 php.ini 配置大概率会出问题——不是超时就是 413 错误。
FrankenPHP 的 upload_max_filesize 为什么经常失效
FrankenPHP 启动时默认加载系统级 php.ini，但很多用户只改了 FPM 模式下的配置（比如 /etc/php/8.2/fpm/php.ini），而 FrankenPHP 实际读的是它自己绑定的路径，比如 /etc/php/8.2/franken/php.ini 或二进制内置路径。没改对位置，参数就等于没设。
- 用
frankenphp -i | grep "Loaded Configuration File"确认实际加载的php.ini路径 - 检查该文件中
upload_max_filesize和post_max_size是否已按需设置（如upload_max_filesize = 2G） -
post_max_size必须 ≥upload_max_filesize，否则 multipart 解析直接失败 - 修改后无需重启系统服务，但要重启
frankenphp进程才能生效
Caddy 层的 body 大小限制必须同步放开
FrankenPHP 前面跑的是 Caddy，它自己也有请求体大小限制，默认是 4MB。哪怕 PHP 层全放开，Caddy 在解析阶段就把大文件拦下了，报错通常是 413 Request Entity Too Large。
- 在
Caddyfile的 server 块里加request_body max_size 2G - 如果用了
php_server指令，它内部默认继承 Caddy 全局限制，必须显式覆盖 - HTTP/3（QUIC）下该限制同样生效，不用额外处理 UDP 层
分片上传在 FrankenPHP 上反而更顺
FrankenPHP 的 worker 模式让每个 PHP 进程常驻，省去了每次请求重载框架和扩展的开销。上传接口如果是 Laravel 控制器，分片接收逻辑（比如校验 $_FILES、写临时块、查 Redis 状态）能更快响应，尤其在高并发分片请求下，延迟波动比 FPM 小得多。
- 避免把整个分片内容读进变量（如
file_get_contents($_FILES['chunk']['tmp_name'])），直接用move_uploaded_file()落盘 - 临时目录建议挂到 SSD 或 tmpfs，FrankenPHP 不控制磁盘 I/O，但 worker 常驻会让频繁的小写更敏感
- 如果用
frankenphp_worker模式，注意max_requests别设太小，否则 worker 重启时可能中断未合并的上传任务
真正容易被忽略的是：FrankenPHP 的 php_server 指令默认启用 try_files，它会把所有未命中静态文件的请求兜底转发给 PHP。但如果你在上传接口里用了重定向或子请求（比如预签名 URL 回调），得确认 Caddy 路由没意外截断或重写原始 POST body —— 这类问题不会报错，但分片元数据（如 index、total_chunks）会丢。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
