需先调用 r.ParseMultipartForm(maxMemory)，maxMemory 建议设为 32
如何用 net/http 接收 multipart 图片上传
Go 标准库 原生支持 multipart/form-data，不需要额外依赖。关键点是调用 r.ParseMultipartForm 并限制内存缓冲大小，否则大文件会直接吃光内存。
常见错误：漏掉 ParseMultipartForm 就直接读 r.MultipartForm.File，结果返回 nil；或传入 0 导致全部写入磁盘（慢且不可控）。
-
maxMemory建议设为32（32MB），足够覆盖多数头像 / 商品图 - 必须检查
err，上传中断、字段名错误、超限都会在这里报错 - 用
formFile比手动遍历MultipartForm.File更简洁，但只适用于单文件字段
func uploadHandler(w http.ResponseWriter, r *http.Request) {err := r.ParseMultipartForm(32 << 20) if err != nil {http.Error(w, "parse form err:"+err.Error(), http.StatusBadRequest) return } file, header, err := r.FormFile("image") if err != nil {http.Error(w, "get file err:"+err.Error(), http.StatusBadRequest) return } defer file.Close() // 保存原始文件，例如到 ./uploads/ dst, _ := os.Create("./uploads/" + header.Filename) defer dst.Close() io.Copy(dst, file) }用 golang.org/x/image/draw 生成等比缩略图
标准库不带图像处理能力，x/image 是官方维护的扩展包，比第三方更轻量、更新更及时。缩略图核心是「等比裁剪」还是「等比缩放」——前者保画质但可能丢内容，后者保完整但可能留白。
容易踩的坑：直接用 draw.CatmullRom 缩放到任意尺寸会导致模糊；没关闭源图 image.Image 的底层 reader；忽略 Alpha 通道导致 PNG 透明背景变黑。
立即学习“go 语言免费学习笔记（深入）”；
- 先用
jpeg.Decode或png.Decode解码，根据header.Header.ContentType判断格式 - 计算目标尺寸时，用
float64运算再转int，避免整数除法截断 - 目标
RGBA图像必须用image.NewRGBA显式创建，不能复用原图矩形
func generateThumbnail(src image.Image, width, height int) *image.RGBA {bounds := src.Bounds() srcW, srcH := bounds.Max.X, bounds.Max.Y scale := float64(width) / float64(srcW) if float64(height)/float64(srcH) 保存缩略图时如何保持原始格式与质量
用户上传的是 JPEG 还是 PNG，缩略图最好也用相同格式输出，否则可能破坏透明度或引入压缩失真。Go 的 image/jpeg 和 image/png 包都支持参数控制，但接口不统一。
典型问题：用 jpeg.Encode 保存 PNG 源图，结果透明区域全变黑；对 PNG 强行设 jpeg.Options{Quality: 95} 报错；没设置 png.Encoder.CompressionLevel 导致文件过大。
- 从原始
header.Header.Filename或解码后类型判断格式，不要只看Content-Type - JPEG 质量建议设为
85，平衡体积与观感；PNG 用png.BestCompression即可 - 写文件前确保目录存在：
os.MkdirAll("./thumbnails", 0755)
func saveImage(img image.Image, path string, format string) error {f, _ := os.Create(path) defer f.Close() switch format { case "jpeg", "jpg": return jpeg.Encode(f, img, &jpeg.Options{Quality: 85}) case "png": return png.Encode(f, img) default: return fmt.Errorf("unsupported format: %s", format) } }为什么不应在 HTTP handler 中直接处理大图
图像解码 + 缩放是 CPU 密集型操作，阻塞 goroutine 会导致并发吞吐骤降。哪怕只是 5MB 的 JPG，在树莓派上也可能卡住 300ms+，而 Go 默认 HTTP server 每个连接一个 goroutine。
真实服务中容易被忽略的是：没设超时、没做并发限制、没分离 IO 与计算。上传接口响应时间应控制在 100ms 内，图像处理应异步化。
- 用
http.TimeoutHandler包裹 handler，防止长请求拖垮服务 - 把解码 / 缩放逻辑扔进带缓冲的 channel 或简单 worker pool（如
semaphore.NewWeighted(10)） - 返回立即响应（如
{"status":"queued","id":"abc123"}），后续用 webhook 或轮询查结果
缩略图路径命名建议包含哈希（如 thumb_），避免重名覆盖和热链接攻击。sha256(filename+time).Hex()[0:8].jpg
