GD库处理图像必须解决三大问题：PNG水印透明度丢失需用imagecopy+imagealphablending+imagesavealpha组合；缩略图变形因未正确加载源图及分配颜色空间；不调用imagedestroy会导致内存泄漏，因GD绕过PHP memory_limit 且不被GC回收。
GD 库在 PHP 图像处理中不是“能用就行”，而是必须直面三个现实问题：水印叠加后透明度丢失、缩略图拉伸变形、imagecreatetruecolor 频繁调用导致内存不释放。这些问题在高并发生成验证码或批量处理用户上传图时会集中爆发。
为什么 imagecopymerge 无法正确叠加 PNG 水印？
常见现象是 PNG 水印的 alpha 通道被强制压平，边缘发灰或出现白边——这不是函数 bug，而是它只支持整数级透明度（0–100），且不识别源图 alpha 通道。
- 真正要保留 PNG 原始透明度，必须用
imagecopy+imagealphablending+imagesavealpha组合 - 关键顺序不能错：先关闭目标图混合（
imagealphablending($dst, false)），再启用保存 alpha（imagesavealpha($dst, true)），最后复制 - 如果水印本身是 24 位真彩色 PNG，但目标图是调色板模式（如用
imagecreate创建），复制必然失败；必须统一用imagecreatetruecolor
缩略图变形或裁剪失控的根源在哪？
多数人直接套用宽高比计算后传给 imagecopyresampled，却忽略两个硬约束：源图是否可读、目标画布是否已分配正确颜色空间。
- 用
getimagesize判断格式后，必须用对应函数加载图像：imagecreatefromjpeg/imagecreatefrompng/imagecreatefromgif，混用会导致黑图或警告 - 创建缩略图画布时，若未用
imagecreatetruecolor而用imagecreate，则 PNG 透明背景会变黑色，GIF 动画首帧可能失真 - 等比缩放逻辑建议封装为函数，输入原图路径、目标宽高、是否强制裁剪（
crop）三参数，避免每次重复判断
imagedestroy 不调用，内存真的不释放吗？
是的，而且后果比想象中严重：GD 使用 Zend 内存管理机制，绕过 memory_limit 限制，泄漏的图像资源不会被 GC 自动回收。
立即学习“PHP免费学习笔记（深入）”；
- 每个
imagecreatetruecolor或imagecreatefromxxx返回的资源，都必须配对调用imagedestroy，哪怕后续抛出异常也要在finally块中执行 - PHP 8.0+ 支持
gdimage类型提示，但不改变资源生命周期；unset($image)不等于销毁，只是断开变量引用 - 批量处理时，建议每处理 10 张图后主动调用
gc_collect_cycles()，尤其在 CLI 模式下长时间运行脚本
最易被忽略的一点：GD 的图像操作全部在内存中完成，一张 4000×3000 的 JPEG 解码后可能占用 36MB 内存（RGB 各占 1 字节 × 宽 × 高），远超原始文件大小。别只盯着 memory_limit，得盯住 gd_info()['memory_limit'] 返回的实际可用值——它可能为空，意味着完全依赖系统剩余内存。
