upload_tmp_dir必须显式指定且确保php进程有读写权限，否则move_uploaded_file()会静默失败并返回错误码6或7；同时需配平upload_max_filesize与post_max_size，并同步调整nginx的client_max_body_size及php的max_input_time。
upload_tmp_dir 配置必须显式指定且可写
PHP 7.1 和 7.2 默认不强制设置 upload_tmp_dir，会退回到系统临时目录（如 /tmp 或 C:\Windows\Temp）。但一旦磁盘满、权限不对或 SELinux/AppArmor 限制，move_uploaded_file() 就会静默失败，$_FILES['file']['error'] 返回 6（缺少临时文件夹）或 7（无法写入）。不要依赖默认值。
实操建议：
- 在
php.ini中明确设置：upload_tmp_dir = /var/www/tmp（Linux）或upload_tmp_dir = C:\php\tmp（Windows） - 确保该路径存在、属主为 Web 进程用户（如
www-data或nginx），且有读写权限：chmod 700 /var/www/tmp && chown www-data:www-data /var/www/tmp - 重启 PHP-FPM 或 Apache 后，用
ini_get('upload_tmp_dir')验证是否生效 - 若用容器（Docker），需挂载该目录并设好 uid/gid，否则即使配置了也写不进
PHP 7.1/7.2 的 upload_max_filesize 和 post_max_size 必须配平
这两个参数在 PHP 7.1–7.2 中仍是硬性拦截点，改错一个就全废。尤其注意：PHP 7.2 对 post_max_size 解析更严格，若它比 upload_max_filesize 小哪怕 1 字节，整个 $_POST 和 $_FILES 都会为空，不是报错而是“收不到”。
实操建议：
- 设
upload_max_filesize = 128M，则post_max_size至少为128M；建议设为135M留出表单字段、边界符等开销 - 避免用
128MB这种写法——PHP 7.1/7.2 只认M（兆字节），MB会被当成 0，导致实际限制为 0 - 检查是否被其他配置覆盖：某些 Plesk/cPanel 环境会在
php_admin_value中锁死这些值，ini_set()完全无效 - 用
var_dump($_FILES)+var_dump($_POST)双查：如果$_FILES为空但$_POST有数据，基本就是post_max_size卡住了
max_execution_time 和 max_input_time 在 PHP 7.2 中行为有差异
PHP 7.1 默认 max_input_time = -1（不限制），而 PHP 7.2 改为默认 60 秒。上传大文件时，光是接收 HTTP body 就可能超时，触发 400 Bad Request 或直接断连，且错误日志里未必留痕。
实操建议：
- PHP 7.2 必须显式设
max_input_time = 600（或更高），不能依赖默认值 -
max_execution_time要覆盖后续处理：比如finfo_open()检测 MIME、move_uploaded_file()写磁盘、生成缩略图等，建议 ≥max_input_time + 60 - 若用 Nginx + PHP-FPM，还要同步调
request_terminate_timeout（FPM 层），否则 PHP 脚本没超时，FPM 主动 kill 掉进程，报502 Bad Gateway - 用
set_time_limit(0)在脚本里动态关时限，仅对 CLI 有效；Web SAPI 下受max_execution_time硬控
Nginx client_max_body_size 不匹配会导致 413 错误，与 PHP 版本无关
无论 PHP 是 7.1 还是 7.2，只要 Nginx 的 client_max_body_size 小于 PHP 的 post_max_size，请求根本到不了 PHP，浏览器直接收到 413 Request Entity Too Large。这个错误常被误判为 PHP 配置问题。
实操建议：
- 在 Nginx 的
http、server或具体location块中加：client_max_body_size 135M;（必须 ≥ PHP 的post_max_size） - 修改后运行
nginx -t && systemctl reload nginx，不是 restart - 若用 Nginx Proxy Manager（NPM）或 Cloudflare，它们也有独立的 body size 限制，需单独排查
- 前端用
XMLHttpRequest.upload.onprogress监听：如果进度卡在 0%，大概率是 Nginx 拦截；卡在 99%，才是 PHP 或后端处理慢
post_max_size 和 max_input_time 这三项，在 PHP 7.1/7.2 上最容易被忽略——它们不报错，只让上传“消失”或“卡住”，排查时得从 Nginx 日志、PHP 错误日志、$_FILES 结构三头对齐才找得准。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
