应统一用golang.org/x/image的通用接口处理图像格式转换：读取用image.decode自动识别格式，写入按需调用jpeg.encode/png.encode/webp.encode；webp需单独go get并显式传&webp.options避免体积暴涨；转jpg前须手动合成白底以防alpha丢失；大图解码应直接用os.open而非os.readfile+bytes.newreader减少内存拷贝。
用 golang.org/x/image 读写不同格式，别碰 image/jpeg 单独包
Go 标准库的 image/jpeg、image/png、image/gif 只负责解码/编码对应格式，不统一；真正做格式转换，必须用 golang.org/x/image 下的通用接口。否则你会卡在“无法把 *jpeg.Image 直接喂给 png.Encode”这种地方。
实操建议：
- 统一用
image.Decode读取任意格式（自动识别），返回image.Image接口，与具体格式解耦 - 写入时用
jpeg.Encode/png.Encode/webp.Encode（需额外引入golang.org/x/image/webp） -
webp包不包含在x/image主模块里，要单独go get golang.org/x/image/webp - 注意：标准库没有
image/webp，别试图 import 它——会报错import "image/webp": cannot find package
webp.Encode 需手动传 *webp.Options，默认不压缩
直接调 webp.Encode(w, img, nil) 会生成未压缩、体积巨大的 WEBP 文件，比原 PNG 还大。这不是 bug，是设计：WEBP 的压缩参数必须显式指定。
常见错误现象：
- 转换后文件体积暴涨 2–5 倍
- 浏览器能打开，但加载慢、CDN 缓存效率低
实操建议：
- 用
&webp.Options{Lossy: true, Quality: 80}控制有损压缩（Quality范围 0–100） - 若要无损（如保留 alpha 且不接受失真），用
&webp.Options{Lossy: false}，但体积仍通常小于 PNG - 别传
nil，哪怕只设一个字段：&webp.Options{Quality: 75}也比nil安全
RGBA 模式影响透明通道处理，JPG 不支持 Alpha
Go 的 image.Image 接口不暴露颜色模型，但底层类型决定能否保留透明度。PNG 和 WEBP 支持 Alpha，JPG 不支持——强行转 JPG 会丢 alpha，且可能变黑或白底，取决于源图是否预乘 Alpha。
使用场景：
- 用户上传带透明背景的 PNG，想转 JPG → 必须手动合成到纯色背景（如白底）
- 转 WEBP 时保留透明，但用
image.NRGBA或image.RGBA源图更稳妥
实操建议：
- 检查源图是否支持 Alpha：
_, ok := img.(image.Uniform)不够，应转成*image.NRGBA再操作 - 合成白底示例：
bounds := img.Bounds() dst := image.NewNRGBA(bounds) draw.Draw(dst, bounds, image.White, image.Point{}, draw.Src) draw.Draw(dst, bounds, img, image.Point{}, draw.Over) - 转 JPG 前务必做这步，否则透明区域行为未定义（常见为黑块）
内存占用高？别用 os.ReadFile + bytes.NewReader 双拷贝
典型写法 data, _ := os.ReadFile("in.png"); img, _ := png.Decode(bytes.NewReader(data)) 会把整个文件读进内存两次：一次 ReadFile，一次解码器内部缓冲。大图（如 4K）容易 OOM。
性能影响：
- 10MB 图片可能触发 20MB+ 内存峰值
- 并发转换时 GC 压力明显上升
实操建议：
- 直接用
os.Open得到*os.File，传给image.Decode（它接受io.Reader） - 解码后立即
file.Close()，避免句柄泄漏 - 如果需多次复用同一张图，再考虑缓存
image.Image，而不是原始字节
webp.Options 是空结构体而非默认值。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
