必须显式调用imagedestroy()释放GD资源，否则内存持续累积导致崩溃；imagecopyresampled()参数错位会引发隐式资源复制加剧内存消耗。
imagecreatefromjpeg() 后不调用 imagedestroy() 必然内存暴涨
GD 库加载图片后返回的是资源句柄，不是普通变量。PHP 的垃圾回收不会在循环中立即释放这类 GD 资源，哪怕你把 $img 设为 null 或重新赋值，底层像素数据仍在内存里堆积。批量处理几十张 2MB 的 JPG 时，很容易触发 Fatal error: Allowed memory size of X bytes exhausted。
必须在每次处理完一张图后，显式调用 imagedestroy() —— 不仅要销毁源图，目标图（如 $thumb）也要销毁，只要它不再被后续逻辑使用。
- 错误写法：
imagejpeg($thumb, $outPath);后直接进入下一轮循环 - 正确写法：
imagejpeg($thumb, $outPath); imagedestroy($thumb); imagedestroy($source); - 注意：
imagedestroy()对已销毁的资源多次调用无害，但对false或未成功创建的资源会报 Warning，建议加判断：if ($source) { imagedestroy($source); }
imagecopyresampled() 参数错位会导致隐式资源复制和内存翻倍
这个函数有 10 个参数，顺序极易出错。一旦把源图宽高、目标图宽高或坐标填反，GD 可能内部创建临时缓冲区或重复加载区域，造成单次操作内存占用激增，尤其在循环中放大效应明显。
典型错误是把 imagecopyresampled($dst, $src, ...) 的前两个参数颠倒，或者把源图尺寸传给目标图尺寸参数——这会让 GD 尝试按错误尺寸分配新画布，再失败重试，间接导致资源残留。
立即学习“PHP免费学习笔记（深入）”；
- 务必核对参数顺序：
imagecopyresampled($dst_img, $src_img, $dst_x, $dst_y, $src_x, $src_y, $dst_w, $dst_h, $src_w, $src_h) - 推荐封装成函数，统一计算缩放比例并校验：
if ($src_w - 避免在循环内反复调用
getimagesize()两次（一次取尺寸，一次做判断），它本身会读文件头，虽轻量但累积也有开销
批量处理前不检查 GD 支持格式，JPEG/PNG 混用引发资源泄漏
不同格式需用对应加载函数：imagecreatefromjpeg()、imagecreatefrompng()、imagecreatefromwebp()。如果统一用 imagecreatefromjpeg() 强行打开 PNG，函数返回 false，后续 imagecopyresampled() 会静默失败，而你可能忘了检查返回值，导致 $source 是 false 却仍传给 imagedestroy() —— 这不会释放任何内存，但脚本继续跑，实际资源没建也没毁，等于漏处理。
- 务必用
getimagesize()的第三个返回值$type分支加载：switch($type) { case IMAGETYPE_JPEG: $img = imagecreatefromjpeg(...); break; ... } - PNG 需额外启用 alpha 支持：
imagealphablending($img, false); imagesavealpha($img, true);，否则imagedestroy()前若未设置，部分内存可能无法完全回收 - WebP 在 PHP 7.1 中需确认 GD 编译时启用了 libwebp，否则
imagecreatefromwebp()直接不可用，函数不存在报 Fatal Error
memory_limit 临时调高只是掩耳盗铃，真正瓶颈在资源生命周期
用 ini_set('memory_limit', '512M') 能让脚本跑完，但掩盖了资源管理缺陷。更危险的是，在 CLI 模式下该设置可能无效（取决于 php.ini 的 memory_limit 是否设为 -1 或被 disable_functions 限制），导致行为不一致。
真实瓶颈不在总内存上限，而在单次循环内资源是否及时归还。一个处理 100 张图的脚本，如果每张图峰值占 8MB，但每轮只释放 4MB，到第 50 轮时已吃掉 200MB —— 这就是典型的“内存阶梯式上涨”，imagedestroy() 缺失的直接表现。
- 上线前用
memory_get_usage(true)打点监控：在循环开头、imagecreatefromxxx()后、imagecopyresampled()后、imagedestroy()后各记一次，定位泄漏点 - CLI 环境下优先用
php -d memory_limit=256M script.php启动，比脚本内ini_set()更可靠 - 若仍频繁 OOM，不要硬扛，改用
Imagick：它的readImage()内部流式解析，内存占用通常比 GD 低 30%~50%，且$imagick->clear(); $imagick->destroy();语义更明确
imagedestroy()，就可能让整个批量任务在第 83 张图时突然中断——而日志里只有一行冰冷的 Allowed memory size exhausted。 
