PHP临时文件堆积的根本原因是其依赖请求正常结束的不可靠清理机制，必须在上传成功、失败及脚本终止三处手动干预清理，并配合独立可控的upload_tmp_dir与定时任务。
PHP上传音频文件后，临时文件堆积不是“偶尔发生”，而是只要上传逻辑没做清理兜底，就一定会发生——尤其在出错、中断或并发上传时。move_uploaded_file() 成功后不会自动删临时文件，失败也不删，PHP只在请求结束时尝试清理，但这个机制不可靠。
为什么 upload_tmp_dir 里的 .tmp 文件越积越多
根本原因在于：PHP 的临时文件生命周期依赖于「请求正常结束」这一前提。而音频上传常伴随以下破坏该前提的场景：
- 用户中途关闭页面或刷新，导致请求被 Nginx 或浏览器主动中断，PHP 进程收不到完整请求，
$_FILES可能未完全解析，临时文件滞留 -
move_uploaded_file()失败（比如目标目录权限不足、磁盘满、路径不存在），但代码没做unlink()补救 - 前端用分片上传，每个分块都生成一个临时文件，合并前若某块失败，对应临时文件不会被自动回收
- Web 服务器（如 Nginx）配置了
client_max_body_size限制，超限请求被截断，PHP 甚至收不到$_FILES，但部分数据已写入临时目录
必须手动清理的三个关键时机
不能等 PHP 自动清理。要在代码里显式干预，覆盖所有常见失败路径：
- 上传成功后，确认
move_uploaded_file()返回true，此时临时文件已移走，无需再删 —— 但别忘了：如果后续业务逻辑抛异常（比如数据库写入失败），你得自己unlink()已移动的目标文件，否则也算“堆积” - 上传失败时（
$_FILES['audio']['error'] !== UPLOAD_ERR_OK），立即unlink($_FILES['audio']['tmp_name'])；注意判断tmp_name是否为空字符串或 null，避免警告 - 在脚本末尾加
register_shutdown_function()回调，检查$_FILES中是否存在未处理的tmp_name，并尝试安全删除（需先is_file()和is_writable()判定）
upload_tmp_dir 配置与定期清理策略
临时目录本身也要可控，不能长期依赖系统默认的 /tmp：
立即学习“PHP免费学习笔记（深入）”；
- 在
php.ini中显式设置upload_tmp_dir = /var/www/uploads/tmp，确保该路径独立、可监控、有配额限制 - 避免多个项目共用同一
upload_tmp_dir，否则一个项目的残留会干扰另一个 - 配合系统级定时任务清理陈旧文件，例如每天执行：
find /var/www/uploads/tmp -name "*.tmp" -mmin +60 -delete
（删除 60 分钟以上未修改的临时文件） - 不要用
touch或stat更新时间来“续命”，这会让清理失效；真正可靠的生命周期应由业务代码控制
临时文件堆积的本质是状态管理缺失。PHP 不负责替你记住“这个临时文件属于哪个上传会话”，它只管写完就扔。所以最易被忽略的一点是：如果你用了分片上传，每个 .partN 文件也得走同样清理逻辑，且要和唯一文件 ID 绑定，否则一次失败的合并操作就会留下一整套碎片。
