灰度化必须用亮度公式0.299r+0.587g+0.114*b转换像素，而非仅类型断言或简单平均；优先调color.GrayModel.Convert，注意Gamma校正、内存控制及draw.Draw兼容性。
灰度化用 image.Gray 还是手动计算 RGB？
直接用 image.Gray 类型不等于灰度化——它只是存储格式。真正灰度化得把原图每个像素按加权公式转成单通道值，否则加载后仍是彩色数据。常见错误是只做类型断言或简单取平均：(r + g + b) / 3，这会偏亮、失真。
正确做法是用亮度公式：0.299*r + 0.587*g + 0.114*b（ITU-R BT.601 标准），Golang 的 image/color 包里 color.YCbCrModel.Convert 或 color.GrayModel.Convert 内部就用这个逻辑。
- 优先调
color.GrayModel.Convert，兼容所有color.Color实现，不用自己拆通道 - 如果原图是
*image.RGBA且想极致控制，可手动遍历rgba.Pix字节切片，但要注意 stride 和 Alpha 通道位置（RGBA 每像素占 4 字节，Alpha 在末尾） - 别对
image.NRGBA直接取r,g,b值——它的值已预乘 Alpha，需先除 Alpha 或改用color.NRGBAModel
jpeg.Decode 后图像变暗或颜色异常？
这是典型 Gamma 校正缺失导致的视觉偏差。JPEG 解码后得到的是 sRGB 编码的像素值，而灰度转换公式假设输入是线性光强度。Golang 标准库不做自动 Gamma 转换，所以直接算出的灰度值会偏暗。
实际项目中多数场景可忽略 Gamma（人眼对灰度差异不敏感），但若需精确匹配 Photoshop 或 OpenCV 行为，得手动做 Gamma 解码：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 对每个 r/g/b 分量，先除以 255 得 [0,1] 浮点数，再做
pow(x, 2.2)得线性值，再套亮度公式 - 生产环境慎用——增加浮点运算、拖慢吞吐，且多数终端显示设备本身也不严格遵循 sRGB
- 更轻量的折中：用查表法（256 元素
[]float64）替代每次 pow 计算
批量处理时内存暴涨甚至 OOM？
问题常出在没控制解码/编码缓冲区。Golang 的 jpeg.Decode 默认把整个图像读进内存，一张 8000×6000 的 JPEG 解码后是 ~192MB 的 *image.RGBA（4 字节/像素），远超原始 JPEG 文件大小。
- 用
jpeg.DecodeConfig先读宽高，判断是否需要缩放再决定是否全量解码 - 对大图，用
golang.org/x/image/vp8或resize库做流式缩放+灰度，避免生成中间 RGBA 图像 - 写入时别用
jpeg.Encode直接写文件——它内部会分配临时缓冲区；改用jpeg.NewEncoder+SetQuality控制压缩率，质量设 75~85 足够，设 100 反而更大
为什么用 image/draw.Draw 复制灰度图总报 panic: "cannot convert"？
因为 draw.Draw 要求源和目标图像的 color.Model 兼容。把 *image.Gray 往 *image.RGBA 上画会失败，反之亦然。错误信息通常是 "cannot convert image.Gray to image.RGBA"。
- 目标图必须是
*image.Gray类型才能接收灰度源图，或用draw.Src模式配合color.GrayModel显式指定转换模型 - 更稳妥的做法：用
image.NewGray创建目标图，尺寸与源图一致，再用draw.Draw（此时源和目标 model 都是color.GrayModel） - 别依赖
image.Image.Bounds()返回的image.Rectangle直接当 slice 索引——Min.X/Y可能非零，要用rect.Dx(), rect.Dy()算尺寸
灰度化真正的复杂点不在算法本身，而在图像来源的多样性：CMYK TIFF、带 ICC Profile 的 PNG、WebP 的 YUV 解码、甚至 GIF 的 palette 索引色。标准库只覆盖最简路径，一旦遇到这些，就得切到 golang.org/x/image 或 cgo 绑定的 libvips。
