image.Decode 读取 WebP 或 AVIF 会 panic 是因标准库默认仅注册 jpeg/png/gif 解码器；需显式导入 golang.org/x/image/webp 等包并启用 -tags=webp/avif 编译选项，且必须检查 err 再调用 img.Bounds()。
为什么 image.Decode 读取 WebP 或 AVIF 会 panic？
Go 标准库的 image.Decode 默认只注册 jpeg、png、gif 三类解码器。上传含 WebP、AVIF、BMP 等格式的图片时，若未显式导入对应包，会直接返回 “unknown format” 错误，甚至触发 panic（尤其在未检查 err 就调用 img.Bounds() 时）。
实操建议：
- 在
main.go或初始化入口处，强制导入需支持的解码器：import _ "image/jpeg" import _ "image/png" import _ "image/gif" import _ "golang.org/x/image/webp" import _ "golang.org/x/image/bmp" // AVIF 需额外构建 tag（见下节）
- 永远先检查
err：不要写img, _ := image.Decode(r)，而应写img, _, err := image.Decode(r)—— 第三个返回值是string格式名，可用于日志或路由判断 - WebP 解码依赖 CGO，默认关闭时会静默失败；启用方式为编译时加
-tags=webp，例如：go build -tags=webp
AVIF 支持必须开启 CGO 且指定 build tag
目前 Go 官方和 golang.org/x/image 均不原生支持 AVIF。主流方案是使用 github.com/andybalholm/brotli + github.com/knqyf263/go-avif 或更轻量的 github.com/disintegration/imaging（底层调用 libavif C 库）。
关键限制：
立即学习“go语言免费学习笔记（深入）”；
-
go-avif要求 CGO_ENABLED=1，且必须加-tags=avif编译，否则avif.Decode返回nil, nil - 生产环境 Docker 构建需安装系统依赖：
apt-get install -y libavif-dev libaom-dev（Debian/Ubuntu） - 若不想引入 C 依赖，可改用「前端预转」策略：上传前用 JS 的
createImageBitmap+canvas.toBlob('image/jpeg')统一降级为 JPEG，服务端只处理 JPEG/PNG/GIF
高并发下批量转图容易 OOM，别直接用 image.Decode + jpeg.Encode
标准库的 image.Decode 会将整张图解码为内存中的 *image.RGBA，一张 8000×6000 的 PNG 解码后约占用 192MB 内存。上传 QPS 达 50+ 时，极易触发 GC 压力或 OOM Kill。
更稳的做法：
- 用
github.com/disintegration/imaging替代标准库：它支持流式缩放（imaging.Resize内部复用 buffer），且 decode 后可立即 discard 原始像素数据 - 对大图强制加尺寸上限：上传后先用
image.DecodeConfig读头信息（仅需前几百字节），若Config.Width > 4096 || Config.Height > 4096，直接拒绝或按比例缩小 - 转图任务丢进异步队列（如
asynq或redis streams），HTTP 接口只做校验和入队，避免请求线程阻塞
保存转换结果时，os.Create 的路径拼接要防遍历攻击
用户上传的原始文件名若含 ../../etc/passwd，直接拼进 os.Create("uploads/" + filename) 可能写入任意路径。
安全做法：
- 用
path.Base(filename)截掉所有路径分量，再用strings.TrimSuffix去掉扩展名，最后拼上唯一 hash 和目标后缀（如uuid.New().String() + ".jpg"） - 存储目录提前
os.MkdirAll("uploads", 0755)，并确保该目录不在 web root 下（防止用户直链访问未授权资源） - 若用对象存储（S3/MinIO），不要把原始 filename 当 key；生成 key 时固定前缀 + hash + 时间戳，例如：
"img/2024/05/" + hash + ".webp"
