因为getpixel/setpixel每次调用均触发gdi+边界检查、颜色转换和句柄验证，而scan0配合unsafe直接操作裸内存，绕过所有托管开销；但需手动处理stride对齐、越界防护与格式匹配。
为什么直接用 BitmapData.Scan0 配合 unsafe 比 GetPixel/SetPixel 快几十倍
因为 GetPixel 和 SetPixel 每次调用都会触发 GDI+ 的边界检查、颜色空间转换和句柄验证，本质是封装了大量安全层；而 unsafe 下通过 Scan0 获取的是一块裸内存地址，你可以用指针直接读写像素字节，绕过所有托管开销。
但这也意味着：你必须自己保证不越界、对齐正确、格式匹配，否则程序会崩溃或图像错乱。
-
Bitmap必须使用PixelFormat.Format24bppRgb或Format32bppArgb等支持指针访问的格式（Format16bppArgb1555也行，但需注意字节序） - 调用
LockBits后必须用UnlockBits配对释放，否则资源泄漏且后续Bitmap操作可能失败 - 不要在
unsafe块里做耗时操作（如 IO、GC 触发逻辑），指针指向的内存只在锁定期间有效
怎么正确获取并遍历 32 位 ARGB 像素指针
关键不是“怎么写 unsafe”，而是怎么让指针真正指向你想操作的首像素，并按正确的步长移动。常见错误是忽略 Stride —— 它不是图像宽度 × 字节/像素，而是每行内存对齐后的实际字节数（通常是 4 字节对齐，所以宽为 101 像素的图，Stride 很可能是 408 而不是 404）。
var bmp = new Bitmap("test.png");
var rect = new Rectangle(0, 0, bmp.Width, bmp.Height);
var bmpData = bmp.LockBits(rect, ImageLockMode.ReadWrite, PixelFormat.Format32bppArgb);
<p>try
{
unsafe
{
byte<em> ptr = (byte</em>)bmpData.Scan0.ToPointer();
int bytesPerPixel = 4;
int stride = bmpData.Stride; // 注意：不是 bmp.Width * 4！</p><pre class="brush:php;toolbar:false;"><pre class="brush:php;toolbar:false;"> for (int y = 0; y <p>}
finally
{
bmp.UnlockBits(bmpData);
}</p>为什么改完像素后图像变花？常见内存踩坑点
最常被忽略的是：你假设了内存是连续、紧密排列的，但 Stride
Width × BytesPerPixel，导致你用 x * 4 跨列时跳进了填充字节区；或者你误把 Scan0 当作整张图起始地址，却没考虑 Rectangle 的 X/Y 偏移——此时 Scan0 指向的是裁剪后区域左上角，不是原图起点。
- 永远用
bmpData.Stride计算行偏移，别硬写width * 4 - 如果
LockBits的Rectangle不是从 (0,0) 开始，Scan0已自动偏移，无需再加X * bytesPerPixel - 32bpp 图像中 Alpha 通道默认可能未预乘（即非 premultiplied alpha），直接修改 RGB 而忽略 Alpha 可能导致半透明区域异常
- 多线程下不能共享同一
BitmapData实例，每个线程必须独立LockBits/UnlockBits
有没有更安全又不慢的替代方案？
纯 unsafe 是最快的，但如果你只需要局部处理、或想规避 GC 压力，Span<byte></byte> + MemoryMarshal.AsRef 是 .NET 5+ 更现代的选择 —— 它仍基于 Scan0，但用 Span 封装后可享受边界检查（debug 模式）和部分 JIT 优化，且无需显式 unsafe 关键字（仅在初始化 Span 时需要一次 unsafe）。
不过要注意：Span 不能跨 await、不能存在静态字段里，且 LockBits 的生命周期仍由你控制——Span 只是视图，不延长内存有效时间。
底层图像处理没有银弹：要速度就得担风险，要安全就得接受开销。真正难的从来不是写对指针，而是确认你锁住的那块内存，在每一帧、每一次缩放、每一种色彩配置下，都确实是你以为的那个样子。
