安全处理图片上传需双重校验：先检查content-type白名单，再用image.decodeconfig验证文件头magic number；限制上传大小防oom；缩放用resize库而非image.draw；jpeg压缩设quality:85，png用bestspeed；并发时用唯一临时路径并及时清理；webp需手动注册解码器且按ua条件启用。
上传时如何安全读取并校验图片文件
直接用 multipart.File 读原始字节再交给图像库解码，容易因恶意构造的非图片文件（如带 shell payload 的 .jpg）触发 panic 或内存暴涨。必须在解码前做双重校验：
- 检查
Content-Type是否在白名单内（"image/jpeg"、"image/png"、"image/gif"），但不能只信它——客户端可伪造 - 用
image.DecodeConfig读取文件头 512 字节，确认 magic number 匹配真实格式；若返回ErrFormat或ErrUnsupported，立刻拒绝 - 限制上传体大小（如 Nginx 的
client_max_body_size或 Go 的http.MaxBytesReader），避免 OOM
缩放与压缩必须用 resize 而非 image.Draw
image.Draw 是底层绘制接口，不做插值优化，直接缩放会导致锯齿严重、细节丢失；生产环境应使用 github.com/nfnt/resize 或更现代的 golang.org/x/image/draw 配合高质量重采样器：
-
resize.Resize默认用 Lanczos2，适合保留边缘清晰度；若需更快响应，可降级为resize.Bilinear - 压缩 JPEG 时务必设
jpeg.Options{Quality: 85}—— 低于 75 人眼易察觉块效应，高于 95 文件体积激增且收益极小 - 对 PNG，优先用
png.Encoder{CompressionLevel: png.BestSpeed}控制编码耗时，而非默认的BestCompression（CPU 占用高、延迟不可控）
并发上传时如何避免临时文件冲突与泄漏
多个 goroutine 共享同一 os.CreateTemp 目录或未关闭 *os.File，会导致磁盘占满或 too many open files 错误：
- 每个上传请求生成唯一临时路径：
os.CreateTemp("", "upload-*.bin")，处理完立即os.Remove - 用
io.CopyN+ 限长 reader 替代io.Copy，防止恶意超大文件写满临时盘 - 所有
defer file.Close()必须在file变量作用域内，避免闭包捕获错误变量
WebP 支持需手动注册且注意兼容性
Go 标准库不支持 WebP，必须显式调用 golang.org/x/image/webp 的 webp.RegisterDecode，否则 image.Decode 会静默失败：
立即学习“go语言免费学习笔记（深入）”；
- 在
main()开头添加webp.RegisterDecode()，否则任何 WebP 图片都会被当成未知格式 - WebP 解码比 JPEG 慢约 3–5 倍，建议仅对明确支持 WebP 的 UA（含
"WebP"的User-Agent）启用，其余回退到 JPEG - 生成 WebP 时注意：标准库无编码器，需用
cgo绑定 libwebp，或改用纯 Go 实现如github.com/chai2010/webp（但压缩率略低）
真正难的不是缩放或转格式，而是当用户连续上传 200 张 12MB RAW 照片时，你的内存分配节奏、临时文件清理时机、以及错误路径里是否漏掉了 Close() —— 这些地方一松懈，服务就卡在 GC 或 fd 耗尽上。
