生成缩略图前须检查GD扩展是否启用，优先用imagecopyresampled()并正确传参，PNG需处理alpha通道，及时调用imagedestroy释放内存。
缩略图生成前必须检查 GD 扩展是否启用
PHP 生成缩略图依赖 GD 库，但不是所有环境默认开启——尤其是 Docker 容器、某些云函数或精简版 PHP（如 Alpine 镜像）。直接调用 imagecreatetruecolor() 却报 Call to undefined function imagecreatetruecolor()，基本就是这个原因。
验证方式很简单：php -m | grep gd（命令行）
或在 Web 环境中写个 phpinfo(); 页面，搜索 “gd” 看是否显示 “enabled”。
- 没启用？Debian/Ubuntu 上装
php-gd，CentOS/RHEL 是php-gd或php74-php-gd（版本号需匹配） - Docker 用户注意：Alpine 需额外装
php7-gd和底层依赖libpng-dev libjpeg-turbo-dev，否则即使扩展加载了，imagecreatefromjpeg()也会静默失败 - Windows 下 PHP 自带 GD，但若用非官方二进制包（如 XAMPP 旧版），可能缺 JPEG 支持——此时
imagecreatefromjpeg()返回false，却无明确错误提示
用 imagecopyresampled() 而不是 imagecopyresized()
缩略图质量差、边缘发虚、文字模糊？大概率用了 imagecopyresized()。它只做最近邻重采样，简单粗暴地丢像素；而 imagecopyresampled() 支持双线性插值，能保留更多细节，是实际项目中的唯一合理选择。
关键区别不在“要不要用”，而在“怎么传参”——四个尺寸参数顺序容易搞反：
imagecopyresampled($dst_img, $src_img, 0, 0, 0, 0, $dst_w, $dst_h, $src_w, $src_h)- 后四参数是「源图裁剪区域」的宽高，不是目标图尺寸；如果填错（比如把
$dst_w当成第 7 位却塞进了$src_w），图像会拉伸变形或只显示左上角一小块 - 务必先用
getimagesize()拿到原始宽高，再按比例计算目标尺寸，别硬写死200, 150—— 否则正方形图变扁，头像被压成饼
透明 PNG 缩略图背景变黑？记得处理 alpha 通道
对 PNG 图片调用 imagecreatetruecolor() 创建画布后，默认是黑色背景。如果原图带透明度，缩略图里透明区域就变成黑块，而不是透出网页背景。
立即学习“PHP免费学习笔记（深入）”；
必须显式开启保存 alpha 并填充透明色：
- 创建目标画布后立即加：
imagealphablending($dst_img, false)和imagesavealpha($dst_img, true) - 不要用
imagefill($dst_img, 0, 0, $color)填背景色，这会覆盖 alpha 信息 - 如果最终要输出为 JPG，那就没法保留透明——得提前决定：要么强制转白底（
imagefilledrectangle($dst_img, 0, 0, $w, $h, $white)再 copy），要么坚持输出 PNG - 注意：
imagecreatefrompng()本身不自动保留 alpha，老版本 PHP 还需配合imagealphablending($src_img, false)，但 PHP 7.4+ 已默认支持，可省略
生成后记得释放内存，尤其批量处理时
GD 图像资源不释放，每张图吃几 MB 内存，循环处理 20 张就可能触发 Allowed memory size exhausted。这不是警告，是直接崩。
- 每次生成完立刻调用
imagedestroy($src_img)和imagedestroy($dst_img) - 别以为“脚本结束自动回收”就安全——CLI 模式下确实会，但 Web SAPI（如 FPM）中资源可能跨请求残留，尤其用了 opcache 或常驻进程时
- 更稳妥的做法：把缩略图逻辑封装成函数，用
try/finally包裹，确保imagedestroy必然执行，哪怕中间imagecopyresampled()失败返回false - 调试时可用
memory_get_usage(true)打点观察，一张 2000×1500 的 JPG 解码后内存占用常超 8MB
