intervention image 上传后生成缩略图需先用 laravel request()->file() 接收并保存原始图至 storage/app/avatars/original/，再通过 storage::path() 转绝对路径供 image::make() 加载，调用 fit(200,200)->save() 生成缩略图存至 thumb/ 目录；须校验文件有效性、扩展支持及 gd/imagemagick 配置，并安全替换旧头像。
Intervention Image 上传后直接生成缩略图的典型写法
Intervention Image 本身不处理上传，它只负责图像处理；头像上传必须先用 Laravel 的 request()->file() 接收文件，再交给 Image::make() 处理。常见错误是试图把未保存的临时文件路径直接传给 Image::make() 却没检查是否成功读取——尤其在 PHP 8.1+ 中，move_uploaded_file() 失败后仍调用 Image::make() 会抛出 Intervention\Image\Exception\NotReadableException。
推荐做法是：先保存原始图，再用绝对路径加载并生成缩略图。这样可避免流式处理中的内存或权限问题。
- 原始图建议存到
storage/app/avatars/original/，缩略图存到storage/app/avatars/thumb/ - 使用
Storage::putFileAs()保存原始图，返回的是相对路径（如avatars/original/abc.jpg），需用Storage::path()转为绝对路径供 Intervention 加载 -
Image::make()后必须显式调用->save()，否则无输出；不指定格式时默认按源图类型保存
$file = $request->file('avatar');
$originalPath = 'avatars/original/' . uniqid() . '.' . $file->extension();
Storage::putFileAs('avatars/original', $file, $originalPath);
$absPath = Storage::path($originalPath);
$img = Image::make($absPath);
$img->fit(200, 200)->save(Storage::path('avatars/thumb/' . $originalPath));
Laravel 10+ 中 Image::make() 读取失败的三个高频原因
不是所有上传文件都能被 Intervention 正确解析。最常卡在「能上传、但生成缩略图时报错」，本质是输入源不可读或不支持。
- 上传文件类型被服务器拦截（如 Nginx 配置了
client_max_body_size或 PHPupload_max_filesize过小），导致$file->isValid()返回 false，但很多人没校验就直接进Image::make() - 用户上传了 WebP 或 AVIF 格式，而当前 GD 扩展未启用对应解码器（GD 默认不支持 WebP，需编译时加
--with-webp-dir）；ImageMagick 后端则更稳定，但需确认imagick扩展已启用 - 临时文件在
request()->file()调用后已被 Laravel 自动清理（极少见，多见于 Swoole 环境或自定义中间件提前读取 body）
验证方式很简单：dd($file->getMimeType(), $file->getSize())，如果 getSize() 是 0 或 getMimeType() 是 application/octet-stream，基本就是上传中途断了或被拦截了。
缩略图尺寸与 fit()/resize() 的实际差异
fit(200, 200) 和 resize(200, 200) 看似一样，但行为完全不同：前者等比裁剪居中，后者强制拉伸变形。头像场景几乎 always 要 fit()，否则人脸会被压扁。
-
fit(200, 200, function ($constraint) { $constraint->upsize(); })可确保小图也能放大填满，但注意放大会模糊，建议配合->sharpen(10) - 若要保留原图比例并加背景（比如生成圆形头像），得用
resizeCanvas()，而不是fit() - GD 后端对透明 PNG 处理较弱，
fit()后可能丢 Alpha 通道；改用 ImageMagick 后端可解决：Image::configure(['driver' => 'imagick'])
如何安全地替换旧头像并清理原图
用户换头像时，不能只存新图，还得删旧图——否则磁盘会慢慢撑爆。Laravel 的 Storage::delete() 不会报错，但删不存在的路径也没提示，容易误以为删成功了。
- 查数据库拿到旧头像路径（如
users.avatar_path），用Storage::exists($oldPath)先判断是否存在再删 - 原始图和缩略图路径要分别删，比如旧值是
avatars/original/xyz.jpg，就得同时删avatars/original/xyz.jpg和avatars/thumb/xyz.jpg - 不要用
unlink()直接删物理路径，绕过 Laravel Storage 抽象层会导致云存储（如 S3）失效
真正容易被忽略的是事务边界：如果数据库更新失败（比如用户名唯一约束冲突），但头像文件已经删了，就会出现「头像丢了、用户信息却没更新」的不一致状态。稳妥做法是先存新图、再更新数据库、最后删旧图，并把删旧图逻辑放到队列里异步执行，避免主流程阻塞。
