Go标准库无image.Resize，编译报undefined；最稳方案是golang.org/x/image/draw配合显式创建*image.RGBA目标图、尺寸校验及类型转换，避免panic和alpha丢失。
别用 image.Resize——它根本不存在，编译直接报 undefined: image.Resize；也别手写双线性插值，容易在 alpha 通道或边界采样上翻车。最稳路径是 golang.org/x/image/draw + 显式类型转换 + 尺寸校验，其他方案要么不维护、要么默认裁剪、要么静默丢 alpha。
为什么 draw.Draw 会 panic: invalid destination image？
目标图没初始化，或类型不被支持。draw.Draw 要求 dst 是可写且已分配像素内存的图像，比如 *image.RGBA，不能传 nil、*image.NRGBA64 或未调用 image.NewRGBA() 的空指针。
- 必须显式创建：
dst := image.NewRGBA(image.Rect(0, 0, w, h))，不能复用src.Bounds()直接当尺寸用（GIF 可能返回(0,0)-(1,1)） - 目标宽高必须为正：
w > 0 && h > 0，否则运行时 panic - JPEG 解码后是
*image.YCbCr，不能直接当src传给draw.Draw，会报draw: unknown image type
缩放质量与速度怎么选：ApproxBiLinear vs CatmullRom
draw.ApproxBiLinear 是生产环境首选：速度快（比 CatmullRom 快 3–5 倍）、质量够用、不强制预乘 alpha；draw.CatmullRom 虽然理论质量高，但对小图放大易发虚，且要求源图已预乘（*image.NRGBA 最安全），否则边缘灰边明显。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 头像、封面图、列表缩略图 → 用
draw.ApproxBiLinear - 图标、像素画、文字截图 → 改用
draw.NearestNeighbor保锐度 - 别用
draw.BiLinear—— 它不在标准库image/draw中，是第三方包里的旧名，易混淆
透明图缩放后变黑？JPEG 和 PNG 的 alpha 处理差异
PNG 解码通常得 *image.NRGBA（带 alpha），JPEG 是 *image.YCbCr（无 alpha）。如果统一往 *image.NRGBA 目标上 draw，JPEG 会被填黑底——这不是 bug，是色彩模型不兼容的必然结果。
立即学习“go语言免费学习笔记（深入）”；
- 统一目标类型：
dst := image.NewNRGBA(image.Rect(0, 0, w, h)) - JPEG 源图要先垫一层底色：
draw.Draw(dst, dst.Bounds(), image.NewUniform(color.White), image.Point{}, draw.Src)，再 draw 覆盖图像 - 保存为 JPEG 前必须转成
*image.YCbCr，否则jpeg.Encode会静默丢 alpha 并可能色偏 - 别依赖文件后缀判断格式——
xxx.png文件内容可能是 GIF，image.Decode会直接 panic
并发缩放多张图时最常漏掉的两件事
一是多个 goroutine 共用同一块 *image.RGBA.Pix 内存，导致像素错乱；二是 SubImage 返回的是视图而非副本，原图被 GC 或修改后，裁剪结果失效——这两个问题线上跑几天才暴露，排查极难。
- 每个 goroutine 必须创建独立的
dst图像，不能共用变量 - 需要裁剪结果稳定，就别用
img.SubImage(r)，改用image.NewRGBA(r)+draw.Draw复制像素 - 用户上传图务必先用
image.DecodeConfig探尺寸和格式，防大图 OOM
