最稳缩放方案是用golang.org/x/image/draw：先decode转为*image.rgba，再预分配目标图并选合适算法（approxbilinear或catmullrom），最后用jpeg.encode/png.encode保存并设质量参数。
用 golang.org/x/image/draw 缩放图片最稳
标准库不支持图像缩放，硬上 image 包会卡在“怎么画到新尺寸 canvas 上”这一步。必须引入 golang.org/x/image/draw —— 它是 Go 官方维护的扩展包，专为像素级绘制设计，缩放逻辑可靠、无隐藏内存泄漏。
常见错误是直接用 draw.CatmullRom 处理大图却忘了预分配目标 *image.RGBA，结果运行时 panic：draw: invalid destination image。这是因为目标图尺寸和源图不匹配，或未初始化。
- 先用
image.NewRGBA按目标宽高创建空白图，别复用源图的 bounds - 缩放算法选
draw.ApproxBiLinear（快且够用）或draw.CatmullRom（质量高但慢 3–5 倍） - 注意：JPEG 解码后是
*image.YCbCr，必须先转成*image.RGBA再传给draw.Draw，否则报错draw: unknown image type
读取 JPEG/PNG 后记得调用 Decode，别直接传 os.File
很多新手把打开的 *os.File 直接塞进 draw.Draw，结果崩溃或输出全黑——因为 draw 不负责解码，只做像素搬运。必须先用对应格式的 Decode 函数把二进制流转成内存图像。
典型错误现象：缩放后图片变紫、偏色、尺寸错乱，往往是因为用了 jpeg.Decode 但没处理 YCbCr 到 RGBA 的转换。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- JPEG：用
jpeg.Decode→ 得到*image.YCbCr→ 调用image.NewRGBA并用draw.Draw复制过去 - PNG：用
png.Decode→ 通常直接返回*image.NRGBA或*image.RGBA，可直传 - 统一做法：不管源类型，最后都转成
*image.RGBA，避免后续操作出错
resize 第三方包能省事，但要注意依赖和裁剪逻辑
如果项目允许加依赖，github.com/nfnt/resize 是最常用的轻量缩放库，封装了采样和内存管理。但它默认行为是「等比缩放+居中裁剪」，不是单纯拉伸——这点极易被忽略，导致图片被意外切掉边缘。
常见坑：传入 800x600 却得到一张 600x600 的图，原因是它按短边优先缩放，再从中心裁出目标尺寸。
- 要严格按指定宽高拉伸，必须加
resize.Lanczos3+resize.AnchorCenter+ 显式设置resize.Fill模式 - 该包不支持 WebP，遇到就只能切回官方
x/image方案 - Go 1.21+ 用户注意：它尚未适配
io/fs接口，读文件还得用os.Open
缩放后保存 PNG/JPEG 要手动写 Header，别漏掉 jpeg.Encode 的 *jpeg.Options
缩放完的 *image.RGBA 是内存对象，不保存就没了。保存时最容易忘的是 JPEG 的压缩质量控制，不设选项就用默认最低质量（约 75），肉眼可见模糊；PNG 则可能因没设 png.Encoder 的 CompressionLevel 导致体积翻倍。
- JPEG：用
jpeg.Encode(w, img, &jpeg.Options{Quality: 90})，值范围 0–100，低于 80 就明显失真 - PNG：用
png.Encode(w, img)即可，但若想压体积，需传&png.Encoder{CompressionLevel: flate.BestSpeed} - 务必检查
os.Create返回的*os.File是否为nil，否则保存失败却无提示
真正麻烦的从来不是“怎么缩”，而是“缩完怎么不出错地落地”。每一步的类型转换、内存分配、编码参数，漏一个就卡在 CI 里跑不通。尤其线上服务处理用户上传图时，YCbCr 和 RGBA 的隐式混用、JPEG 质量参数缺失、目标图未预分配——这三个点占了 80% 的生产问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
