C# GDI+绘图完整指南：一文搞懂核心要点与避坑策略
在 .NET 生态中进行图形操作，System.Drawing 曾是许多开发者的首选。然而，时代变了。一个必须认清的现实是：GDI+ 在 .NET 6 及更高版本中已被标记为过时，而 System.Drawing.Common 在非 Windows 平台上的行为并不可靠，生产环境，尤其是 Web 或跨平台图形生成场景，强烈不建议继续使用。
为什么 Graphics 对象一用就报“对象已被释放”？
这个问题堪称经典。它通常出现在两种场景：要么是在窗体控件的 Paint 事件之外，手动调用了 Graphics.FromImage() 或 Graphics.FromHwnd() 后忘了及时清理；要么就是试图去复用一个已经随着其父级 Bitmap 或窗体一同销毁的 Graphics 实例。
- 记住一个铁律：所有通过
Graphics.FromXXX()这类工厂方法创建的对象，都必须显式调用Dispose()，不能把希望寄托在垃圾回收器（GC）身上。 - 在
Form.Paint事件参数e.Graphics中获取的实例，是系统提供的临时对象。这个实例禁止手动Dispose()，也绝对不应该被缓存起来以备后用。 - 当在
Bitmap上绘图时，生命周期的顺序至关重要：正确的流程是，先new Bitmap()，再通过Graphics.FromImage()获取绘图上下文，绘图操作完成后，先graphics.Dispose()，最后才是bitmap.Dispose()。务必确保Bitmap的寿命长于在其上活动的Graphics对象。
DrawString 文字模糊、锯齿严重怎么办？
默认的文本渲染质量确实不尽如人意，尤其是在高 DPI 或界面缩放的场景下，锯齿和模糊感会格外明显。问题的根源，往往出在 Graphics.TextRenderingHint 和 Graphics.SmoothingMode 这两个属性没有被正确设置。
- 文字清晰度的关键，几乎完全取决于
TextRenderingHint。在 Windows 环境下，优先将其设为TextRenderingHint.ClearTypeGridFit；如果考虑到跨平台兼容性，TextRenderingHint.AntiAliasGridFit通常是更稳妥的选择。 - 需要区分的是，
SmoothingMode主要影响线条和曲线的平滑度，对文字渲染没有直接作用，但经常被误调。调整它并不会让文字边缘变得更锐利。 - 设置时机很重要：务必在调用
DrawString()方法之前完成属性设置。g.TextRenderingHint = TextRenderingHint.ClearTypeGridFit;
- 如果绘制的是图标或者小字号文字（例如小于等于10pt），ClearType 技术有时反而会导致笔画发虚。遇到这种情况，可以尝试改用
TextRenderingHint.SingleBitPerPixelGridFit。
在 ASP.NET Core 中用 System.Drawing 生成图片会崩溃
这是另一个高频的生产环境陷阱。当应用部署到 Linux 或 macOS 容器时，系统往往缺少 GDI+ 的原生依赖（比如 libgdiplus），随之而来的就是 DllNotFoundException: libgdiplus 或者各种内部句柄为空的异常。更何况，从 .NET 6 开始，官方已不再保证其跨平台的稳定性。
- 首要建议：不要在 Web API 或任何后台服务中使用
System.Drawing.Common来动态生成图片。 - 替代方案已经非常成熟：
SkiaSharp是推荐选项，它跨平台、高性能，并且 API 设计与 GDI+ 类似，迁移成本相对较低。另一个选择是纯托管的ImageSharp，它完全没有原生依赖，部署更简单。 - 如果因为历史原因必须沿用旧代码，那么在非 Windows 服务器上（如 Debian/Ubuntu）需要手动安装
libgdiplus（命令：apt-get install libgdiplus）。但请注意，即便解决了依赖，System.Drawing内部的部分操作也并非线程安全，风险依然存在。 - 如果在执行
dotnet publish时遇到类似 “runtimes/linux-x64/native/libgdiplus.so not found” 的错误提示，这通常意味着目标运行时环境缺失了必要的原生库，而不是项目打包本身的问题。
说到底，使用 GDI+ 真正的难点，或许并不在于如何画出一条线或写出一行字。真正的挑战在于判断：在当前的技术栈和部署环境下，是否还应该使用它？它的生命周期管理方式有些反直觉，跨平台支持更像是一种“幻觉”，而迁移到现代替代方案的成本，又常常被我们低估。
