color.rgba 的 r、g、b、a 字段是 0–65535 的 16 位缩放值，需右移 8 位得 0–255；转换 color.color 应用 color.rgbamodel.convert() 而非类型断言；修改像素须写回 *image.rgba；jpeg 常为 ycbcr，需正确转 rgb 防色偏。
color.RGBA 结构体的 Alpha 通道不是 0–255 范围
读取像素时拿到的 color.RGBA 值，R、G、B、A 字段都是 uint32，但它们是“16-bit 缩放值”：实际范围是 0–65535，不是直观的 0–255。这是 go 图像库为精度保留的内部表示，直接拿 r 当 0–255 用会严重偏色。
常见错误现象：img.At(x, y) 返回的 color.RGBA 在转成 8-bit 时没右移 8 位，结果所有颜色发灰或过曝。
- 正确做法：用
r >> 8、g >> 8、b >> 8、a >> 8得到标准 0–255 值 - 如果要做计算（比如亮度公式
0.299*r + 0.587*g + 0.114*b），建议先右移再算，避免整数溢出 - 写回像素前，记得把 0–255 的值左移 8 位（
r ）再赋给 <code>color.RGBA{}
image.RGBAModel.Convert() 不等于类型断言
想把任意 color.Color 转成 color.RGBA 时，别直接 col.(color.RGBA) —— 大部分图像源返回的是 color.NRGBA 或 color.YCbCr，强行断言 panic。
使用场景：遍历 PNG/JPEG 解码后的图像，统一处理像素；滤镜需兼容不同来源的 image.Image。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
color.RGBAModel.Convert(col)，它安全转换并归一化 Alpha -
color.RGBAModel和color.NRGBAModel行为不同：前者假设输入是“预乘 Alpha”，后者假设“未预乘”；PNG 默认是 NRGBA，所以用NRGBAModel更稳妥 - 性能影响：每次调用
Convert()都有小开销，循环内别重复创建 Model 实例，复用一个变量就行
Filter 函数里修改像素后必须写回原图或新图
Go 的 image.Image 接口是只读的，At(x, y) 只读不写。想实现滤镜（比如灰度化、反色），必须用可变图像类型如 *image.RGBA，并手动调用 Set(x, y, color.Color)。
常见错误现象：代码看着改了 r,g,b，但图片输出完全没变化——因为没写回，或者写到了只读图像上（panic 或静默失败）。
- 确认源图类型：
img, ok := src.(*image.RGBA)，否则要先image.NewRGBA(img.Bounds())创建可写副本 -
Set()的坐标必须在Bounds()内，越界不会报错但无效 - 注意并发安全：如果用 goroutine 并行处理像素块，确保每个 goroutine 写的是互不重叠的区域，或加锁
YCbCr 到 RGB 转换容易忽略色彩空间差异
JPEG 解码后常是 *image.YCbCr，直接当 RGB 处理会导致色偏（尤其人脸发青）。Go 标准库提供了 color.YCbCrModel，但它默认按 ITU-R BT.601 转换，而现代 JPEG 多用 BT.709。
使用场景：对 JPEG 做锐化、对比度调整等需先转 RGB 的操作。
- 简单方案：用
color.YCbCrModel.Convert()，接受轻微色偏 - 精确方案：手写 BT.709 系数的转换公式，或用
golang.org/x/image/colornames之外的第三方色彩空间库 - 性能提示：BT.709 转换比 BT.601 多几次浮点乘加，纯整数运算下差距不大，但高频滤镜中值得测一下
最常被跳过的一步是检查图像原始模型——很多开发者看到 img.Bounds() 正常就默认它是 RGBA，结果在 JPEG 上调试半天才意识到 YCbCr 的存在。