C#绘图避坑指南：从Graphics来源到DPI适配的实战要点
在C#中进行图形绘制，一个看似简单的DrawRectangle背后，往往藏着好几个“坑”。Graphics对象不能直接new，否则要么直接报错，要么静默失败——所有绘图操作都必须基于合法的来源。这可以说是入门绘图的第一条铁律。
Graphics 从哪来？三个合法入口，别碰 new
直接new Graphics()会抛出NotSupportedException，因为它并非一个可以随意实例化的普通类。合法的来源其实只有三个，各有各的适用场景：
- 窗体或控件的
Paint事件参数：e.Graphics—— 这是最推荐、最标准的方式。它自动参与系统的双缓冲和重绘流程，能确保图形持久且高效。 - 位图离屏绘制：
Graphics.FromImage(bitmap)—— 当你需要生成一张图片文件或在内存中绘制时使用。切记，用完后一定要调用graphics.Dispose()来释放资源。 control.CreateGraphics()—— 这个方法的用途比较特殊，通常仅用于调试或实现瞬时覆盖效果（比如鼠标跟随的预览线）。用它绘制的图形不会持久，窗口一旦发生重绘就会消失。
一个典型的错误场景是：在Button_Click事件里调用this.CreateGraphics()画了个矩形，结果按钮一点完，矩形就没了。这其实不是Bug，而是设计如此。
Pen 和 Brush 必须 Dispose，但别乱 new
Pen和Brush这两个类持有底层的GDI+句柄，如果不及时释放，会导致句柄泄漏。长时间运行后，程序可能会莫名其妙地抛出OutOfMemoryException，或者绘图直接失效。
- 在循环里反复
new Pen(Color.Red, 2)是高危操作。正确的做法是使用using语句块：using (var pen = new Pen(...)) { ... }。 - 静态复用是安全的，比如
static readonly Pen GridPen = new Pen(Color.LightGray, 1);。但要注意，Pen.Width和Color是只读属性，创建后无法修改。 - 对于系统预定义的刷子，如
Brushes.Red，无需手动Dispose。但如果是自己创建的SolidBrush或LinearGradientBrush，就必须手动释放。
DrawRectangle 画不出/位置偏移？先查坐标系和 DPI
明明写了g.DrawRectangle(pen, 10, 10, 100, 50)，却什么也看不见，或者画出来的框总往右下角偏。遇到这种情况，大概率是踩了下面三个坑：
- 没确认目标控件的客户区边界：在
PictureBox这类控件上绘图，坐标应该基于pictureBox.ClientSize来计算，而不是硬编码像素值。 - 高DPI缩放（Win10/11默认开启）：此时
Graphics.DpiX可能高达120或144。如果还按传统的96DPI设计尺寸去画，图形就会缩放失真。一个简单的校正方法是使用g.ScaleTransform(g.DpiX / 96f, g.DpiY / 96f)。 - 描边与填充的差异：
DrawRectangle的描边是以边线中心为基准的。如果pen.Width = 3，实际覆盖的区域会比参数指定的宽和高各多出1.5像素。而FillRectangle则是严格按左上角坐标和宽高来填充内部区域。
DrawString 模糊？TextRenderingHint 是关键开关
小字号文字发虚、边缘毛糙，问题通常不在字体本身，而在于默认的文本渲染模式过于“宽松”：
- 默认的
TextRenderingHint.SystemDefault在非整数缩放或ClearType关闭时，极易导致文字模糊。 - 一个固定的优化写法是：在
Paint事件的开头就设置g.TextRenderingHint = TextRenderingHint.AntiAliasGridFit;。 - 尽量避免使用浮点数的字体大小（如
new Font(“Arial”, 9.75f)），.NET会对其进行取整但不作提示。如果对文字精度有极高要求，可以考虑使用GraphicsPath配合FillPath来绘制文字轮廓。
话说回来，真正棘手的是DPI缩放与多显示器混合场景下的坐标对齐问题。这时候，光靠ScaleTransform可能就不够了，往往需要配合Control.LogicalToDeviceUnits方法，或者在应用程序清单中启用Per-Monitor DPI Aware声明——这一点，很多开发者一开始根本想不到。
