GetPixel 性能极差，因其是GDI+封装的同步、线程不安全操作，每次调用均触发完整像素解码与边界检查；1000×1000图像遍历耗时2–5秒，指针方式仅10–30ms。
GetPixel 性能差到离谱，别在循环里用
直接说结论：GetPixel 是 GDI+ 封装的同步、线程不安全、每次调用都触发完整像素解码和边界检查的慢操作。1000×1000 图片遍历全部像素，用 GetPixel 可能要 2–5 秒；换成指针方式只要 10–30ms。
常见错误现象：for (int y = 0; y 这种写法在 UI 线程跑会卡死界面，导出图片或批量分析时根本不可行。
- 只在调试、取极少数点（比如鼠标点击位置）时用
GetPixel - 批量读取必须用
LockBits+ 指针或BitmapData扫描行 - .NET 6+ 可考虑
System.Drawing.Common的GetPixel，但底层仍是同款慢实现，没本质改善
GetPixel 坐标原点是左上角，但容易被图像旋转/翻转骗到
GetPixel(x, y) 的 (0, 0) 是位图数据左上角像素，不是设备坐标系或 PictureBox 显示区域的逻辑左上角。如果图片被 RotateFlip 过，或加载自 EXIF 含旋转标记的 JPEG，GetPixel 读的仍是原始未旋转数据 —— 你看到的“顶部”可能其实是原始图像的右侧。
使用场景：从用户截图或摄像头帧中取色，结果颜色总对不上视觉位置。
- 先确认
bmp.RotateFlipType == RotateFlipType.RotateNoneFlipNone - 若图片来自
Image.FromFile，它默认会按 EXIF 自动旋转，此时bmp已是“人眼正确”的图像，GetPixel坐标才和显示一致 - 若用
new Bitmap(original)复制，EXIF 信息丢失，旋转状态可能错乱
GetPixel 返回 Color 结构，Alpha 通道常被忽略
GetPixel 返回的是 Color，它封装了 A/R/G/B 四个字节。但很多人只看 c.Rc.Gc.B，忘了 Alpha 不为 255 时，RGB 值已是预乘 Alpha 后的结果（GDI+ 默认启用预乘）。尤其处理 PNG 透明图时，直接比对 R==255 && G==0 && B==0 会漏掉半透明红点。
常见错误现象：识别红色目标失败，但用画图软件放大看确实是红的。
- 判断颜色前先检查
c.A ，决定是否需要反推原始 RGB - 预乘公式是
premultipliedR = (R * A) / 255，反推需浮点运算，有精度损失 - 更稳的做法：用
LockBits读原始 32bppArgb 数据，自己解析四字节
替代方案：LockBits + 指针读像素（.NET Framework / .NET Core 3.1+）
这是唯一靠谱的批量取色路径。核心是绕过 GDI+ 封装，直接访问内存中的像素数组。
简短示例（读取单点）：
var rect = new Rectangle(x, y, 1, 1);
var data = bmp.LockBits(rect, ImageLockMode.ReadOnly, PixelFormat.Format32bppArgb);
try {
unsafe {
byte* ptr = (byte*)data.Scan0.ToPointer();
int b = ptr[0], g = ptr[1], r = ptr[2], a = ptr[3];
var c = Color.FromArgb(a, r, g, b);
}
} finally {
bmp.UnlockBits(data);
}
-
Scan0是首行起始地址，data.Stride是每行字节数（含填充），不是Width * 4 - 32bppArgb 格式下，BGR 顺序（内存低地址到高地址是 B,G,R,A）
- 必须
try/finally确保UnlockBits，否则位图锁死，后续GetPixel会抛OutOfMemoryException
真要取单点又懒得写 LockBits，就老老实实用 GetPixel；但凡涉及 >10 个点，别犹豫，上指针。
