用golang.org/x/image/draw缩放图片最稳：推荐draw.CatmullRom.Scale，需目标尺寸新建可写RGBA图像，注意color.Model一致、Alpha处理及裁剪须在缩放前完成，并复用Pix底层切片优化性能。
用 golang.org/x/image/draw 缩放图片最稳
Go 原生 image 包不支持缩放，硬写双线性插值容易出错且性能差。直接上 golang.org/x/image/draw 是当前最可靠的选择，它封装了多种重采样算法，也适配所有标准 image.Image 实现。
常见错误是手动创建新 image.RGBA 后忘记调用 bounds() 或填错尺寸，导致黑图或 panic。务必用目标尺寸新建图像，再调用 draw.CatmullRom.Scale(...)（推荐 Catmull-Rom，比 NearestNeighbor 更平滑，比 Bicubic 更快）。
-
draw.NearestNeighbor适合像素风或缩略图预览，速度快但锯齿明显 -
draw.CatmullRom是通用首选，兼顾质量与速度 - 目标图像必须可写（如
image.NewRGBA），不能传入*image.JPEG这类只读解码结果 - 源图和目标图的
color.Model最好一致；若混用color.NRGBAModel和color.RGBAModel，可能丢 alpha 通道
读取和保存时注意格式与 Alpha 通道
缩放后保存为 PNG 或 JPEG 时，png.Encode 和 jpeg.Encode 对 alpha 处理完全不同：PNG 默认保留透明度，JPEG 强制丢弃并填充黑色背景。如果原图带透明，又想存成 JPEG，得先手动合成到白底或黑底。
典型错误是直接把 RGBA 图传给 jpeg.Encode，结果边缘发灰——因为 JPEG 不支持 alpha，jpeg.Encode 会静默忽略 Alpha 通道，但 RGB 值已按原始 alpha 混合过一次（即预乘 alpha），导致颜色变暗。
立即学习“go语言免费学习笔记（深入）”；
- 保存前检查：
img.Bounds().Max.X和.Y是否为期望尺寸，避免缩放没生效却保存了原图 - 读取时用
image.Decode，别用jpeg.Decode硬指定格式，否则 WebP 或 PNG 会失败 - 需要透明底 → 存 PNG；要兼容老浏览器或体积优先 → 先用
draw.Draw合成到纯色背景，再存 JPEG
裁剪必须在缩放前做，否则精度丢失
裁剪（crop）和缩放（resize）顺序不能颠倒。如果先缩放再裁剪，等效于对低分辨率图像抠局部，细节模糊、边缘失真；正确做法是先从原图精确裁出 ROI（Region of Interest），再对裁出的小图缩放。
很多人以为「反正都要缩，先缩再裁更快」，实际测试表明：高分图先裁再缩，内存占用更低、CPU 时间更少，还避免插值引入的定位偏移。
- 裁剪用
subImg := img.SubImage(image.Rect(x, y, x+w, y+h))，返回的是视图，不拷贝像素 - 确保
Rect参数不越界，否则SubImage可能返回空或 panic（取决于底层实现） - 若需裁剪后居中缩放，先算出原图中心区域坐标，再
SubImage，最后Scale
大图缩放卡顿？加个 runtime.GC() 并复用缓冲区
处理 >5MB 的 JPG 时，频繁 new image.RGBA 会触发大量 GC，造成明显卡顿。Go 的 image 类型本身不提供缓冲池，得自己管理。
关键不是减少分配次数，而是复用同一块底层 []byte。用 image.NewRGBA 创建图像后，缓存它的 Pix 字段，下次 resize 直接重置 Bounds 和 Stride 即可复用内存。
- 不要每次缩放都
make([]byte, w*h*4)，改用 sync.Pool 管理*image.RGBA - 缩放完成后立刻调用
runtime.GC()不必要；真正有效的是复用 Pix 底层切片 - 并发缩放时注意：多个 goroutine 共享同一
*image.RGBA必须加锁，或每人持有一份池化实例
最易被忽略的是：缩放后图像的 Stride 不一定等于 width * 4，尤其用 image.NewNRGBA 时。直接操作 Pix 数组前，务必用 img.Stride 计算行首偏移，否则跨行访问会错位。
