用 github.com/disintegration/imaging 加水印最稳，因其纯 Go 实现、无 CGO 依赖、自动处理预乘 alpha、支持抗锯齿缩放与正确图层叠加，避免原生 image 包手动合成导致的发虚、透明度错乱、背景变黑等问题。
用 github.com/disintegration/imaging 加水印最稳
Go 原生 image 包不支持直接合成水印，硬写 RGBA 叠加容易出错、不抗锯齿、不处理透明度。实际项目里，imaging 是目前最轻量又可靠的方案——它底层用纯 Go 实现，没 CGO 依赖，跨平台打包不翻车。
常见错误是直接拿 image.Draw 手动覆盖，结果水印发虚、alpha 混乱，或者 PNG 透明背景变黑。这是因为没做 premultiplied alpha 合成，而 imaging 默认就处理好了。
- 水印图必须是
*image.NRGBA或能转成它的格式（比如用imaging.Clone()强制转换） - 文字水印别用
draw.Draw直接画，先用imaging.DrawText渲染到独立图层再叠加 - 缩放水印时，用
imaging.Resize+imaging.Lanczos，别用NearestNeighbor，否则边缘锯齿明显
文字水印位置和透明度怎么调才不糊
文字水印不是“写上去”就完事，关键在渲染时机和 blend 模式。直接往原图上 DrawText 会破坏原图 alpha 通道；正确做法是新建一个同尺寸透明图层，只在上面画字，再用 imaging.Overlay 叠加。
常见问题：文字半透明但背景发灰，其实是水印图层用了 image.RGBA 而非 NRGBA ——前者 alpha 是 postmultiplied，后者才是标准预乘，imaging 内部所有合成都按 NRGBA 处理。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 字体大小建议 ≥12px，太小的字用
Lanczos缩放后依然模糊 - 透明度控制用
imaging.AdjustOpacity，参数是 0.0–1.0，别传整数 - 位置计算别手算坐标，用
imaging.Centered或imaging.TopLeft等锚点常量，避免图片尺寸变化时水印偏移
PNG/JPEG 水印后文件体积暴增？这是编码没关对
加完水印立刻 jpeg.Encode 或 png.Encode 得到的文件，往往比原图大一倍以上。问题不在水印本身，而在编码器默认参数太“保守”：JPEG 用 DefaultQuality（75），PNG 用无压缩的 png.Encoder 配置。
更麻烦的是，如果原图是 JPEG，你用 png.Encode 输出，那肯定体积爆炸——格式选错比参数还致命。
- JPEG 输出务必显式传
&jpeg.Options{Quality: 85}，85 是清晰度和体积的合理平衡点 - PNG 输出要设
png.Encoder的CompressionLevel，推荐flate.BestCompression - 别对已压缩图反复解码-编码，水印操作前后尽量保持同一格式流转
批量加水印时 goroutine 泄露和内存暴涨
有人写 for 循环起一堆 goroutine 跑 imaging，结果跑一半 OOM。不是 imaging 本身吃内存，而是每张图 decode 后的 *image.NRGBA 对象没及时被 GC，尤其大图（如 4000×3000）单张就占 40MB+。
根本原因是没控制并发数，且没复用 bytes.Buffer 或图像缓存。goroutine 数量 > CPU 核心数意义不大，反而加剧调度开销和内存碎片。
- 用
semaphore或带缓冲 channel 控制并发，比如最多 4 个 goroutine 同时处理 - 每次处理完立即
runtime.GC()不必要，但要在 defer 里把buf.Reset()和局部变量置为nil，帮 GC 快速识别可回收对象 - 别把水印图
*image.NRGBA存全局变量反复用——它不是线程安全的，多 goroutine 并发写会 panic
水印逻辑本身不复杂，难的是边界：图像格式差异、内存生命周期、并发模型。漏掉任意一个，线上跑几天就崩。
