两次调用 draw.Draw 结果不一致，是因为 image.RGBA 复用时未清空背景，残留像素叠加；且 new(image.RGBA) 的零值为透明黑（0,0,0,0），非纯白，PNG 编码后显示异常。
用 image 包生成图片时，为什么两次调用 draw.Draw 结果不一致？
Go 标准库的 image 包本身不带“渲染引擎”，draw.Draw 只是像素级复制/合成，没有自动清空目标图像的概念。如果你复用同一张 *image.RGBA 作为画布但没手动填充背景色，上一轮留下的像素会叠加到下一轮——视觉对比测试里这就直接导致误判。
- 每次生成新图前，用
image.Rect(0, 0, w, h)范围调用draw.Draw(dst, dst.Bounds(), &image.Uniform{color.RGBA{255,255,255,255}}, image.Point{}, draw.Src)显式填白（或透明黑） - 别依赖
new(image.RGBA)的零值：它只保证像素数组为 0，而0,0,0,0是完全透明，在 PNG 编码后可能被显示为黑或灰，取决于查看器 - 如果做批量对比，建议统一用
color.NRGBA类型（Alpha 预乘），避免color.RGBA在 alpha 混合时出现意外偏色
保存 PNG 时颜色偏差，png.Encode 输出和浏览器预览不一致
png.Encode 默认写入的是非预乘 Alpha 的 RGBA 数据，但很多图像查看器（尤其是 macOS 预览、Chrome）在渲染时按预乘逻辑解释，导致浅色边缘发灰或泛蓝。这不是 bug，是色彩空间解释差异。
- 生成前把源颜色转成
color.NRGBA（即 R,G,B 已乘以 A/255），再传给draw.Draw；或者 - 用
golang.org/x/image/png替代标准库image/png，它支持png.Encoder的CompressionLevel和更可控的 Alpha 处理 - 测试时别只看系统预览，用
identify -verbose output.png（ImageMagick）确认实际存储的 color type 和 bit depth
并发生成多张图，draw.Draw panic: “invalid memory address or nil pointer dereference”
draw.Draw 不是并发安全的，但它崩溃通常不是因为函数本身，而是你共享了未加锁的 *image.RGBA 实例，或在 goroutine 中访问了已释放的图像数据（比如闭包捕获了循环变量）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个 goroutine 必须持有独立的
*image.RGBA实例，不要从外部传入共用画布 - 如果从 slice 构建图像，确保底层数组不被其他 goroutine 覆盖：
img := image.NewRGBA(image.Rect(0,0,w,h))，而不是基于某个共享[]byte手动构造 - 避免在 for 循环里直接起 goroutine 并引用
range变量：go func(i int) { ... }(i)，否则所有 goroutine 可能读到同一个i值，进而访问越界图像区域
对比两张图差异，用 bytes.Equal 判断 PNG 文件内容是否相同总失败
PNG 是有压缩和可选 chunk（如 tEXt、tIME）的格式，即使像素完全一样，两次 png.Encode 产生的字节流也几乎必然不同——zlib 压缩结果受内存布局、Go 版本、甚至 runtime.GC() 影响。
立即学习“go语言免费学习笔记（深入）”；
- 对比应基于解码后的像素：用
png.Decode读出两幅image.Image，再逐像素比对At(x,y)返回的color.Color - 注意 color model 统一：
image.RGBA和image.NRGBA的 Alpha 含义不同，直接比较R,G,B,A字段会出错；推荐转成color.NRGBA64再取整数分量 - 如果只是验证生成逻辑一致性，更轻量的方式是计算像素直方图哈希（比如 R/G/B 各通道的分布统计），比全量像素比对快一个数量级
测试图像生成逻辑时，最常被忽略的不是算法，而是图像类型的语义细节和编码器的行为边界。尤其当你要靠像素级一致来断言“结果正确”，就得亲手控制从内存布局到文件头的每一层。
