用 image.DecodeConfig 先读尺寸，jpeg.DecodeOptions.Scale 降采样，再 draw.ApproxBiLinear 缩放；校验 MIME 用 http.DetectContentType 和 magic bytes，流式读取并限大小。
用 golang.org/x/image/draw 做缩略图容易内存爆掉
直接用 draw.BiLinear 或 draw.CatmullRom 缩放原图，如果原始图片是 5000×4000 的 JPEG，解码后 RGB 数据会占约 60MB 内存，再叠加缩略图绘制过程中的临时缓冲区，单次请求就可能吃掉上百 MB。这不是并发问题，是单图处理路径没做约束。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
image.DecodeConfig读头信息，拿到宽高，不全量解码 - 按目标尺寸反推采样率，用
jpeg.Decode的jpeg.DecodeOptions{Scale: n}参数提前降采样（n取 2、4、8） - 再用
draw.ApproxBiLinear（比CatmullRom快 3 倍且内存友好）做最终缩放 - 务必设置
http.MaxBytesReader防止上传超大文件
net/http 处理图片上传时的 MIME 类型陷阱
前端用 FormData.append('file', blob) 上传，但某些浏览器（特别是旧版 Safari）可能不带 Content-Type，或传成 application/octet-stream，导致后端用 mime.TypeByExtension 判定失败，误认为不是图片。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要只信
req.Header.Get("Content-Type")，要用http.DetectContentType检查前 512 字节 - 对
image/jpeg、image/png、image/webp显式支持，其他一律拒收 - 接收时用
multipart.Reader流式读取，边读边校验 magic bytes，超过 10MB 立即中断 - 避免用
req.ParseMultipartForm(32 —— 它会把整个 body 全塞进内存
生成 WebP 缩略图时 CPU 占用飙升的解决办法
Go 标准库不支持 WebP 编码，得靠 golang.org/x/image/webp，但它默认用纯 Go 实现的 encoder，压缩质量设为 80 时，CPU 使用率能拉满，延迟从 200ms 涨到 2s+。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用
github.com/h2non/bimg（基于 libvips），它支持 WebP 且默认启用多线程缩放 - 若必须用纯 Go，把
webp.Options.Quality控制在 60–75 区间，质量下降不明显，耗时降 60% - 加缓存层：用
filepath.Join(cacheDir, fmt.Sprintf("%s_%dx%d.webp", hash, w, h))做文件级缓存，避免重复编码 - 注意
bimg在 Alpine 容器里要装libvips-dev和build-base，否则 runtime panic 报undefined symbol: vips_colourspace
缩略图 API 返回 400 却没告诉用户哪里错了
常见错误如：width=abc、height=-100、format=gif（不支持）、quality=105，后端直接返回 400 Bad Request，但响应体为空，前端无法提示具体原因。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有 query 参数解析后立即校验，用结构体 +
mapstructure.Decode或手写ParseThumbnailQuery函数 - 错误响应统一用
map[string]string{"error": "invalid width: must be positive integer"}，Content-Type: application/json - 对
width/height做硬限制（如 ≤ 4096），超出直接 400，不尝试缩放 - 记录日志时带上
req.URL.String()和req.UserAgent()，方便排查恶意扫描
