最简单方法是直接用 os.WriteFile 保存图片原始字节，无需解码再编码；注意文件后缀与实际格式一致、权限用 0644、multipart 上传需 ParseMultipartForm 并设 MaxMemory。
用 os.WriteFile 保存图片二进制数据最简单
Go 里存图片文件，本质就是把 []byte 写进磁盘。别想太复杂——只要拿到图片的原始字节（比如从 HTTP 请求、本地读取或生成），直接调用 os.WriteFile 就行，不用额外编码或转换。
常见错误是误以为要先解码成 image.Image 再编码回去，这纯属浪费 CPU 和内存。除非你要缩放、加水印等图像处理，否则跳过 image.Decode 和 jpeg.Encode 这些步骤。
-
os.WriteFile("avatar.jpg", imageData, 0644)——imageData是原始 bytes，比如http.Request.Body读出来的内容 - 确保文件后缀和实际格式一致（
.jpg对应 JPEG 数据，.png对应 PNG 数据），否则某些程序打不开 - 权限掩码写
0644而不是644，少个0会变成八进制含义错乱
从 http.Request 接收并保存上传的图片
Web 场景下，用户上传图片通常走 multipart/form-data。这时候不能直接读 r.Body，得用 r.ParseMultipartForm + r.FormFile 提取文件流。
容易踩的坑是忽略 MaxMemory 设置，导致大图直接加载进内存；或者没检查 Content-Type，把非图片文件也存了。
- 调用前设限：
r.ParseMultipartForm(32 （限制最多 32MB 在内存，超量部分写临时文件） - 用
file, header, err := r.FormFile("image")获取文件句柄，header.Header.Get("Content-Type")可做基础校验（如是否含image/） - 用
io.Copy流式写入，避免一次性加载整个文件：os.Create("upload/" + header.Filename)后接io.Copy(dst, file) - 别忘了
file.Close()和dst.Close()，否则 Linux 下可能报too many open files
保存前校验图片头（magic number）比扩展名更可靠
单靠文件后缀判断类型不安全——用户可以改个 .jpg 后缀上传恶意脚本。真正靠谱的方式是读取前几个字节，比对图片格式签名。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
Go 标准库的 net/http.DetectContentType 就干这事，但它只看前 512 字节，且返回的是推测的 MIME 类型，不是布尔判断。你需要自己匹配。
- JPEG 头是
[]byte{0xff, 0xd8, 0xff}，PNG 是[]byte{0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a} - 用
bytes.HasPrefix(data, []byte{0xff, 0xd8, 0xff})做快速判断，比调用image.Decode开销小得多 - 如果必须支持多种格式且要严格校验，建议用
golang.org/x/image/bmp等第三方包解析 header，但多数场景只需头字节检查
并发写入多个图片时注意文件路径冲突
多人同时上传同名文件（比如都叫 photo.jpg），直接覆盖会丢数据。解决方法不是加锁，而是生成唯一文件名。
别用 time.Now().UnixNano() 拼接——纳秒级在高并发下仍可能重复；也别依赖客户端传的文件名，它不可信。
- 推荐组合：UUID v4（用
github.com/google/uuid） + 原始扩展名，例如uuid.NewString() + ".jpg" - 如果业务要求保留原始名，可在路径中加入用户 ID 或时间目录：
uploads/2024/05/user_123/abc.jpg - 写入前用
os.Stat检查路径是否存在？没必要。直接写，失败再处理；但要注意os.IsNotExist(err)和os.IsPermission(err)区分对待
真正麻烦的从来不是“怎么存”，而是“谁来删”和“存哪”。临时目录没清理、OSS 上传失败后本地残留、文件名 URL 编码不一致导致 404……这些才是线上出问题的地方。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
