subimage返回原图视图而非新图像，修改原图会导致裁剪结果异常；正确做法是用image.newrgba创建新图并用draw.draw复制。
裁剪图片时 image.SubImage 返回的不是新图像，而是视图引用
直接用 image.SubImage 拿到的区域只是原图的一个“窗口”，底层像素数据没复制。如果后续修改原图（比如重绘、GC 回收底层数组），裁剪结果可能意外变花或 panic。
- 正确做法：用
image.NewRGBA创建新图像，再用draw.Draw把子图内容复制进去 - 注意
SubImage的坐标必须在原图 bounds 内，越界会返回 nil，不报错但容易漏判 - 如果原图是
*image.RGBA，可直接用sub.Bounds()和sub.Pix手动拷贝，性能更好
缩放用 draw.BiLinear 还是 draw.NearestNeighbor
缩放质量与速度的取舍很实际：draw.NearestNeighbor 快但锯齿明显，适合图标、小尺寸预览；draw.BiLinear 平滑但慢 2–3 倍，适合用户头像、封面图。
-
draw.BiLinear对非整数倍缩放（如 0.75x）效果明显，但对 2x/4x 这类整数缩放提升不大 - 别用
draw.CatmullRom—— 它不在标准库image/draw中，需要第三方包，且开销大、边界易出灰边 - 缩放前务必确认目标图像已用
image.NewRGBA分配好空间，否则draw.Draw会静默失败
处理 JPEG/PNG 时 decode 后的图像类型不一定是 *image.RGBA
Go 标准库解码后常返回 *image.YCbCr（JPEG）或 *image.NRGBA（带 alpha 的 PNG），而 draw.Draw 要求至少一方是 RGBA 或兼容格式，否则 panic 报 "draw: invalid destination image type"。
- 统一转成
*image.RGBA最稳妥：用image.NewRGBA(src.Bounds())+draw.Draw复制一次 - 如果只读不写，可用
src.Convert(image.RGBAColorModel)，但注意它返回的是color.Color接口，不能直接传给draw.Draw - 不要假设
img.Bounds().Max.X就是宽度——YCbCr 图像的Stride可能大于Bounds().Dx()，直接操作 Pix 数组会越界
并发缩放多张图时别共用同一个 draw.Draw 目标图像
多个 goroutine 同时往同一块 *image.RGBA.Pix 写会导致数据竞争，图像花掉或 panic： "fatal error: concurrent map writes"（如果底层用了 map）或更隐蔽的像素错乱。
立即学习“go语言免费学习笔记（深入）”；
- 每个 goroutine 必须分配独立的
*image.RGBA实例 - 如果批量处理，建议用
sync.Pool缓存*image.RGBA，避免高频 GC；池中对象需在复用前调用bounds重置，不能只清 Pix - 对大图（>2000×2000），缩放本身是 CPU 密集型，开太多 goroutine 反而因调度开销降低吞吐，实测 4–8 个常较优
