直接用 gin.Context 读取图片失败是因为 c.Request.Body 只能读一次，且 Gin 不自动解析 multipart/form-data 为可复用字节流；正确做法是用 c.Request.FormFile 获取文件头，再 Open() 并 io.ReadAll 一次性读入内存。
为什么直接用 gin.Context 读取图片会失败
因为 c.Request.Body 默认只允许读取一次，且 Gin 没有自动解析 multipart/form-data 中的二进制文件为可复用的字节流。如果你用 c.PostForm("image") 拿到的是空字符串，或者用 c.Request.FormFile("image") 后再想二次读取，就会遇到 http: read on closed body 错误。
正确做法是：先调用 c.Request.FormFile 获取 *multipart.FileHeader，然后用它的 Open() 方法得到一个可读的 io.ReadCloser，再用 io.ReadAll 一次性读入内存——后续所有图像处理都基于这个 []byte 进行。
- 别在中间件里提前调用
c.Request.ParseMultipartForm，Gin 已在路由匹配前做了这事 - 如果前端传的是 base64 字符串（比如 Data URL），要用
base64.StdEncoding.DecodeString解码，注意去掉data:image/png;base64,前缀 - 务必检查
fileHeader.Size，避免上传超大图导致 OOM；建议限制在 10MB 以内
用 golang.org/x/image/draw 叠加文字水印时字体渲染模糊
根本原因是 draw.Draw 默认不启用抗锯齿，而文字绘制又依赖 font.Face 和 truetype.Font 的 DPI 设置。直接用 golang.org/x/image/font/basicfont 的内置字体，效果差、无中文支持、字号固定。
推荐方案：用 golang.org/x/image/font/opentype 加载本地 TTF 文件，并显式设置 faceOpts.DPI = 72（或 96/144 根据输出尺寸调整）；再用 text.Draw 替代原始 draw 操作。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 字体文件路径必须是绝对路径或相对于可执行文件的路径，
os.Executable()+filepath.Dir()可靠些 - 中文字符需确认 TTF 文件包含对应 Unicode 区块（如 NotoSansCJK 或思源黑体）
- 不要用
font.Face.Metrics()算高度，直接用face.Metrics().Height，单位是fixed.Int26_6，要除以 64 才是像素
image/jpeg.Encode 输出的图片颜色失真或体积暴涨
这是 JPEG 编码器默认使用高质量（jpeg.Options{Quality: 75}）但未显式传参导致的。如果不传 jpeg.Options，底层会用 DefaultQuality = 75，对带水印的图来说往往偏高；而某些 PNG 转 JPEG 时还可能因 Alpha 通道处理不当出现灰边。
关键动作：先调用 image.NewRGBA 创建目标画布，用 draw.Draw 把原图（转成 RGBA）和水印图合成；若原图是 PNG 且含透明通道，需手动填充背景色（比如白底），否则 JPEG 编码会出错。
- 写入响应前，用
c.Writer.WriteHeader(http.StatusOK)和c.Header("Content-Type", "image/jpeg")显式设置头 - 质量参数建议设为
85平衡清晰度与体积；低于60会出现明显块状伪影 - 避免对同一张图反复 encode → decode → encode，每次都会损失质量
并发处理多张图片时 CPU 占用飙升甚至卡死
golang.org/x/image 的图像操作全是同步阻塞的，没有内置 goroutine 封装。如果每个请求都做缩放+水印+编码，单核 CPU 在 3–5 个并发下就可能跑满。
缓解方式不是加 goroutine，而是加资源限制：用带缓冲的 channel 控制同时处理的图片数（比如最多 4 张），其余请求排队；同时对图像尺寸做前置判断——宽高超过 4000px 的图，强制先等比缩放到 2000px 再处理。
- 别用
runtime.GOMAXPROCS盲目调高，图像解码本身不受益于多 OS 线程 - 缓存已处理过的水印图（比如固定文字+位置+字体的组合），用
sync.Map存watermarkKey → *image.RGBA - 生产环境务必用
pprof抓 CPU profile，重点看image/draw.drawRGBAMultiply和jpeg.encode耗时
水印逻辑看着简单，但字体加载、Alpha 混合、JPEG 量化表选择这些细节，每一步都可能成为瓶颈。真正上线前，拿真实手机截图和扫描件测一遍——很多“正常”的图，在低分辨率屏上水印位置会偏移、文字会糊成一片。
