PHP 8.5.7 大文件上传超时需同步调优HTTP接收、临时写入、脚本处理三环节，漏一即静默失败；必须严格设upload_max_filesize=256M（单位大写）、post_max_size≥256M+16M、Nginx client_max_body_size匹配，并区分max_input_time（解析请求体）与max_execution_time（脚本执行），二者均需设为0或足够大。
PHP 8.5.7 上传大文件超时，不是改一个 upload_max_filesize 就能解决的——它卡在 HTTP 请求体接收、临时文件写入、脚本处理三个环节，每个环节都有独立超时和大小限制，漏掉任意一个都会静默失败。
为什么改了 upload_max_filesize 还是 $_FILES 为空？
这是最典型的“以为改对了，其实根本没进 PHP”。PHP 8.5.7 对单位校验更严格，256m 或 256 M 会被当 0 处理，256M 才有效。但即使单位正确，也必须同步满足：
-
post_max_size≥upload_max_filesize+ 表单其他字段开销（建议至少多加 16M） - Nginx 的
client_max_body_size必须 ≥post_max_size，否则请求在 Nginx 层就被 413 拒绝，PHP 根本收不到 - PHP-FPM 的
request_terminate_timeout（非max_execution_time）可能先于 PHP 脚本超时，尤其在慢磁盘上写临时文件时 - 用
var_dump(ini_get('upload_max_filesize'))验证是否返回字符串"256M"，而不是false或空——别信 phpinfo() 里显示的路径，CLI 和 Web 加载的 php.ini 很可能不同
max_input_time 和 max_execution_time 到底谁管什么？
PHP 8.5.7 明确区分这两个时间窗口，混淆会导致上传卡在 99%：
-
max_input_time：控制 PHP 解析整个 POST 请求体（含 multipart boundary 和所有分块）的最长时间。大文件流式读取就发生在这里，Nginx FastCGI 转发延迟也计入此值 -
max_execution_time：只从脚本第一行开始计时，move_uploaded_file()移动临时文件、计算哈希、重命名等操作才走这里 - 二者都得设为 0（不限制）或足够大（如 1200），不能只调一个。尤其在 NFS 或网络挂载盘上，
move_uploaded_file()可能单次耗时几百毫秒，积少成多直接触发max_execution_time
超过 500MB 的文件，别碰 fgets() 和一次性 file_get_contents()
硬读整个文件会吃光 memory_limit，PHP 8.5.7 默认 128M，哪怕你设了 1G，大文件校验或转换仍可能 OOM。该放弃“行”概念时，就用流式处理：
立即学习“PHP免费学习笔记（深入）”；
- 用
fread($fp, 8192)分块读，配合hash_update()增量算 MD5，不缓存全文 - 合并分片时用
file_put_contents($target, $chunk, FILE_APPEND | LOCK_EX)，避免内存拼接 - 目标路径必须是本地 SSD，避开 NFS、CIFS、/tmp（某些系统 /tmp 是 tmpfs，空间不足会直接失败）
- 如果业务允许，前端强制分片（如每片 8MB），后端只做接收+追加，不拼接——拼接逻辑延后到下载或预览时再做
PHP 8.5.7 特别要注意的兼容细节
这个版本没新增函数，但底层校验收紧，容易暴露旧配置里的“侥幸”写法：
- 单位必须全大写：
1G✅，1g❌，1024M❌（超出单位范围，部分环境静默截断为 0） -
php_admin_value在 Nginx vhost 或 Plesk/cPanel 中会锁定参数，此时改 php.ini 无效，得进控制面板或改容器启动参数 - Cloudflare、阿里云 WAF 等反代层有默认 100MB 上传限制，必须单独调整，否则 PHP 根本等不到
- 临时目录
upload_tmp_dir的磁盘剩余空间必须 > 文件大小 × 2（PHP 先写临时文件，再 move），且www-data用户需有写权限，mkdir()不会自动创建父目录
真正卡住的地方，往往不在 PHP 配置本身，而在临时文件落盘那一下——检查 df -h 和 ls -ld 比调参数有用得多。
