GD库resize后quality不生效，因JPEG需用imagejpeg($img,$path,$quality)显式传参（1–100），PNG不支持quality参数，WebP推荐使用imagewebp($img,$path,80)。
GD 库 resize 后 quality 参数不生效？
PHP 用 imagejpeg() 或 imagepng() 保存压缩图时，如果文件大小没变小，大概率是没传 quality 参数，或传了但类型不对。JPEG 压缩靠 imagejpeg($img, $path, $quality) 的第三个参数（1–100），PNG 则不支持 quality——imagepng() 没这个参数，强行传会报 Warning，且无效。
常见错误写法：imagepng($img, $path, 75) → PHP 警告“Wrong parameter count”，图片仍以默认无压缩方式保存。
- JPEG：必须显式传
imagejpeg($img, $path, 75)，低于 80 才有明显体积下降 - PNG：改用
imagepng($img, $path, PNG_NO_FILTER)或先转成 JPEG 再压 - WebP：优先选它，
imagewebp($img, $path, 80)支持 quality，体积通常比 JPEG 小 25%+
缩放 + 压缩必须分两步做
只调 imagecopyresampled() 缩放但不重设画布尺寸，或缩放后没重新创建真彩色图像，会导致颜色失真、体积反增。尤其处理 PNG 透明图时，漏掉 imagesavealpha() 和 imagealphablending()，会生成带黑底的假 PNG，体积暴增。
正确流程：
立即学习“PHP免费学习笔记（深入）”；
- 用
getimagesize()获取原图宽高和类型 -
imagecreatefromjpeg/png/webp()创建资源，注意函数名要匹配类型 -
imagecreatetruecolor($new_w, $new_h)新建目标画布 -
imagecopyresampled()把原图复制进新画布 - 对 PNG：加
imagealphablending($new_img, false)和imagesavealpha($new_img, true) - 最后用对应格式函数保存，并传 quality（JPEG/WebP）或过滤选项（PNG）
file_get_contents + imagecreatefromstring 绕过临时文件
如果上传的是 base64 或内存中二进制数据（比如 API 接收的图片流），别先写临时文件再读——多一次 I/O，慢且易出权限错误。直接用 imagecreatefromstring() 解码二进制内容。
示例片段：
$data = file_get_contents('php://input');
$img = imagecreatefromstring($data);
if (!$img) {
throw new Exception('Invalid image data');
}
// 后续缩放+保存逻辑...
注意：imagecreatefromstring() 不识别 MIME 头，若数据含 base64 前缀（如 data:image/jpeg;base64,...），得先用 explode(',', $data)[1] 截掉，再 base64_decode()。
memory_limit 和 max_execution_time 容易爆掉
大图（如 5000×3000）在 GD 中解码后，内存占用≈宽×高×4 字节（RGBA）。一张 4000×3000 图就要约 48MB 内存；PHP 默认 memory_limit=128M，并发几张就超限。同时 GD 处理耗时明显，max_execution_time=30 在低配机器上可能不够。
- 上线前用
ini_set('memory_limit', '256M')临时提限（仅当前请求） - 加
set_time_limit(60)防止超时中断 - 更稳妥的做法：用
getimagesize()先检查尺寸，超 3000px 的直接拒绝或走异步队列 - 生产环境建议换
Imagick扩展，内存控制更好，还支持渐进式 JPEG 和更多压缩策略
真正卡住的不是代码怎么写，而是没预估好原始图的尺寸和格式边界——用户随手传张手机直出图，就可能让整个流程崩在内存分配那步。
