最稳妥的裁剪方式是graphics.drawimage，它兼容性好、行为可预测；bitmap.clone速度快但有格式和动画限制；imagesharp更现代但需注意坐标系和icc配置；image.getthumbnailimage不是裁剪工具，应避免使用。
用 Graphics.DrawImage 裁剪最稳妥
这是 .NET 框架里最通用、兼容性最好、行为最可预测的方式。它不依赖图像编码器，也不修改原始像素数据结构，只做“绘制时取局部”这件事。
常见错误是传错 sourceRect 坐标或尺寸——比如把裁剪区域宽高写成目标画布大小，结果图被拉伸或截断；或者没检查原图尺寸，Rectangle 超出边界导致 ArgumentOutOfRangeException。
- 先用
new Rectangle(x, y, width, height)明确裁剪区域，x/y 是原图左上角起点，不是目标位置 - 务必在创建前校验：
if (x img.Width || y + height > img.Height) - 目标
Bitmap尺寸应设为裁剪宽高，不是原图尺寸；否则会留黑边或缩放 - 记得调用
graphics.InterpolationMode = InterpolationMode.HighQualityBicubic防止小图裁剪后发虚
Bitmap.Clone 快但有坑
它底层直接复制内存块，零拷贝、无重采样，速度最快，适合批量裁剪且对画质无要求的场景（比如生成缩略图切片）。
但它只支持矩形裁剪，且返回的 Bitmap 与原图共享像素格式。如果原图是 PixelFormat.Format16bppArgb1555 或带 alpha 的非标准格式，Clone 出来的图可能在后续 Save 时报 EncoderNotFound 或颜色异常。
- 必须用
new Rectangle(...)和img.PixelFormat两个参数调用，缺一不可 - 不能用于 GIF 动画帧——
Clone只处理当前帧，不保留动画元数据 - 裁剪后若要保存为 JPEG，得先
new Bitmap(clone)转一次格式，否则可能失败
用 ImageSharp 裁剪更现代但需取舍
如果你项目已引用 ImageSharp（v2+），用 Clone 或 Crop 方法比 GDI+ 更安全：自动处理跨平台解码、内存池复用、无 GDI 句柄泄漏风险。
但它默认裁剪是“中心裁剪”，不是从左上角开始；而且 Crop 方法接受的是 Rectangle，但坐标系原点在图像左上，这点和 GDI+ 一致，容易混淆。
- 显式传
new Rectangle(x, y, width, height)，别依赖默认居中逻辑 - 异步方法如
LoadAsync+Crop+EncodeAsync需注意 await 上下文，ASP.NET Core 中别在同步方法里混用 - 若原图含 ICC 配置文件，
Crop后默认保留，但某些浏览器渲染会偏色——可加.WithColorProfile(null)主动剥离
别碰 Image.GetThumbnailImage
它根本不是裁剪工具，而是缩略图生成器。内部强制按比例缩放并填充/裁剪以适配目标尺寸，行为不可控，返回图质量差，且在 .NET 6+ 已标记为 obsolete。
典型误用：传入和原图等大的尺寸想“白嫖裁剪”，结果图模糊、边缘有灰边、Alpha 通道丢失。Windows Server 上还可能因 GDI+ 初始化失败直接抛 OutOfMemoryException。
- 看到这个函数名就跳过，不管文档怎么写“可指定区域”
- 它的
thumbWidth/thumbHeight参数永远是输出尺寸，不是裁剪框 - 替代方案只有上面三种，没有例外
裁剪看着简单，但 Rectangle 坐标来源、像素格式继承、目标保存编码器这三者一旦错位，问题就藏得深——尤其在 CI 环境或 Linux 容器里，GDI+ 缺失会让部分方式直接失效。动手前先确认运行时环境和图像格式。
