必须启用file_uploads = On，否则上传静默失败；post_max_size须严格大于upload_max_filesize，且需同步调大max_input_time、max_execution_time，并确保upload_tmp_dir可写且空间充足。
php.ini 中必须启用的上传开关
最基础但最容易被忽略的一点：file_uploads = On 必须存在且为 On。很多共享主机或 Docker 镜像默认关闭此项，导致整个上传流程静默失败——表单提交后页面空白或跳转，$_FILES 为空数组，也无错误提示。
验证方式很简单：在 PHP 脚本中运行 var_dump(ini_get('file_uploads'));，输出不是 "1" 就说明没开。
upload_max_filesize 和 post_max_size 的配比关系
这两个值不是独立设置的，而是强依赖关系：post_max_size 必须严格大于 upload_max_filesize，否则哪怕文件本身没超限，也会因 POST 总载荷超限而触发 UPLOAD_ERR_FORM_SIZE（错误码 2）或更隐蔽的 400 错误。
-
upload_max_filesize = 50M→ 单个音频文件上限（如长播客、无损 WAV） -
post_max_size = 60M→ 预留 10M 给表单其他字段（如标题、描述、token 等） - 若允许多文件上传，
post_max_size还需再上浮，比如 5 个 50M 文件就得 ≥250M + 额外开销
注意：upload_max_filesize 不影响 $_FILES['xxx']['size'] 的读取——它只在 PHP 接收阶段拦截，一旦进到 $_FILES，大小就是真实的字节数。
立即学习“PHP免费学习笔记（深入）”；
max_execution_time 和 max_input_time 对大音频的影响
上传一个 100MB 的 FLAC 文件，网络慢时可能耗时 30 秒以上。如果 max_input_time = 60（默认常见值），PHP 在解析完 POST 数据前就中断，报错 UPLOAD_ERR_NO_FILE（错误码 4）——看起来像“用户没选文件”，实则是超时丢包。
建议按业务场景调整：
- 内网或高速环境：
max_input_time = 120，max_execution_time = 180 - 公网面向用户：
max_input_time = 300，并配合前端分片上传或进度条反馈，避免用户反复提交 -
memory_limit一般不用调高——PHP 上传不把整个文件读进内存，move_uploaded_file()是直接移动临时文件句柄
upload_tmp_dir 权限和磁盘空间问题
PHP 把上传文件先写入临时目录，再由脚本移动。如果 upload_tmp_dir 指向的路径不存在、不可写、或磁盘已满，会直接报 UPLOAD_ERR_CANT_WRITE（错误码 7）或 UPLOAD_ERR_NO_TMP_DIR（错误码 6）。
排查方法：
- 运行
echo sys_get_temp_dir();查看当前临时目录 - 确认该路径属主是 Web 服务器用户（如
www-data或apache），且有写权限 - 检查
df -h是否根分区或/tmp已 100% 占用（尤其 Docker 容器里默认/tmp很小）
临时目录出问题时，$_FILES['audioFile']['tmp_name'] 可能为空字符串或非法路径，后续 move_uploaded_file() 必然失败，且不会给出明确原因——这是最常被误判为“代码逻辑错误”的底层陷阱。
