PHP上传文件大小限制需同步调整upload_max_filesize、post_max_size和memory_limit三个参数，并配置Nginx的client_max_body_size或Apache的LimitRequestBody，修改后必须重启PHP-FPM及Web服务，再通过phpinfo()确认生效路径与值。
PHP上传文件大小限制不是前端控制得了的，必须从服务器配置层下手。单改upload_max_filesize基本没用，它只是三把锁里最内层的一把。
为什么改了 upload_max_filesize 还报 UPLOAD_ERR_INI_SIZE（错误码 1）
因为 PHP 在解析 POST 请求前就卡在了外层限制上。真正生效的是三个参数协同作用：
-
upload_max_filesize：单个文件上限，比如100M -
post_max_size：整个 POST 请求体总大小，必须 ≥upload_max_filesize，建议多留 5–10M，比如105M -
memory_limit：脚本内存上限，要能装下上传的临时数据，至少是post_max_size的 1.5 倍，比如256M
单位必须用 M 或 G（大写），不能带引号，不能写 MB 或 mb；设成 134217728（字节数）虽合法但极易出错，不推荐。
Nginx 或 Apache 拦在 PHP 前面，返回 413 错误
即使 PHP 配置全调大了，Nginx/Apache 也会在请求抵达 PHP 前直接拒绝。这时你根本收不到 $_FILES，日志里只有 413 Request Entity Too Large。
立即学习“PHP免费学习笔记（深入）”；
- Nginx：在对应
server块里加client_max_body_size 105m（注意单位是小写m，且别写进http全局块） - Apache：用
LimitRequestBody 110100480（单位字节，105MB ≈ 110100480）或在.htaccess中写php_value post_max_size 105M（仅限 mod_php，PHP-FPM 下无效）
改完 Nginx 要 nginx -t && nginx -s reload，Apache 要 apachectl graceful 或重启服务。
ini_set() 和 .htaccess 能不能救急
不能替代 php.ini，只能补漏：
-
ini_set('upload_max_filesize', '64M')是无效的——该指令类型为PHP_INI_SYSTEM，运行时不可修改，PHP 官方明确标注 -
.htaccess中的php_value upload_max_filesize 64M仅对 Apache + mod_php 生效，多数云主机、Docker 环境或启用了 PHP-FPM 的站点会直接 500 - 真正能动态起效的只有框架层校验，比如 ThinkPHP 的
$file->validate(['size' => 52428800])，但它只在 PHP 已成功接收文件后才执行，拦不住底层超限
怎么确认你改的配置真生效了
别猜路径，别信备份名，用事实验证：
- 写个
test.php，内容为<?php phpinfo(); ?>，访问它，搜索 “Loaded Configuration File” 找到真实加载的php.ini路径 - 在同一页面搜 “upload_max_filesize”，确认显示值是你刚写的
100M，不是旧值或2M - CLI 下运行
php --ini和php -r "echo ini_get('upload_max_filesize');"，看命令行环境是否也同步（有些部署中 CLI 和 Web 使用不同配置） - 上传一个略小于设定值的文件，再 dump
$_FILES['xxx']['error']，确保不是 1（INI_SIZE）、2（FORM_SIZE）或 4（NO_FILE）
最容易被忽略的是：改完 php.ini 后只 reload Nginx，却忘了 restart PHP-FPM；或者改了 Apache 的 php.ini，却用 Nginx + PHP-FPM 运行，压根没读那个文件。
