应使用 lockbits 直接操作内存而非 getpixel/setpixel，因其避免 gdi+ 锁和颜色转换；需用 stride 计算行宽、注意 bgr 顺序、保留 alpha、及时 unlockbits；colormatrix 适合批量或 ui 实时处理；span 加速需谨慎用于稳定场景。
用 Bitmap 和 GetPixel/SetPixel 做灰度化？别这么干
效率极低，尤其对中大图——GetPixel 每次都触发 GDI+ 锁和颜色空间转换，1000×1000 图可能卡顿数秒。它只适合调试小图或教学演示。
实操建议：
- 改用 LockBits 直接操作像素内存块
- 确保图像格式为 PixelFormat.Format24bppRgb 或 Format32bppArgb（避免额外格式转换）
- 计算灰度值时优先用加权平均：0.299×R + 0.587×G + 0.114×B，比简单取平均更符合人眼感知
- 注意 SetPixel 在 LockBits 区域内完全失效，必须手动写入 Scan0 指向的内存
LockBits 后怎么安全读写 RGB 分量？
核心是理解位图内存布局：每行字节对齐到 4 字节边界，所以实际每行宽度 ≠ 宽度×字节数/像素。容易踩坑的是直接按 width * 3 计算偏移，导致越界或错位。
实操建议：
- 用 BitmapData.Stride 获取真实行宽（含填充），不是 width * bytesPerPixel
- 对于 Format24bppRgb，BGR 顺序存储（不是 RGB），索引 0 是 B，1 是 G，2 是 R
- 修改灰度时，三个分量设为同一值，但 Alpha 通道（如有）保持原样，别误清零
- 写完必须调用 UnlockBits，否则资源泄漏且后续 Bitmap 操作会抛 InvalidOperationException
要不要用 ColorMatrix？什么场景下它反而是最优解？
当批量处理、需叠加其他色彩变换（如对比度、饱和度）或目标是 UI 渲染而非离线处理时，ColorMatrix + ImageAttributes 更轻量、线程安全，且由 GDI+ 底层优化。
实操建议：
- 灰度矩阵固定为：new float[][] { new float[] {0.299f, 0.299f, 0.299f, 0, 0}, ... }（完整 5×5 矩阵需补全）
- 必须设置 ImageAttributes.SetColorMatrix，漏掉这步矩阵不生效
- 不适用于需要逐像素逻辑（比如只灰度某区域、或根据亮度跳过某些像素）
- 在 WPF 或 WinForms 的 Paint 事件里用它做实时预览，比重绘 Bitmap 流畅得多
用 Span<byte></byte> 和 MemoryExtensions 加速灰度计算？C# 7.2+ 可行但有前提
能显著减少 GC 压力和边界检查开销，但前提是图像数据已通过 LockBits 暴露为可写的 IntPtr，再用 Span<byte>.DangerousCreate</byte> 或 Marshal.PtrToStructure 转换——这不是 .NET 自动管理的内存，出错直接崩进程。
实操建议：
- 仅在性能敏感且图像尺寸稳定（如摄像头帧）时启用
- 必须严格校验 Stride 和 Height，避免 Span 跨越行边界读写
- 灰度循环里用 Unsafe.Add 替代数组索引，但先确认 JIT 已内联该调用
- 开发期务必开启 #define UNSAFE 并在项目文件加 <allowunsafeblocks>true</allowunsafeblocks>
真正麻烦的从来不是公式本身，而是内存对齐、通道顺序、Alpha 保留和释放时机——这些地方错一点，图就花一块，或者程序跑着跑着就挂了。
