$_FILES'audio' 返回整数编码：0（成功），1（超upload_max_filesize），2（超MAX_FILE_SIZE），3（部分上传），4（未选文件），6（无临时目录），7（写入失败），8（扩展禁用）。
PHP音频上传失败时 $_FILES['audio']['error'] 返回什么值
PHP处理文件上传时，$_FILES['audio']['error'] 是判断音频上传是否出问题的第一依据。它不是布尔值，也不是字符串错误信息，而是一个整数编码——每个数字对应一种具体失败原因。
常见值包括：0（成功）、1（超出 upload_max_filesize）、2（超出表单中 MAX_FILE_SIZE 隐藏字段）、3（文件只上传了部分）、4（未选择文件）、6（找不到临时文件夹）、7（写入失败）、8（扩展被禁用，如 fileinfo 或 exif 关闭可能间接导致后续校验失败）。
注意：error 为 0 只代表 PHP 接收完成，并不保证是合法音频文件——比如用户把 .txt 改名成 .mp3，error 仍是 0。
如何用 mime_type 和 file extension 双重校验音频文件
仅靠后缀名（如 $_FILES['audio']['name'] 的 .wav）完全不可信；仅靠 finfo_file() 返回的 MIME 类型也可能被绕过（如构造特殊头部的恶意文件）。必须两者结合，且优先以 finfo 检测结果为准。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 用
finfo_open(FILEINFO_MIME_TYPE)获取真实 MIME，白名单限定为audio/mpeg、audio/wav、audio/ogg、audio/mp4等，拒绝application/octet-stream或text/plain - 提取文件扩展名时用
pathinfo($_FILES['audio']['name'], PATHINFO_EXTENSION)，而非substr()或正则，避免双扩展名（如voice.mp3.php）绕过 - 如果
finfo返回audio/x-wav，但扩展名是.mp3，应直接拒绝——类型与扩展名不一致大概率是伪装 - 对
audio/ogg要额外注意：有些 OGG 文件实际是视频（video/ogg），需用finfo精确匹配，不能模糊匹配ogg
为什么 move_uploaded_file() 失败却没报错？
move_uploaded_file() 返回 false 时不抛异常，也不输出错误信息，容易误判为“上传成功但没保存”。根本原因通常是权限或路径问题。
排查要点：
- 目标目录（如
/var/www/uploads/）必须存在，且 Web 服务器用户（如www-data或nginx）有写权限，chmod 755不够，需775或确保组可写 - 不要用相对路径，如
./uploads/；始终用绝对路径，通过__DIR__ . '/uploads/'拼接 - 检查磁盘空间：
disk_free_space()在调用前做一次判断，避免传到一半因空间不足静默失败 - 临时文件可能已被清理：如果上传耗时较长（如大音频文件 + 慢网络），PHP 的
max_execution_time或代理超时可能导致$_FILES['audio']['tmp_name']对应的临时文件被删，此时move_uploaded_file()必然失败
音频文件过大时如何提前拦截，避免浪费带宽
等整个文件上传完再检查大小，对用户和服务器都是负担。应在 PHP 层之前就设防。
关键控制点：
- 在
php.ini中调低upload_max_filesize和post_max_size（后者必须 ≥ 前者），例如设为20M；否则即使代码里检查$_FILES['audio']['size'] > 20 * 1024 * 1024，PHP 已经把几十 MB 数据读进内存或临时文件了 - 前端加
<input type="file" accept="audio/*">，虽可被绕过，但能减少普通用户误传视频或文档 - 若用 AJAX 上传，可在
XMLHttpRequest.upload.onprogress中实时监控，上传到 5MB 时发现远超预期，主动 abort 并提示 - Nginx 用户可在
client_max_body_size设置硬限制，比 PHP 层更早拦截，返回413 Request Entity Too Large
真正难处理的是「合法但危险」的音频：比如一个 100MB 的 24bit/192kHz FLAC，finfo 认证无误，MIME 正确，但解码时可能耗尽内存或触发超时。这种需要后续用 ffprobe 检查采样率、位深、时长等元数据，不在上传阶段解决。
