upload_max_filesize修改后不生效的主因是其他层级限制未同步调整：post_max_size须≥该值，nginx需设client_max_body_size，apache需调limitrequestbody，且须确认php.ini实际加载路径并重启服务。
upload_max_filesize 修改后不生效的常见原因
改了 upload_max_filesize 却还是传不了大文件？大概率不是 PHP 本身没读到配置，而是被其他限制卡住了。这个值只是上传流程里的一环，后面还有 post_max_size、max_execution_time、甚至 Web 服务器层的拦截。
-
post_max_size必须 ≥upload_max_filesize，否则整个 POST 请求会被直接拒绝（PHP 根本收不到文件） - Nginx 默认有
client_max_body_size，Apache 有LimitRequestBody，这些不调，PHP 层改了也没用 - CLI 模式下修改
php.ini无效——Web 服务用的是它自己的 PHP 配置，和终端执行php -v看到的可能不是同一份 - 某些 docker 镜像或宝塔面板会覆盖主配置，优先检查
php --ini输出的加载路径，再确认实际生效的是哪个.ini文件
PHP 8.5 中 upload_max_filesize 的正确设置方式
PHP 8.5 没有新增上传相关语法或函数，但对 ini 值的解析更严格：单位必须大写（M、G），小写如 m 会被当成 0；数值不能带空格，128 M 会失效。
- 编辑实际生效的
php.ini（用php --ini和phpinfo()双重确认） - 同时调整两个关键项：
upload_max_filesize = 256Mpost_max_size = 256M（建议略大一点，比如260M，留点 header 缓冲） - 重启对应服务：Nginx + PHP-FPM 要
sudo systemctl restart php8.5-fpm nginx，不是只 reload - 验证是否生效：
var_dump(ini_get('upload_max_filesize'), ini_get('post_max_size'));，输出应为字符串如"256M"，不是false或空
为什么改完还是报 “Missing boundary in multipart data” 或 413 错误
这不是 PHP 报的错，是 Web 服务器在请求体到达 PHP 前就拦截了。413 是 Nginx/Apache 的状态码，Missing boundary 多半是因为请求体被截断或格式损坏——根本原因是 body 大小超限，导致服务器没收到完整 multipart 包。
- Nginx：检查
client_max_body_size，需在http、server或location块中显式设置，例如client_max_body_size 256M; - Apache：检查
LimitRequestBody（单位是字节），设为0表示不限，或明确写268435456（256×1024×1024） - Cloudflare 或其他 CDN：它们也有上传大小限制（免费版默认 100MB），PHP 和源站改得再大也没用
- 浏览器端：部分老版本 chrome 对超大表单提交有隐式限制，可先用
curl -F "file=@big.zip" http://localhost/upload.php排除前端干扰
PHP 8.5 下大文件上传的现实瓶颈
把 upload_max_filesize 改到几 G 看似可行，但实际容易触发内存溢出或超时，尤其在共享主机或低配 VPS 上。
立即学习“PHP免费学习笔记（深入）”；
-
memory_limit必须 ≥ 上传文件大小（PHP 默认会把整个文件读进内存做校验），建议设为512M或更高 -
max_execution_time和max_input_time都要延长，上传 1GB 文件在千兆内网也需几十秒，慢速网络更要预留分钟级 - 临时目录
upload_tmp_dir必须有足够空间和写权限，否则会静默失败（$_FILES['xxx']['Error'] === 6） - 真正生产环境别硬扛大文件上传：前端分片 + 后端合并才是可靠方案，
upload_max_filesize只适合控制单次请求的合理上限
事情说清了就结束。注意：PHP 8.5 没有 magic fix，上传限制是层层关卡，漏掉任意一环都会失败；最常被忽略的是 Web 服务器配置和实际生效的 ini 文件路径。