应上传时直接压缩图片，而非保存后再处理；使用GD或Imagick在moveTo()前加载并压缩原图，通过资源句柄或二进制流写入，按MIME类型与用途分策略设定质量及格式，注意扩展启用与内存限制。
上传时直接压缩图片，别等存完再处理
ThinkPHP 默认的 upload() 方法只负责移动文件，不带压缩逻辑。想节省空间和带宽，必须在保存前用 GD 或 Imagick 缩放、重编码。常见错误是先 moveTo() 再读取文件二次处理——这多一次 I/O，还可能因并发导致临时文件被删。
- 在
think\File实例拿到后、调用moveTo()前，用imagecreatefromxxx()（GD）或new \Imagick()加载原始资源 - 压缩后不写回磁盘，而是用
ob_get_contents()或Imagick::getImageBlob()拿到二进制流，再传给moveTo()的第二个参数（支持资源句柄或字符串内容） - 注意 GD 对 WebP 支持依赖 PHP 编译选项，
imagewebp()在 PHP 7.0+ 才稳定；Imagick 则需服务器装了 libwebp 才能处理 WebP
GD 和 Imagick 怎么选：看场景，不是看名字
GD 轻量、内置、够用；Imagick 功能强、内存占用高、易出错。不是“Imagick 更高级就该用它”。实际项目里，90% 的头像/商品图压缩，GD 完全胜任；只有需要批量裁切+加水印+CMYK 转 RGB 这类复合操作时，才值得引入 Imagick。
- GD 处理大图（如 >5000×5000）容易触发
Allowed memory size exhausted，因为图像数据全在内存；Imagick 可通过setResourceLimit(\Imagick::RESOURCETYPE_MEMORY, 128 * 1024 * 1024)控制上限 - GD 的
imagejpeg()第三个参数默认是 75，但 ThinkPHP 上传组件不会自动继承这个质量值——你得手动指定，否则可能存出 100% 质量的巨图 - Imagick 的
setImageCompressionQuality(80)必须在readImage()之后、writeImage()之前调用，顺序错了会无效
压缩参数怎么设才不糊又不大
盲目设 quality=60 很危险：文字截图、线条图一压就锯齿，而风景照压到 85 也看不出差别。关键不是固定数值，而是按 MIME 类型和用途分策略。
- 用户头像：
image/png→ 转image/jpeg+quality=82；image/gif→ 保持 GIF，但用imagegif()前先imagepalettetotruecolor()防色块 - 商品主图：
image/jpeg原图直接重存，quality=88；如果是image/webp，别转格式，用imagewebp($img, null, 85)保持原格式优势 - 所有缩放统一用双三次插值：
imagecopyresampled()（GD）或resizeImage(, , \Imagick::FILTER_LANCZOS, 1)（Imagick），避免imagecopyresized()产生的模糊
ThinkPHP 6.x 中绕不开的路径和扩展检查
本地测试 OK，上线报 Call to undefined function imagecreatefromjpeg()？不是代码问题，是 PHP 配置漏了。GD 和 Imagick 都不是默认全开的扩展。
立即学习“PHP免费学习笔记（深入）”；
- 运行
php -m | grep -i gd或php -m | grep -i imagick确认扩展已加载；没输出就去 php.ini 开extension=gd或extension=imagick - GD 还要检查是否支持 JPEG：
var_dump(gd_info()['jpeg_support'])必须为true；Imagick 则运行(new \Imagick())->queryFormats('JPEG')看返回是否非空 - ThinkPHP 的
File类对路径很敏感：如果用$file->validate(['size'=>2048000])，记得单位是字节，不是 KB；验证失败时抛的是think\exception\ValidateException，不是UploadException
最常被跳过的点：GD 的 memory_limit 不光看 PHP 配置，还要算图像内存占用——一张 8000×6000 的 PNG 解码后约占用 192MB 内存（宽×高×4 字节），远超默认 128M。别只改代码，顺手查下 ini_get('memory_limit')。
