根本原因是源图和目标图的 Bounds() 不对齐或颜色模型不匹配；draw.Draw 不自动缩放、裁剪或转色，仅像素级复制/混合，越界丢弃，类型不符会 panic。
draw.Draw 为什么总画不出预期效果
根本原因通常是源图和目标图的 Bounds() 不对齐，或者颜色模型不匹配。Go 的 draw.Draw 不会自动缩放、裁剪或转换颜色空间——它只做像素级复制/混合，超出目标区域的部分直接丢弃，类型不兼容时甚至 panic。
常见错误现象：draw.Draw: invalid source image（源图 ColorModel() 和目标图不一致）、合成后一片黑/白/透明（Bounds() 为零或偏移错）、文字或图标位置偏移（没考虑 image.Point 偏移参数）。
- 确保源图和目标图都使用
color.RGBAModel（最稳妥），用image.NewRGBA创建目标，用draw.Draw前先检查src.Bounds().Max.X - 偏移量不是“贴到左上角”，而是以
dst的坐标系为基准：比如想把小图贴到目标图 (50,30) 位置，第三个参数传image.Pt(0,0)，第四个参数传dst.Bounds().Min.Add(image.Pt(50,30)) - 如果源图是
*image.NRGBA或*image.Gray，必须显式转成*image.RGBA，否则draw.Draw会拒绝执行
draw.Over 和 draw.Src 的区别到底在哪
这俩是 draw.Op 类型的两个常量，控制像素如何混合。用错会导致图层被覆盖、透明度失效或背景残留。
draw.Src 是“直接覆盖”：目标像素完全替换成源像素，无视 alpha；draw.Over 是“正常图层叠加”：按源像素 alpha 值做混合（类似 Photoshop 的“正片叠底”前的默认模式），保留目标图的底层内容。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 合成水印、图标、文字等需要透明边缘的元素，必须用
draw.Over，否则透明部分变成纯黑或纯白 - 用
draw.Src的典型场景：清空某块区域（用纯色图覆盖）、替换固定区域内容（如 UI 中刷新某个按钮图标） - 如果源图 alpha 值全为 255（不透明），两者效果一样；但只要存在半透像素，
draw.Over才能正确融合
合成 PNG 时透明通道丢失怎么办
标准库默认不处理 PNG 的 alpha 通道写入——即使你用了 *image.RGBA 并设置了 alpha 值，png.Encode 也可能输出成无透明的 RGB 图。
根本原因是 *image.RGBA 的 At(x,y) 返回的是 color.RGBA，其 alpha 值在 0–255 范围，但 PNG 编码器是否写入 alpha 取决于图像是否被识别为“支持 alpha”。而 image.RGBA 默认满足条件，问题往往出在中间步骤。
- 不要用
image.NewNRGBA后再转*image.RGBA，NRGBA 的 alpha 存储方式不同，转过去可能失真 - 保存前确认目标图变量类型是
*image.RGBA，且每个像素的A字段已设为期望值（比如半透文字：color.RGBA{255,255,255,128}） - 用
png.Encode保存时，确保文件后缀是.png，且没有额外的格式转换（比如误用jpeg.Encode）
性能差得离谱？别让 draw.Draw 在循环里反复调用
每次 draw.Draw 都会遍历源图所有像素并做坐标映射+混合计算。如果在 for 循环里对同一张小图重复贴 100 次，就是 100 次全量遍历——哪怕只是改个位置。
更糟的是，如果源图是解码后的 *image.PNG，每次调用还可能触发隐式颜色转换（尤其源图是 paletted 或 YCbCr 格式）。
- 批量贴图时，先把所有要贴的位置预计算好，用单次
draw.Draw+ 自定义image.Image实现“虚拟拼接图”，避免多次调用 - 高频合成（如视频帧生成）建议复用同一张
*image.RGBA作为目标缓冲区，不要每帧都make新的 - 如果只是平移贴图，可直接操作
dst.Pix底层数组（需手动计算内存偏移），比draw.Draw快 3–5 倍，但要自己处理边界和颜色模型
真正难的不是调哪个函数，而是想清楚“哪部分该提前算好”“哪部分必须 runtime 决定”——边界模糊时，Bounds() 和 ColorModel() 就是第一道检查关卡。
