看起来你遇到的是个典型的多文件上传坑——单文件/少量文件能正常上传，但数量到3个及以上时$_FILES直接为空。结合你已经检查的配置，下面是几个最可能的原因和对应排查步骤：

1. 检查post_max_size配置（最常见诱因） #

你已经确认了upload_max_filesize和max_file_uploads，但很容易忽略**post_max_size**这个关键配置：它控制着整个POST请求的总大小上限，包含所有上传文件的总和+表单其他数据。

如果3个及以上MP3的总大小超过了post_max_size的值，PHP会直接丢弃整个POST请求，导致$_FILES和$_POST都为空。

• 排查方法：在PHP处理脚本的开头添加phpinfo();，搜索post_max_size查看实际生效的值，确保它大于upload_max_filesize * 预期最多上传文件数（比如你要传5个200M的文件，post_max_size至少要设为1000M或1G）。
• 修改后务必重启Web服务器（Apache/Nginx等），否则配置不会生效。

2. 确认max_file_uploads是否真的生效 #

虽然你说php.ini里设了max_file_uploads = 20，但有时候会存在以下情况导致配置不生效：

• 你修改的不是Web服务器正在使用的php.ini文件（比如CLI和Web环境用的是不同的配置文件）；
• 项目目录下的.htaccess（Apache）或user.ini（PHP-FPM）文件覆盖了这个配置；
• 修改后没有重启Web服务器，新配置未加载。

排查方法：同样用phpinfo();查看max_file_uploads的实际值，确保是你设置的20。

3. 检查上传临时目录的权限 #

PHP会把上传的文件先存到upload_tmp_dir指定的临时目录，如果这个目录没有写权限（对Web服务器的运行用户，比如www-data、apache），当上传文件数量较多时，可能无法创建临时文件，导致上传失败。

• 排查方法：用phpinfo();找到upload_tmp_dir的路径，然后检查该目录的权限：

  # 示例：假设临时目录是/tmp/php_upload
  ls -ld /tmp/php_upload
  

  确保所有者或组是Web服务器运行用户，且有写权限（权限至少为755）。

4. 检查Web服务器的请求大小限制 #

如果你的Web服务器是Nginx，它有一个client_max_body_size配置，控制客户端发送的请求体最大大小。如果总文件大小超过这个值，Nginx会直接拒绝请求，PHP根本接收不到任何数据，自然$_FILES为空。

• 排查方法：查看Nginx的配置文件（比如nginx.conf或站点专属配置文件），找到client_max_body_size，确保它的值大于你的预期总上传大小，修改后重启Nginx。

5. 确认表单的enctype未被意外修改 #

虽然你的表单里已经设置了enctype="multipart/form-data"（这是文件上传的必要属性），但如果页面有JS代码动态修改表单属性，或者表单在渲染过程中被篡改，可能导致这个属性丢失。你可以在浏览器开发者工具里查看最终渲染的HTML，确认enctype属性存在且正确。

内容的提问来源于stack exchange，提问作者Worksfather