必须调用imagedestroy()，因为GD图像资源不走PHP引用计数回收路径，GC不自动清理，循环中遗漏会导致内存线性暴涨直至OOM。
imagecreatefromjpeg() 后必须调用 imagedestroy()
GD 库创建的图像资源不会自动释放，哪怕变量被 unset 或函数返回，内存仍被占用。循环中反复调用 imagecreatefromjpeg() + imagecreatetruecolor() 而不销毁，是批量缩放 JPG 时内存线性暴涨的主因。
关键操作不是“等脚本结束”，而是“用完立刻清”：
-
imagedestroy()必须在每次处理完成后显式调用，参数为对应图像资源句柄 - 即使中间出错（如
imagecopyresampled()失败），也要在catch或finally块里确保销毁 - 不要依赖
__destruct()—— GD 资源不走 PHP 的引用计数回收路径，GC 不管它
避免在循环内重复创建资源句柄
常见错误是把 imagecreatetruecolor() 放在循环里，每次生成新画布。哪怕目标尺寸一致，也会为每个图像分配独立内存块，叠加后迅速突破 memory_limit。
更轻量的做法：
- 提前创建一次目标画布（
$dst = imagecreatetruecolor($w, $h)），循环中复用 - 每次迭代前用
imagefilledrectangle($dst, 0, 0, $w, $h, $bg)清空画布，比重建快且省内存 - 若需不同尺寸，按尺寸分组预建几个画布，而非每图一建
memory_limit 临时放宽要带边界控制
图像处理确实需要更高内存上限，但直接全局设 memory_limit = 1G 是危险操作。CLI 和 Web 场景下应分层控制：
- 脚本开头用
ini_set('memory_limit', '512M')，仅影响当前请求，且建议加判断：if (ini_get('memory_limit') !== '-1') ini_set(...) - CLI 批量处理时，用
php -d memory_limit=768M resize.php启动，不污染 Web 配置 - PHP-FPM pool 级配置（
www.conf中php_admin_value[memory_limit] = 512M）比改php.ini更安全 - 绝对不要设成
-1—— 它绕过 Zend 内存检查，但底层 malloc 仍会失败，报错更难定位
大图缩放前先检查原始尺寸与压缩比
一张 8000×6000 的 JPG，即使目标只有 200×150，GD 仍需将全图解码进内存（RGB 每像素 3 字节 → 约 144MB 仅解码阶段）。盲目缩放等于主动触发 OOM。
真正有效的前置动作：
- 用
getimagesize($path)先读宽高，跳过超限原图（如 >5000px）或打日志告警 - 对 JPEG 可尝试
exif_read_data($path, 'COMPUTED')获取缩略图（COMPUTED.Thumbnail.FileType），优先用它替代全图解码 - 考虑降级方案：超大图转用
exec('convert -resize 200x150 '.$path.' '.$out)委托 ImageMagick，它内部流式处理更省内存
最常被忽略的一点：GD 图像资源释放不是“可选项”，而是“必填项”。哪怕你调大了 memory_limit，只要漏掉一次 imagedestroy()，下次循环就多占几 MB —— 积少成多，直到某次刚好卡在临界点崩掉，而错误堆栈里根本看不到资源泄漏痕迹。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
