Go标准库image包支持基础图像操作但不支持缩放旋转等高级功能；需显式导入解码器并校验类型，JPEG编码需YCbCr格式，缩放推荐nfnt/resize库，操作前须检查尺寸防OOM。
Go 标准库的 image 包能完成基础图像加载、保存、裁剪和像素操作，但**不能直接缩放、旋转或高质量滤波**——这些必须靠第三方库或手动实现，否则效果差、易 panic、不兼容常见格式。
image.Decode 为什么经常 panic: invalid JPEG format
因为 image.Decode 依赖注册的解码器，而 Go 默认只注册 PNG；JPEG/GIF 需显式导入对应包才能识别 Magic Number。跳过类型校验直接传文件给 jpeg.Decode，遇到 PNG 就崩。
- 正确做法：先用
http.DetectContentType检查前 512 字节，再选jpeg.Decode/png.Decode/gif.Decode - 别写
import _ "image/jpeg"就以为万事大吉——它只注册解码器，不改变image.Decode对输入流的解析逻辑 - 上传场景下，
*multipart.File是io.Reader，但jpeg.Decode内部会尝试读取整个流，若未重置偏移量（如用io.MultiReader或bytes.NewReader(buf)），可能读到空内容
jpeg.Encode 报错：cannot encode image.RGBA as JPEG
JPEG 规范不支持 Alpha 通道，jpeg.Encode 只接受 *image.YCbCr 或能转为 YCbCr 的类型（如 *image.NRGBA 不行，*image.RGBA 也不行）。
- 安全做法：用
draw.Draw把原图绘制到image.NewYCbCr目标上，再传给jpeg.Encode - 偷懒但可用：用
imaging.AdjustColorBalance或gocv.CvtColor转换颜色空间，但会引入额外依赖 - 别忽略
*jpeg.Options{Quality: 85}—— 默认质量是 75，体积大且模糊；设为 95 以上反而可能因量化表溢出导致编码失败
想缩放图片？别碰 image/draw.Scale
image/draw.Scale（含 NearestNeighbor、Bilinear）是标准库里唯一缩放入口，但它没有抗锯齿、无滤波控制、不支持 Lanczos，输出常带明显马赛克或模糊，生产环境基本不可用。
立即学习“go语言免费学习笔记（深入）”；
- 推荐
github.com/nfnt/resize：轻量、API 简单、默认双线性，小图加resize.Lanczos3显著提升锐度 - 注意返回值是
*image.NRGBA，保存为 JPEG 前得转一次：resize.Resize(...)→draw.Draw(dst, dst.Bounds(), src, src.Bounds(), draw.Src)→jpeg.Encode - 并发调用时，每个 goroutine 必须新建
resize.Bicubic实例，复用会导致 panic: concurrent map writes
修改像素前必须确认图像可写类型
image.Image 是只读接口，At(x, y) 返回 color.Color，但 Set(x, y, color) 只在 *image.RGBA、*image.NRGBA 等具体类型上存在。
- 错误写法：
img.Set(0, 0, c)（img 是 interface）→ 编译失败 - 正确路径：先
bounds := img.Bounds()，再rgba := image.NewRGBA(bounds)，然后draw.Draw(rgba, bounds, img, bounds.Min, draw.Src)复制数据 - 高频操作别用
rgba.At/rgba.Set——它每次都要做边界检查和 RGBA 分量转换；直接操作rgba.Pix字节切片（索引 =y*rgba.Stride + x*4）快 3–5 倍
最易被忽略的一点：所有涉及图像尺寸的操作（裁剪、缩放、创建新图），都必须提前检查 Bounds().Dx() 和 Bounds().Dy() 是否超出内存安全阈值（比如 > 8192×8192），否则恶意上传一张 100MB 的超大 PNG，解码瞬间就 OOM。
