GD库缩略图问题根源在于尺寸计算错误与资源管理缺失：等比缩放需手动计算裁剪坐标，模糊因插值精度不足，WebP需编译支持，内存溢出因未及时销毁图像资源。
GD库生成缩略图时图片变形或裁剪错位
常见现象是缩略图拉伸、内容被切掉一半，或者居中偏移——根本原因在于没区分「等比缩放」和「强制拉伸」两种模式。imagecopyresampled() 本身不负责裁剪逻辑，只做像素重采样；你传进去的源区域（$src_x, $src_y, $src_w, $src_h）和目标区域（$dst_w, $dst_h）尺寸不匹配，就必然出问题。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 先用
getimagesize()拿到原图宽高，再按目标比例算出「等比缩放后最大可容纳尺寸」 - 若需居中裁剪（比如头像类缩略图），要手动计算源图裁剪起点：
$src_x = ($orig_w - $src_w) / 2，$src_y = ($orig_h - $src_h) / 2 - 别直接用目标宽高当
imagecopyresampled()的$dst_w/$dst_h，它们必须和你要创建的目标画布一致（即imagecreatetruecolor($dst_w, $dst_h)的参数）
缩略图模糊、锯齿严重，尤其文字边缘发虚
这是 GD 默认插值算法太粗糙，加上没开启抗锯齿或没选对重采样方式导致的。PHP 7.4+ 的 GD 虽支持 IMG_FILTER_SMOOTH，但它对缩略图无效；真正起作用的是 imagecopyresampled() 自身的质量控制——它依赖源/目标区域的尺寸精度，也受图像格式影响。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确保源图不是超大尺寸（比如 8000×6000），先用
imagecopyresized()快速缩小到 2–3 倍目标尺寸，再用imagecopyresampled()二次采样，效果明显提升 - JPEG 输出前务必调用
imagejpeg($img, null, 95)，第三个参数不能省，默认是 75，细节损失大 - PNG 图像要禁用调色板：
imagealphablending($thumb, false)+imagesavealpha($thumb, true)，否则透明通道会参与插值，造成边缘灰边
生成 WebP 缩略图时提示「Call to undefined function imagewebp()」
不是你代码写错了，是 PHP 编译 GD 库时没带 WebP 支持。Ubuntu/Debian 下装了 libwebp-dev 也不代表 PHP 就自动启用了——得重新编译 GD，或换用已启用 WebP 的 PHP 版本（如 Ubuntu 22.04+ 的 php8.1-gd 默认支持）。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 运行
php -r "print_r(gd_info());"查看输出中webp support是否为true - 不支持 WebP 时，别硬套
imagewebp()，改用imagejpeg()或imagepng()并在响应头里设Content-Type: image/webp是自欺欺人 - 线上环境优先检测函数存在性：
if (function_exists('imagewebp')) { ... }，避免 fatal error
内存溢出或超时，尤其处理批量图片时
GD 图像资源不释放，是 PHP 图片处理最隐蔽的内存黑洞。一个 5MB 的 JPEG 解码后在内存中可能占 60MB（RGB 各占 1 字节 × 宽 × 高），而 imagedestroy() 不调，资源就一直挂着。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 每张图处理完立刻销毁：
imagedestroy($src_img); imagedestroy($thumb);，别等脚本结束 - 批量任务加
gc_collect_cycles()强制回收，尤其循环中反复imagecreatefromxxx() - 用
memory_get_usage(true)在关键点打点，确认是否真由 GD 引起；有时是错误地把整张图 base64_encode 后存进变量里，那才是真爆内存
GD 生成缩略图真正难的不是调哪个函数，而是每一步都要自己算尺寸、自己管内存、自己判格式支持。很多人卡在“为什么明明代码跑通了，图就是糊的”，答案往往藏在 imagecopyresampled() 前那几行尺寸计算里，而不是函数本身。
