gd扩展是使用intervention/image等php图像处理包的硬性前提，需先通过php -m确认安装，再按系统配置；intervention/image默认用gd驱动，但webp/avif支持依赖php≥8.1及gd编译选项；原生gd函数更轻量但易出错，需严格校验输入、管理资源、注意参数顺序与路径规范。
composer 安装图像处理包时，ext-gd 是硬性前提
不装好 GD 扩展，任何基于 gd 的 PHP 图像包（比如 intervention/image）都跑不起来——不是报错“class not found”，就是运行时报 Call to undefined function imagecreatefromstring()。Composer 只管下载代码，不管底层扩展是否存在。
实操建议：
- 先在终端执行
php -m | grep gd，确认输出里有gd；没有就别急着composer require - linux（debian/ubuntu）：装扩展用
sudo apt install php-gd，然后重启 Web 服务（如sudo systemctl restart apache2或sudo service php8.2-fpm restart） - macos（Homebrew + PHP）：用
brew install php@8.2-gd（版本号按你实际 PHP 版本调整），再检查php.ini是否已自动加载extension=gd.so - windows：打开
php.ini，取消;extension=gd前的分号，保存后重启 Apache/nginx
intervention/image 是最常用、也最容易踩坑的图像处理包
它封装了 GD 和 Imagick，但默认只启用 GD；一旦你机器上 GD 缺功能（比如不支持 WebP），它不会自动降级或报明确错误，而是静默失败或抛出模糊异常。
实操建议：
- 安装命令是
composer require intervention/image，别加--dev（除非你确定只在命令行工具里用） - 初始化时必须显式指定驱动：
$image = InterventionImageImageManager::imagick()或::gd()；不传参数会按环境自动选，但自动逻辑不可靠 - GD 驱动下，
webp、avif等格式读写需要 PHP ≥ 8.1 且 GD 编译时启用了对应支持，否则imagecreatefromwebp()直接不存在 - 常见错误现象：
Unsupported image type—— 八成是 GD 不支持该格式，不是包的问题
不用 intervention/image？直接调用 gd 函数更轻量，但得自己兜底
如果你只做缩略图、水印、简单裁剪，原生 gd 函数反而更快、无依赖、不占内存。但 PHP 的 GD 函数命名反直觉、参数顺序混乱，容易写错。
实操建议：
- 创建资源前务必检查输入：
getimagesize($path)返回false就别调imagecreatefromjpeg()，否则警告变致命错误 - 所有
imagecreatefrom*函数返回资源（Resource），不是对象，不能链式调用；用完记得imagedestroy($img)防内存泄漏 -
imagecopyresampled()是缩放核心，但第 5–6 参数是「源图宽高」，第 7–8 是「目标图宽高」——参数顺序和直觉相反，错一个就拉伸变形 - 中文水印要用
imagettftext()，但字体路径必须是服务器绝对路径（__DIR__ . '/font.ttf'），相对路径大概率失败
PHP 8.3+ 用户注意：gd 扩展行为有微小但关键变化
新版 GD 对无效图像数据更敏感，比如 JPEG 文件末尾多几个空字节，旧版能容忍，8.3+ 会直接让 imagecreatefromjpeg() 返回 false。
实操建议：
- 读图前先用
finfo_open(FILEINFO_MIME_TYPE)校验 MIME 类型，别光看文件后缀 - 对用户上传的图，加一层
exif_imagetype($path) === IMAGETYPE_JPEG再进 GD 函数 - 错误处理别只靠
@抑制警告——它不抑制致命错误，也不捕获 GD 内部的资源创建失败 - 如果项目需长期兼容不同 PHP 版本，建议把 GD 操作包一层 try/catch + fallback 日志，而不是假设“只要没报错就成功”
GD 扩展本身不提供高级语义（比如“生成圆角头像”），所有“智能”操作都要自己算坐标、掩码、混合模式。这点容易被包装库的文档带偏——看着一行代码搞定，背后全是条件分支和边界判断。