使用Golang进行图片生成的视觉对比测试

两次调用 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 中访问了已释放的图像数据（比如闭包捕获了循环变量）。

• 每个 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 各通道的分布统计），比全量像素比对快一个数量级

测试图像生成逻辑时，最常被忽略的不是算法，而是图像类型的语义细节和编码器的行为边界。尤其当你要靠像素级一致来断言“结果正确”，就得亲手控制从内存布局到文件头的每一层。