PHP音频上传需同步调大upload_max_filesize、post_max_size和memory_limit三个参数，并配置Nginx的client_max_body_size或Apache的LimitRequestBody，重启服务后生效；前后端须双重校验文件大小，排查临时目录权限与磁盘空间，超100MB推荐分片上传。
PHP上传音频时限制文件大小，不能只改 upload_max_filesize 就完事——音频文件（如 MP3、WAV、FLAC）往往体积大、解码耗内存，单靠一个参数容易漏掉关键拦截点，导致上传失败却报错不明。
必须同步调大的三个 PHP 配置项
音频上传失败最常见现象是 $_FILES 为空，或 $_FILES['audio']['error'] === UPLOAD_ERR_INI_SIZE（值为 1）。这说明请求在 PHP 解析层就被截断了，根源是以下三个参数没协同：
-
upload_max_filesize：控制单个音频文件上限，比如设为50M（WAV 常超 20MB，FLAC 可达 100MB+） -
post_max_size：必须 ≥upload_max_filesize，建议设为60M，否则整个 POST 包（含表单字段）会被拒绝 -
memory_limit：音频处理（如用getid3或ffmpeg提取元数据）会吃内存，至少设为256M，避免上传中途Fatal error: Allowed memory size exhausted
改完后必须重启 PHP-FPM（sudo systemctl restart php8.1-fpm）或 Apache/Nginx，仅 reload 不生效。
Nginx 或 Apache 的外层拦截常被忽略
即使 PHP 配置全调大，Nginx/Apache 仍可能在请求到达 PHP 前就干掉它：
立即学习“PHP免费学习笔记（深入）”；
- Nginx：必须在
server或location块中加client_max_body_size 60M，否则返回413 Request Entity Too Large，且错误日志里不会提 PHP - Apache：检查是否启用了
LimitRequestBody，若设为10485760（10MB），需同步调高，否则和 Nginx 表现一致 - 代理/CDN（如 Cloudflare）：默认上传限制常为 100MB，但部分计划只支持 10MB；直连测试可快速排除这类干扰
前端校验 + 后端二次校验不能省
用户选了个 200MB 的 WAV 文件，前端不拦，等提交再报错，体验极差。必须做两层校验：
- 前端 JS 立即读
file.size，比如限制 50MB：if (file.size > 50 * 1024 * 1024) { alert('音频不能超过 50MB'); return false; } - 后端不能信
$_FILES['audio']['size']就完事，要先检查$_FILES['audio']['error']是否为UPLOAD_ERR_OK；再比对实际大小与业务阈值，例如：if ($_FILES['audio']['size'] > 52428800) { die('音频文件超限'); } - 别依赖
MAX_FILE_SIZE隐藏字段——浏览器可绕过，PHP 也不强制校验它
音频上传失败的静默陷阱
有些问题不报错，但音频传了一半就停了，$_FILES['audio']['size'] 是 0 或 error 为 3（UPLOAD_ERR_PARTIAL）：
- 临时目录
upload_tmp_dir磁盘满，或www-data用户无写权限 → 查df -h /tmp和ls -ld /var/tmp -
max_execution_time或max_input_time太小 → 音频上传慢，PHP 直接 kill 进程；建议都设为600（10 分钟） - 音频格式本身损坏，或客户端中断上传 → 这类不是配置问题，但容易误判为后端限制没生效
真正的大音频（>100MB）别硬扛，分片上传（tus.io 或自研）才是稳解；PHP 层只收 chunk，拼完再转码或存对象存储。
