formfile() 返回的临时文件路径不能直接用于图像处理，因其在请求结束时被清理，且gd/imagick可能无读取权限或解码失败；必须先 move_uploaded_file() 保存，再校验、加载、缩放、销毁资源。
直接用 echo.Context.FormFile() 拿到文件后不能立刻传给图像库处理——它只是个临时路径引用，没保存前 GD 或 Imagick 极易读取失败，尤其在并发或大文件场景下。
为什么 FormFile() 返回的 tmp_name 不能直接喂给 Image::make() 或 imagecreatefromjpeg()
因为 FormFile() 只返回一个指向临时文件的指针，PHP 请求生命周期结束时该临时文件会被自动清理。如果跳过 move_uploaded_file() 或等效保存步骤就直接调用图像函数，大概率触发 NotReadableException（Intervention）或返回 false（GD），且无明确错误提示。
- 临时文件权限可能受限，GD/Imagick 进程无读取权
- 某些 Swoole 或 RoadRunner 环境中，
tmp_name在多次请求间复用，内容已覆盖 - WebP/AVIF 格式需对应扩展支持，但 GD 默认不启用 WebP 解码器，
imagecreatefromwebp()会静默失败
GD 库生成缩略图的最小安全链路（无第三方包）
必须分三步：接收 → 保存 → 加载处理。不能省略中间保存环节。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 先用
move_uploaded_file($file->TmpName, $targetPath)把文件落地到可写目录（如uploads/original/） - 用
getimagesize($targetPath)校验是否真为有效图像，避免上传恶意文件伪装成图片 - 根据
$type调用对应加载函数：imagecreatefromjpeg()、imagecreatefrompng()、imagecreatefromwebp()（确认扩展已启用） -
imagecopyresampled()参数顺序极易填反：第7–8位是目标宽高，第9–10位是原图宽高；填错导致黑图或空白输出 - 保存后务必调用
imagedestroy($src)和imagedestroy($thumb)，否则内存泄漏
用 Intervention Image 时绕不开的三个硬性检查点
不是装了包就能用，Laravel 风格的门面写法在 Echo 中不适用，得手动实例化并传绝对路径。
-
Image::make()必须接收服务器本地绝对路径，不能是 URL 或相对路径（如./uploads/xxx.jpg） - 确保
storage/app/目录存在且 Web 进程有写权限；缩略图路径建议与原图分离，如storage/app/avatars/thumb/ - PHP 8.1+ 下，
move_uploaded_file()失败后若未判断返回值就调Image::make()，会抛NotReadableException，必须前置校验$file->Size > 0 && $file->Error === 0
最常被忽略的是 GD 对 WebP 的支持状态和 imagecopyresampled() 的参数顺序——这两个点一旦出错，缩略图要么完全空白，要么尺寸错乱，但错误日志里往往只显示 “failed to open stream”，根本看不出是解码失败还是坐标填反。
