在.NET生态里做图像处理，开发者通常会遇到两个名字：System.Drawing和ImageSharp。前者是.NET Framework时代遗留下来的经典方案，后者是近年来快速崛起的纯托管开源库。很多团队在从旧项目迁移到.NET Core或.NET 6+时，会被System.Drawing的跨平台限制卡住；而新项目如果直接选用ImageSharp，又可能对它的许可模式产生顾虑。这篇文章把两个库的核心差异、典型代码和选型逻辑一次性讲透，帮你避开部署时的坑。
System.Drawing：经典但受限的Windows方案
System.Drawing最早出现在.NET Framework 1.1中，底层基于Windows GDI+原生API。在Windows服务器或桌面环境下，它稳定可靠，API简单直观，几乎所有.NET开发者都接触过它。加载一张图片、调整尺寸、保存为另一种格式，几行代码就能完成。下面的示例演示了如何用System.Drawing将一张图片缩放到指定宽高并保存为JPEG：
using System.Drawing;
using System.Drawing.Imaging;
public void ResizeImage(string inputPath, string outputPath, int width, int height)
{
using (var image = Image.FromFile(inputPath))
using (var resized = new Bitmap(image, new Size(width, height)))
{
resized.Save(outputPath, ImageFormat.Jpeg);
}
}这段代码很清楚，但背后隐藏着严重的平台绑定问题。System.Drawing.Common包虽然在.NET Core早期被微软提供用于跨平台兼容，但从.NET 6开始，微软官方明确将其标记为Windows-only，在Linux或macOS上调用会抛出PlatformNotSupportedException，除非你手动安装libgdiplus等原生依赖并接受不稳定的行为。对于容器化部署、云原生应用或者需要在macOS开发机上直接运行的服务，这几乎是致命的。
另一个需要注意的是资源管理。System.Drawing中的Bitmap、Graphics等对象都封装了非托管句柄，必须显式调用Dispose或者使用using语句，否则很容易造成内存泄漏。尤其是在循环处理大量图片时，忘记释放Graphics对象可能导致GDI+句柄耗尽，最终引发OutOfMemoryException。虽然模式固定，但不够优雅，也增加了代码审查的负担。
ImageSharp：纯托管跨平台的开源方案
ImageSharp由Six Labors团队开发，完全使用C#托管代码实现，不依赖任何原生图像库。这意味着它可以在Windows、Linux、macOS上一致运行，无需安装额外系统组件，非常适合.NET Core及后续版本的跨平台项目。它的API设计也更为现代，采用链式调用和中间图像处理管道，代码更简洁，资源管理交给GC自动完成。下面的代码同样实现了缩放功能：
using SixLabors.ImageSharp;
using SixLabors.ImageSharp.Processing;
public void ResizeImage(string inputPath, string outputPath, int width, int height)
{
using (var image = Image.Load(inputPath))
{
image.Mutate(x => x.Resize(width, height));
image.Save(outputPath);
}
}从代码可以看出，ImageSharp使用Image.Load静态方法加载图像，返回的Image对象同样实现了IDisposable，但内部完全托管，即使忘记Dispose也不会造成句柄泄漏，最坏情况是内存回收延迟。Mutate方法接受一个委托，可以在其中链式调用多个操作，比如Resize后再应用旋转、裁剪、滤镜等，这种风格比System.Drawing需要手动创建Graphics对象更方便。
ImageSharp支持丰富的图像格式，包括JPEG、PNG、GIF、BMP、WebP等，并且对EXIF元数据、色彩空间、动画帧等高级特性也有较好的支持。在性能方面，由于是纯托管代码，某些底层像素操作可能比GDI+慢，但Six Labors做了大量优化，对于常规的缩放、裁剪、格式转换，性能差距在实际项目中通常可以忽略。更重要的是，ImageSharp可以安全地运行在容器中，不会因为缺少系统库而导致进程崩溃。
性能与功能对比及选型建议
如果单论原始性能，System.Drawing在某些简单操作上可能略占优势，因为它直接调用经过多年优化的Windows原生代码。但ImageSharp在跨平台一致性、内存安全性和API设计上明显更胜一筹。从功能覆盖来看，两者都能完成基本的图像处理任务，但ImageSharp扩展性更强，例如支持自定义图像处理器、流式处理大图而不必一次性加载到内存。
下表对两个库的关键维度做了汇总，方便快速判断：
| 对比维度 | System.Drawing | ImageSharp |
|---|---|---|
| 跨平台支持 | 仅Windows（在.NET Core/5+上） | 全平台 |
| 原生依赖 | 依赖GDI+ | 无，纯托管 |
| API风格 | 传统，需手动管理Graphics | 链式调用，现代化 |
| 内存管理 | 必须显式Dispose | GC自动回收，更安全 |
| 许可协议 | 随.NET SDK，无额外限制 | 2.x为Apache 2.0；3.x为Six Labors Split License，商业使用需评估 |
| 格式支持 | 常见格式，但WebP需要插件 | 内置WebP、GIF等更多格式 |
许可协议是选型时容易忽略但必须确认的环节。ImageSharp 2.x版本采用宽松的Apache 2.0协议，可以自由使用。但从3.0版本开始，项目切换到了Six Labors Split License，对个人、开源项目和小型企业免费，年收入超过一定规模的企业需要购买商业许可。如果你的公司属于大企业或者不想在许可上做审查，可以继续使用2.x版本，或者考虑其他替代方案如SkiaSharp、Magick.NET。但对于绝大多数中小项目，ImageSharp 3.x的免费条款仍然适用。
实际选型时，如果项目已经基于System.Drawing构建且只部署在Windows服务器上，短期内没有跨平台需求，继续沿用可以降低迁移成本。但如果是从零开始的新项目，尤其是需要容器化、Kubernetes编排或者运行在Linux云主机上的服务，ImageSharp是更稳妥的选择。即使未来需要替换，ImageSharp的代码结构也更清晰，迁移成本更低。建议在技术评审阶段就把部署环境和许可要求列入决策清单。
C#图像处理System.DrawingImageSharp修改时间：2026-10-03 05:23:07