Go图片水印失败主因是解码未校验错误、坐标硬编码、透明度未用draw.Over及NRGBA类型、批量处理内存溢出；需检查err、动态计算位置、调整alpha并流式处理。
Go 图片水印加不上去？先检查 image/jpeg 和 image/png 的解码是否成功
很多新手跑通代码后发现图片没变化，甚至输出空白图，根本原因是 jpeg.Decode 或 png.Decode 失败但没报错——Go 的 image.Decode 在遇到不支持格式（比如 WebP）或损坏数据时会静默返回 nil 和错误，而后续直接对 nil 图像操作就会 panic 或写入空图。
- 务必在解码后判断
err != nil，并用log.Fatal(err)或明确提示“不支持的图片格式” - 支持多格式的稳妥写法是调用
image.Decode前先注册解码器：import _ "image/gif"、_ "image/png"、_ "image/jpeg" - 注意：Windows 下路径含中文时，
os.Open可能失败，建议用filepath.FromSlash统一路径分隔符
draw.Draw 水印位置总偏移？别硬算坐标，用 watermark.Bounds().Dx() 和 Dy() 动态对齐
手动写 dstX := 100; dstY := 50 看似简单，实际会导致不同尺寸图上水印位置“漂移”。真正可控的方式是基于目标图和水印图的实际宽高做相对定位，比如右下角留 20px 边距：
- 右下角：
dstX := dst.Bounds().Dx() - mark.Bounds().Dx() - 20 - 居中：
dstX := (dst.Bounds().Dx() - mark.Bounds().Dx()) / 2 - 注意
mark必须是 *image.NRGBA 类型（带 alpha），否则透明度设置无效；用image.NewNRGBA创建后，再用draw.Draw把原始水印图绘制进去
透明度调了但没效果？问题出在 draw.Draw 的第 4 个参数 op 和水印图类型
很多人改了 alpha := 0.6 却发现水印还是实心黑块，这是因为：draw.Draw(dst, r, src, sp, op) 中的 op 如果用了 draw.Src，就完全覆盖目标像素，透明度信息被丢弃；必须用 draw.Over 才会按 alpha 混合。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 水印图必须是
*image.NRGBA（不是*image.RGBA），否则 alpha 通道不参与合成 - 调整透明度的正确做法：遍历水印图每个像素，把
color.NRGBA{R,G,B,A}的A乘以系数（如uint8(float64(a) * alpha)） - 别漏掉：目标图
dst也得是*image.NRGBA，否则draw.Over会静默降级为Src
批量处理卡死或 OOM？别一次性加载所有图到内存，用 os.ReadDir + 流式处理
用 filepath.WalkDir 遍历几千张图时，如果每张都 os.ReadFile 再 image.Decode，极易触发 GC 压力或内存爆满。真实项目里应边读边处理，立刻写入磁盘，不缓存图像对象。
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Open打开源文件 →jpeg.Decode解码 → 加水印 →jpeg.Encode写新文件 → 立即close所有句柄 - 避免用
glob匹配大量文件名后统一处理；os.ReadDir更轻量，且可配合strings.HasSuffix过滤".jpg"、".png" - 并发需谨慎：
runtime.GOMAXPROCS默认等于 CPU 核数，但图片解码是 CPU 密集型，开太多 goroutine 反而因调度开销变慢；建议限制为min(4, runtime.NumCPU())
水印工具最难调的其实是 alpha 混合那几行——看似只是改个参数，背后牵扯图像类型、绘图模式、内存布局三层匹配。漏掉任意一个，都会让透明度失效或位置错乱，而且不容易一眼看出来。
