PHP图像处理的临时文件不会自动删除，必须手动调用unlink()清理；imagecreatefromxxx系列函数仅在内存中操作，不生成临时文件；真正写磁盘的是imagejpeg/imagepng传路径或tempnam()配合使用；imagedestroy()只释放内存，不影响磁盘文件；推荐用try/finally确保unlink()执行，并通过系统cron定时清理。
PHP图像处理产生的临时文件不会自动删除，必须手动清理，否则磁盘会持续增长直至写满。
imagecreatefromxxx 系列函数会生成内存图像，但不直接写磁盘
像 imagecreatefromjpeg、imagecreatefrompng 这类函数只在内存中加载图像资源，本身不创建临时文件。真正触发磁盘写入的，通常是后续显式调用 imagejpeg、imagepng 并传入文件路径，或使用 tempnam() + imagejpeg($img, $tmpfile) 模式时。
常见错误是：用 tempnam() 创建临时路径 → 写入图像 → 忘记 unlink() → 临时文件堆积。
- 检查所有图像输出逻辑，确认是否用了
tempnam()、sys_get_temp_dir()或硬编码的/tmp路径 - 如果只是缩放后直接
echo输出（如header('Content-Type: image/jpeg'); imagejpeg($img);），则无临时文件，无需清理 - GD 库本身不管理临时文件生命周期，PHP 也不会替你回收
imagedestroy() 不等于 unlink()，两者作用完全不同
imagedestroy() 释放的是 GD 图像资源内存，对磁盘上的文件毫无影响；unlink() 才是删除物理文件的操作。混淆这两者是最常见的清理失效原因。
立即学习“PHP免费学习笔记（深入）”；
典型错误写法：
$tmp = tempnam(sys_get_temp_dir(), 'img_'); imagejpeg($img, $tmp); imagedestroy($img); // ✅ 内存释放了，但 $tmp 文件还躺在磁盘上！ // ❌ 忘了 unlink($tmp)
- 必须在
imagedestroy()后（或前）显式调用unlink($tmp) - 建议用
try/finally包裹，确保异常时也能清理：try { ... } finally { if (file_exists($tmp)) unlink($tmp); } - 注意
unlink()失败会触发 warning，可加@unlink($tmp)抑制（但应先检查file_exists()）
批量任务中临时文件残留的排查与定时回收
当图像处理被封装进队列任务（如 Laravel Horizon、Supervisor 管理的 worker）时，单次请求结束不等于进程退出，register_shutdown_function() 不可靠，临时文件极易遗漏。
- 不要依赖 PHP 请求结束自动清理 —— CLI 进程可能长驻，
$_SERVER['REQUEST_TIME_FLOAT']在 CLI 下不可用 - 给临时文件加时间戳前缀，例如
tempnam(sys_get_temp_dir(), 'img_'.date('Ymd_His').'_')，便于后续按时间筛选 - 部署级清理推荐用系统 cron，每小时执行：
find /tmp -name 'img_*' -mmin +60 -delete 2>/dev/null - 避免用
glob('/tmp/img_*')在 PHP 中遍历清理 —— 并发高时可能误删其他进程刚创建的文件
临时文件路径权限、NFS 挂载点的 unlink 行为、SELinux 上下文限制，都可能导致 unlink() 静默失败。上线前务必在目标环境验证清理逻辑是否真实生效。
