go标准库需手动导入image/jpeg等包注册解码器，否则image.Decode报“unknown format”；缩放PNG/JPEG须匹配color.Model（如*image.NRGBA）并用draw.CatmullRom保alpha；大图处理应限并发、调用runtime.GC、用DecodeConfig预检；原子替换文件需临时路径+权限/时间戳恢复+os.Rename。
Go 本身标准库不支持 JPEG/PNG 等常见图像的编解码，直接调用 image.Decode 会 panic：「unknown format」——必须显式注册解码器。
为什么 image.Decode 总返回 «unknown format»？
Go 的 image 包把格式解码逻辑拆到子包里，image/jpeg、image/png、image/gif 都需要手动导入才能注册解码器。只 import image 不够。
正确做法是：
- 在 main 包或初始化位置，import _ “image/jpeg”
- import _ “image/png”
- import _ “image/gif”
下划线导入触发包内 init() 函数，完成格式注册。漏掉任一格式，对应文件就无法 decode。
立即学习“go语言免费学习笔记（深入）”；
如何安全地批量缩放 PNG/JPEG 并保持透明通道？
缩放时若用 draw.ApproxBiLinear 或直接写死 RGBA64，PNG 的 alpha 通道可能被丢弃或错误叠加（尤其带半透明像素时）。
关键点：
- 先用
image.Decode得到原始图像，检查其类型是否实现了color.Model；常见 PNG 返回*image.NRGBA，它原生支持 alpha - 创建目标图像时，务必用匹配模型：
dst := image.NewNRGBA(bounds)，而非NewRGBA - 缩放使用
draw.CatmullRom（比 ApproxBiLinear 更保细节），并传入源图的完整 bounds 和插值方式
示例片段：
src, _, _ := image.Decode(file) bounds := src.Bounds().Resize(0.5) // 缩放至 50% dst := image.NewNRGBA(bounds) draw.CatmullRom.Scale(dst, dst.Bounds(), src, src.Bounds(), draw.Over)如何避免处理大图时内存爆掉？
一张 8000×6000 的 PNG 解码后可能占用 >100MB 内存（RGBA 各通道 1 字节 × 宽 × 高）。并发处理多张图极易 OOM。
实操控制手段：
- 用
runtime.GC()在单张图处理完后主动触发回收（非强制，但可降低峰值） - 限制 goroutine 并发数，用
semaphore或带缓冲 channel 控制同时解码/缩放数量（建议 ≤ CPU 核心数） - 对超大图（如宽或高 > 5000），先用
jpeg.Encode或png.Encode压缩为低质量中间格式再处理，避免全尺寸解码
注意：image.DecodeConfig 可提前读取尺寸和格式，用于快速过滤或分流，不消耗图像内存。
文件管理：如何原子化替换原图并保留权限/时间戳？
直接 os.WriteFile 会丢失 chmod 权限、atime/mtime，且写入中途失败会导致原图损坏。
安全做法分三步：
- 将新图写入临时路径：
tempPath := path.Join(filepath.Dir(src), "."+filepath.Base(src)+".tmp") - 写完后调用
os.Chmod(tempPath, origInfo.Mode())和os.Chtimes(tempPath, origInfo.ModTime(), origInfo.ModTime()) - 最后用
os.Rename(tempPath, src)—— unix 下是原子操作，windows 下需 fallback 到io.copy+os.Remove组合
别依赖 os.SameFile 判断是否同一设备，rename 跨设备会失败，应提前 stat 检查 Dev 字段。
图像处理链路上最易被跳过的环节是格式注册和 alpha 模型匹配，这两处出错不会报编译错误，但运行时静默损坏输出——尤其处理设计稿或 ui 资源时，半透明边缘糊掉往往要到上线才发现。