WinForm GDI+流程图源码：拖动不闪、缩放不偏、可序列化

简介：面向.NET桌面开发者以及需要自制流程设计工具的学习者，这套C# WinForm流程图示例围绕GDI+绘图与鼠标交互展开，可用于理解工作流图形界面的基础实现，也适合课程设计、内部工具原型等场景参考。压缩包共39个文件、约176KB，以9个cs源码为核心，配合resources、resx等界面资源，config、exe、pdb等编译运行文件，以及png效果图和txt使用说明，体量轻、结构紧凑，便于直接运行对照调试。已有3217人学习，说明其在入门与参考场景中具有一定认可度。代码重点演示Graphics、Pen、SolidBrush等绘制形状与文本，借助FlowShape一类自定义对象保存位置和类型，并在MouseDown、MouseMove、MouseUp中完成拖动，通过Invalidate触发即时重绘；连接线管理、刷新机制和源码注释也为继续扩展留出空间。读者可据此掌握WinForm画布交互、图形对象组织与重绘流程，并为开发更复杂的流程图编辑器打下基础。

1. 拖动不闪、松手不飘：一套 WinForm 流程图源码的真实价值

前阵子帮某公司内部工具做评审，需求很朴素：在 .NET WinForm 里画一张流程图，节点能拖、连线跟着走、拖的时候不能闪。找了一圈现成例子，能画出图的不少，拖动起来不撕裂、松手位置不偏移、缩放之后还能对准的，真不多。这份基于 GDI+ 的 C# 流程图源码就是在这种场景下翻出来的：纯 WinForm 手绘，不引第三方图形库，节点拖动走脏矩形刷新，双缓冲把闪烁压下去，代码量控制在一个 solution 能读完的范围里，算得上良心资源。它适合三类人：要在桌面端快速塞一个流程编辑器的、想学 GDI+ 自绘控件套路的、接手老 WinForm 项目又不想引入重依赖的。后面按绘图骨架、拖动链路、数据落盘、踩坑排查的顺序往下拆。

2. GDI+ 绘图骨架：从控件选择到坐标换算的三层地基

自绘流程图看着是「画几个矩形加箭头」，真正决定后面好不好改的，是最初那几十行骨架代码。骨架没搭对，拖动一上来就会遇到闪烁、坐标漂移、缩放错位这三件套。这一章把源码里最底层的三层拆开：为什么用单控件自绘而不是控件拼装、OnPaint 里的双缓冲怎么配、世界坐标和屏幕坐标怎么换算。

2.1 为什么不用 Panel 拼控件

新手最容易走的路线是拖一堆 Panel 或 Label 到窗体上，每个节点一个控件，连线用父容器的 Paint 事件补。这个做法在 5 个节点时能跑，20 个节点就开始露馅。每个子控件都是独立窗口句柄，鼠标划过要各自处理 WM_PAINT 和 WM_ERASEBKGND，拖动时父容器和子控件交替重绘，肉眼可见的抖动基本躲不掉。更麻烦的是 Z 序：连线要画在节点下面，但节点是子控件、连线是父容器绘制的，谁压谁全靠运气调。

单控件自绘把这套复杂度收回到一处。整个画布就是一个继承自 Control 的类，所有节点、连线、选中框都在一次 OnPaint 里按顺序画完，Z 序就是绘制顺序，想调谁在上面就把谁挪到列表后面。节点数量增长带来的只是绘制指令变多，不会多出窗口句柄，几百个节点在现代机器上依然能拖动。

这个选择有代价：命中测试、文本排版、光标形状、键盘焦点，全得自己写。源码里这几块都补齐了，所以拿来改比自己从零搭要省事。我一般的判断标准是——节点数会超过 20 个、或者需要缩放和平移，就别用控件拼装，直接上自绘。

2.2 OnPaint 里的双缓冲与重绘入口

WinForm 自绘控件闪烁的根本原因，是系统先用背景色刷一遍再让你画，两次绘制之间的时间差被人眼捕捉到。GDI+ 的双缓冲把这两步合并到一张离屏位图里，画完一次性贴到屏幕。源码在构造函数里把样式一次性设好：

public class FlowCanvas : Control { public FlowCanvas() { // 四个标志位缺一不可，少一个都可能闪 SetStyle(ControlStyles.AllPaintingInWmPaint // 屏蔽 WM_ERASEBKGND，不让系统刷背景 | ControlStyles.OptimizedDoubleBuffer // 双缓冲，先画到内存位图再整体贴屏 | ControlStyles.UserPaint // 走自己的 OnPaint，不用系统默认绘制 | ControlStyles.ResizeRedraw, true); // 尺寸变化时自动重绘 UpdateStyles(); // 样式改动后必须调用，否则不生效 } protected override void OnPaint(PaintEventArgs e) { var g = e.Graphics; // 抗锯齿只对曲线和斜线有意义，节点特别多时可以关掉换帧率 g.SmoothingMode = SmoothingMode.AntiAlias; g.PixelOffsetMode = PixelOffsetMode.HighQuality; // 顺序不能反：先平移视口，再缩放 g.TranslateTransform(_panX, _panY); g.ScaleTransform(_zoom, _zoom); foreach (var edge in _edges) edge.Draw(g); // 连线先画，压在节点下面 foreach (var node in _nodes) node.Draw(g); // 节点后画 DrawSelection(g); // 选中框最后画，永远在最上层 } }

AllPaintingInWmPaint是整套配置里最容易被漏掉的一个。少了它，系统仍然会响应擦背景消息，双缓冲只挡住了一半闪烁。UpdateStyles()也常被忘，样式设了但不调用，运行起来跟没设一样，这种问题排查起来很玄学，因为代码看起来完全正确。

绘制顺序同样有讲究。连线和节点分两个循环画，而不是按数据结构里的自然顺序混着画，这样任何一条连线都不会盖住节点。选中框单独放最后，是为了拖动时高亮边框始终可见。这三层顺序固定下来，后面加缩略图、加网格背景，都只是往对应层里插一条绘制指令，不会互相打架。

SmoothingMode.AntiAlias不是无脑开。它对直线矩形几乎没开销，对圆角、贝塞尔曲线、斜线有明显的边缘改善，但在节点数上百、又开着实时拖动的情况下，帧率会掉一截。我的做法是拖动过程中临时切成SmoothingMode.None，松手后再切回来，视觉上几乎察觉不到，流畅度立刻回来。

2.3 世界坐标与屏幕坐标的换算

坐标换算是自绘流程图里出错最多的地方，因为一旦错了，现象往往是「拖到某个位置之后所有东西都偏一点」，很难定位。源码把两套坐标分得很清楚：节点自身的 Bounds 存的是世界坐标，鼠标事件拿到的是屏幕坐标，所有业务逻辑只在世界坐标里跑。

// 屏幕坐标 -> 世界坐标：逆序运算，先减平移再除缩放 private PointF ScreenToWorld(Point p) { float x = (p.X - _panX) / _zoom; float y = (p.Y - _panY) / _zoom; return new PointF(x, y); } // 世界坐标 -> 屏幕坐标：用于计算脏矩形，顺序反过来 private Rectangle WorldToScreen(RectangleF r) { return new Rectangle( (int)(r.X * _zoom + _panX), (int)(r.Y * _zoom + _panY), (int)Math.Ceiling(r.Width * _zoom), (int)Math.Ceiling(r.Height * _zoom)); }

这两个函数看着简单，坑在顺序。正向变换是「先缩放再平移」，逆向就必须「先减平移再除缩放」，写成先除后减，缩放不为 1 的时候坐标就整体错位。源码里所有鼠标入口第一件事都是调ScreenToWorld，绝不直接拿e.Location去做命中测试，这条纪律守住，缩放比例怎么改都不会崩。

另外两个细节：_zoom用 float 存，默认 1.0f，限制在 0.2f 到 4.0f 之间，避免除零和极端缩放下的绘制溢出；WorldToScreen里宽高用Math.Ceiling而不是直接截断，是因为脏矩形少算一个像素就会留下一条残影，多算一个像素只是多刷一点，成本可以忽略。这类「宁可多刷不可少刷」的取舍，在自绘控件里是默认规矩。

3. 拖动即时刷新：命中测试、状态机与三种刷新策略

拖动是这套源码的核心卖点，也是最容易翻车的部分。要在鼠标移动的每一帧里完成：找到被拖的节点、更新它的位置、算出需要重绘的区域、把新旧两块区域都刷掉。任何一步偷懒，结果就是撕裂、残影或者拖快了节点「甩出去」。这一章按鼠标事件的顺序拆这条链路。

3.1 命中测试与 Z 序：从后往前找

命中测试要回答的问题是：鼠标点下去的那一点，落在哪个节点上。最直观的做法是从列表头往后遍历，但那样永远选中最早创建的那个节点，后画的节点明明盖在上面却点不到。正确顺序是从后往前，因为绘制顺序就是从前往后，后画的在视觉上更靠上。

// 从后往前遍历，先命中的就是视觉上最上层的节点 private FlowNode HitTest(PointF worldPt) { for (int i = _nodes.Count - 1; i >= 0; i--) { var n = _nodes[i]; // 用世界坐标的包围盒判断，不要拿屏幕坐标来比 if (n.Bounds.Contains(worldPt)) return n; } return null; }

Contains用的是矩形包围盒，对圆角节点和菱形节点会有几个像素的误判，允许一定误差，换来的是 O(1) 的判定成本。如果对精度有要求，可以在FlowNode里覆写一个HitTestExact，用GraphicsPath.IsVisible做路径判定，但那个开销大，只在包围盒命中后再调用，实际几乎不影响手感。

Z 序的维护放在鼠标按下的瞬间：命中的节点从列表里摘出来追加到末尾，视觉上就浮到最上层。这个操作成本极低，但用户感知很明显——点哪个哪个亮起来，是拖动交互的基本预期。

3.2 鼠标状态机：Down / Move / Up 与 Capture

拖动逻辑最忌讳写成一堆 if 嵌套在各个事件里，状态一多就失控。源码用了一个显式的枚举状态机，三种状态：空闲、拖节点、框选，后面加连线绘制也只是再加一个状态，不会污染已有分支。

private enum DragMode { None, MovingNode, Marquee } private DragMode _mode = DragMode.None; private PointF _dragOffset; // 按下点相对节点左上角的偏移，保证拖起来不跳 private FlowNode _active; protected override void OnMouseDown(MouseEventArgs e) { var wp = ScreenToWorld(e.Location); var hit = HitTest(wp); if (hit != null) { _active = hit; // 记住偏移量，否则节点左上角会瞬间吸到鼠标位置 _dragOffset = new PointF(wp.X - hit.Bounds.X, wp.Y - hit.Bounds.Y); _mode = DragMode.MovingNode; Capture = true; // 关键：捕获鼠标，拖出控件外也不丢事件 BringToFront(hit); // 同步 Z 序 Invalidate(); } base.OnMouseDown(e); } protected override void OnMouseMove(MouseEventArgs e) { if (_mode == DragMode.MovingNode && _active != null) { var wp = ScreenToWorld(e.Location); var oldBounds = _active.Bounds; // 先存旧位置 _active.Bounds = new RectangleF( wp.X - _dragOffset.X, wp.Y - _dragOffset.Y, oldBounds.Width, oldBounds.Height); InvalidateDirty(oldBounds, _active.Bounds); // 新旧两块都要刷 } base.OnMouseMove(e); } protected override void OnMouseUp(MouseEventArgs e) { _mode = DragMode.None; _active = null; Capture = false; // 一定要释放，否则其他窗口收不到鼠标 Invalidate(); base.OnMouseUp(e); }

_dragOffset这一行是「不跳」的关键。如果直接把节点位置设成鼠标位置，按下去的那一瞬间节点左上角会瞬移到鼠标，手感像被拽了一下。存下按下点相对节点左上角的偏移，整个拖动过程中保持这个偏移不变，节点才会像被手指按住一样跟着走。

Capture = true是另一个必须项。不捕获的话，鼠标拖出控件边界就收不到 Move 事件，节点会卡在边界上不动；松手在控件外面，Up 事件也收不到，状态机就永远停在拖动状态，下一次移动鼠标节点还会跟着跑。这个现象我翻过车，表现是「切出去再切回来，节点自己乱动」，查了半天才发现是 Capture 没释放。

3.3 三种刷新策略：全量、脏矩形与离屏缓存

刷新的粒度直接决定拖动的手感。源码里能看到三种做法的痕迹，理解它们的取舍，才知道什么时候该用哪种。

源码默认走脏矩形，InvalidateDirty的实现就是把新旧两块矩形转成屏幕坐标后取并集，稍微外扩两个像素：

private void InvalidateDirty(RectangleF oldW, RectangleF newW) { var a = WorldToScreen(oldW); var b = WorldToScreen(newW); var union = Rectangle.Union(a, b); union.Inflate(2, 2); // 外扩，抵消抗锯齿边缘的溢出 Invalidate(union); // 注意：这个重载在 UserPaint 下才有效 }

外扩两个像素不是可有可无。开了抗锯齿之后，图元的边缘会向外溢出一到两个像素，脏矩形贴着边界算，那圈淡边就刷不到，拖久了会留下一道浅色的拖影。这个现象不明显，但放大看很脏，属于典型的「不上线发现不了」的问题。

只有当节点图元特别复杂（比如内部带图标、带多行富文本）时，才值得上离屏缓存：每次绘制不重新计算路径，直接把预先渲染好的 Bitmap 贴上去。代价是每个节点一份位图，缩放时要重建，内存和首次渲染时间都会涨。我的经验是节点数过千再考虑，普通流程图脏矩形足够。

4. 节点、连线与序列化：让图能存能读的三件事

画得出来、拖得动，只是能用；能不能存盘、下次打开还是原样，才决定这份代码能不能进真实项目。这一章拆数据模型、连线路由和序列化三块，都是后期改需求时绕不开的地方。

4.1 图元模型：基类、节点、连线的职责边界

数据模型没设计好，后面加一个「节点分组」或者「连线标签」就要动一大片代码。源码用了很标准的抽象基类：所有能在画布上出现的东西继承同一个基类，基类只负责身份、位置、绘制和命中这四件事，具体形状交给子类。

public abstract class FlowElement { public Guid Id { get; set; } = Guid.NewGuid(); // 全局唯一，连线靠它找端点 public RectangleF Bounds { get; set; } // 世界坐标包围盒 public abstract void Draw(Graphics g, float zoom); public virtual bool HitTest(PointF worldPt) => Bounds.Contains(worldPt); } public class FlowNode : FlowElement { public string Text { get; set; } = string.Empty; public NodeShape Shape { get; set; } = NodeShape.Rect; // 矩形/圆角/菱形/椭圆 public List<Guid> Anchors { get; set; } = new(); // 锚点，连线挂在这上面 } public class FlowEdge : FlowElement { public Guid FromId { get; set; } // 起点节点 Id public Guid ToId { get; set; } // 终点节点 Id public int FromAnchor { get; set; } // 挂在起点的第几个锚点上 public int ToAnchor { get; set; } public string Label { get; set; } = string.Empty; // 连线上的文字，如「是」「否」 }

用 Guid 而不是对象引用做关联，是为了序列化。对象引用一进 JSON 就变成循环引用或者深层嵌套，Newtonsoft 和 System.Text.Json 都要额外配置才能处理。改用 Id，存盘就是平铺的数组，读盘后重建一个Dictionary<Guid, FlowElement>索引，O(1) 就能从 Id 找到节点。

Draw里多传了一个zoom参数，是因为文字排版和线宽要根据缩放做补偿。节点放大的时候，边框线宽不能跟着无限变粗，源码里线宽取1.5f / zoom，这样不管缩放到多少，屏幕上的线看起来都是 1.5 像素。这个细节决定了缩放之后图好不好看。

4.2 正交折线路由：拐点怎么算

连线走直线最省事，但流程图里两个节点一左一右、上下错开的时候，直线会斜穿其他节点，视觉上很乱。正交折线（横平竖直）是行业惯例，源码实现的是一个简化版：取两个锚点的中点做一条竖直通道，先横后竖再横，三个拐点。

// 简化版正交路由：p1 -> (midX,p1.Y) -> (midX,p2.Y) -> p2 private PointF[] RouteOrthogonal(PointF p1, PointF p2) { float midX = (p1.X + p2.X) / 2f; // 竖直通道放在两个锚点的中间 return new[] { p1, new PointF(midX, p1.Y), // 第一个拐点：横着走到通道 new PointF(midX, p2.Y), // 第二个拐点：竖着走到目标高度 p2 }; } // 绘制时用 DrawLines + 圆角连接，视觉上更柔和 g.DrawLines(pen, RouteOrthogonal(start, end));

这个算法在大多数布局下能用，遇到两个节点竖直通道上有别的节点穿过去，就需要「绕行通道」：把 midX 往左或往右偏一段，避开遮挡。源码里留了一个AvoidObstacles的扩展点，实现思路是在候选通道位置做几次采样，选第一个不与任何节点包围盒相交的 x 坐标。功能没写死，改起来有地方下手。

拐点数量也要控制。每多一个拐点，视觉噪音就多一分。经验值是相邻节点之间最多三个拐点，超过就说明布局有问题，宁可让用户手动拖一下节点位置。

4.3 JSON 序列化与版本兼容

存盘格式选 JSON 而不是二进制，理由是排查方便：出问题时用文本编辑器打开就能看出哪个字段丢了。源码用 System.Text.Json，配置有三处值得抄：

private static readonly JsonSerializerOptions Opts = new() { WriteIndented = true, // 缩进，方便人眼看 Converters = { new JsonStringEnumConverter() }, // 枚举存字符串，别存数字 DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull // 空值不写，减小体积 }; public void Save(string path) { var doc = new FlowDocument { SchemaVersion = 2, // 版本号必须留，后面加字段靠它做迁移 Nodes = _nodes.Select(n => (FlowNodeDto)n).ToList(), Edges = _edges.Select(e => (FlowEdgeDto)e).ToList() }; File.WriteAllText(path, JsonSerializer.Serialize(doc, Opts)); }

JsonStringEnumConverter这行别省。枚举默认存成数字，哪天在枚举中间插一个值，所有历史文件的含义全变了，而且不会报错，属于典型的静默数据损坏。存字符串多占几十字节，换的是可读性和向后兼容。

SchemaVersion是给未来的自己留的后悔药。读盘时先看版本号，低于当前版本就走进迁移分支，比如 v1 的连线没有 Label 字段，v2 读进来给个默认空串。没有这个字段，半年后想改结构就只能写一堆if (json.Contains("label"))的判断。

读盘之后必须重建索引，而不是直接拿 DTO 当模型用：

public void Load(string path) { var doc = JsonSerializer.Deserialize<FlowDocument>(File.ReadAllText(path), Opts); _nodes = doc.Nodes.Select(d => d.ToModel()).ToList(); _edges = doc.Edges.Select(d => d.ToModel()).ToList(); _index = _nodes.ToDictionary(n => n.Id); // 重建 Id -> 节点 的索引 _edges.RemoveAll(e => !_index.ContainsKey(e.FromId) || !_index.ContainsKey(e.ToId)); Invalidate(); }

最后那行RemoveAll是防御性代码：文件被手工改过、或者版本迁移出错，会出现指向不存在节点的连线，不清理的话绘制时直接空引用崩掉。宁可丢掉一条连线，也不要整个文件打不开。

5. 避坑与排查：五条上线前必须过的坎

这套代码在 Demo 阶段跑得很顺，真正接进项目之后，问题都是零散冒出来的。下面五条是我在实际使用和改造中记下来的，每条按现象、原因、解决三步写，遇到类似的可以直接对号入座。

5.1 拖快了节点「甩出去」，松手位置比鼠标偏一截

现象：快速拖动时节点跟不上鼠标，松手后节点停在鼠标前方一段距离，慢速拖动则正常。

原因：OnMouseMove里直接用了e.Location累加位移，而鼠标事件本身有合并机制，快速移动时系统会把多个移动事件合并成一个，累加就少算。另一个常见原因是用了整型Point存位置，缩放不为 1 的时候每次换算都截断小数，误差累积。

解决：位置一律用绝对坐标重算，不做增量累加；坐标类型统一用PointF，中间过程不转 int，只在最终绘制和脏矩形计算时才取整。这条改完之后，快速画圈拖动也不会飘。

5.2 高分屏下整体偏移，125% 缩放时点哪都差一点

现象：在 125% 或 150% 缩放的显示器上，鼠标点击位置和节点实际位置对不上，缩放比例越高偏得越多。

原因：WinForm 默认的 DPI 感知模式是「系统感知」，系统会对整个窗口做位图拉伸，控件内部拿到的坐标是逻辑坐标，而 GDI+ 绘制用的是物理像素。两套坐标混用，偏移量正好是 DPI 缩放系数。

解决：在程序清单或项目属性里开启 PerMonitorV2 DPI 感知，并在窗体的OnDpiChanged里重新计算_zoom基准。临时方案是在启动时读一次DeviceDpi，把画布的逻辑尺寸按dpi / 96f缩放一遍。不做这步，界面在高分屏上永远是糊的加偏的。

5.3 连线跟着节点走，但旧位置留了一条残影

现象：拖动节点时连线实时更新，可原位置总有一小段浅色线擦不掉，拖得越远残影越明显。

原因：脏矩形只算了节点的新旧包围盒，没算连线的包围盒。连线的端点跟着节点移动，它的旧路径覆盖范围可能超出节点本身的矩形，超出部分就没被重绘。

解决：InvalidateDirty的入参从「节点矩形」改成「与该节点相连的所有连线 + 节点」的并集。实现上在拖动开始时就把关联连线收集好，每帧取并集，成本很小。另一种做法是拖动期间干脆全量重绘，松手再恢复脏矩形，简单粗暴但有效。

5.4 保存后重新打开，连线全叠在左上角

现象：文件存了，节点位置都在，但所有连线都从画布左上角连到另一个左上角，像是坐标全变成 0。

原因：序列化时只存了节点的 Bounds，连线存的是端点的绝对坐标快照；读盘后节点位置恢复了，连线却还拿着旧快照，或者反序列化时 DTO 到模型的转换漏了锚点索引。

解决：连线不要存绝对坐标，只存 FromId、ToId 和锚点序号，端点位置在绘制时实时从节点 Bounds 算。这样节点一动连线自动跟随，存盘体积也小。检查一下 DTO 转换函数，确认FromAnchor和ToAnchor这两个字段确实被赋值了。

5.5 开着窗口放一晚上，内存和 GDI 句柄一直涨

现象：程序长时间运行后内存缓慢上升，任务管理器里 GDI 对象数从几百涨到几千，最后界面开始绘制异常甚至白屏。

原因：OnPaint里每次 new 出来的 Pen、Brush、Font、GraphicsPath 没释放。GDI+ 对象虽然托管包装，但底层是非托管句柄，不 Dispose 就要等终结器，终结器回收速度跟不上绘制速度，句柄就堆积。

解决：所有在绘制过程中创建的 GDI+ 对象一律using包起来，高频使用的 Pen 和 Font 提到字段里复用。另外检查Graphics.FromImage这类调用，用完必须 Dispose。判断标准很简单：任务管理器盯着 GDI 对象数拖一分钟，数字应该稳定在一个区间，持续上涨就是漏了。

6. 进阶：把流程图从「能跑」推到「敢交付」

代码能跑和能交付之间，隔着几件必须补的事：性能验证、导出质量、撤销重做。这三块源码里给了骨架，落地细节还得自己补，下面是我改完之后留下的做法。

性能验证不用专业工具，盯 GDI 对象数和拖动帧率就够。写个简单的手动检查流程：打开任务管理器增加「GDI 对象」列，拖一个节点来回晃三十秒，观察数字是否回落；再用秒表掐十次快速拖动，取平均耗时，超过 16 毫秒就该考虑关抗锯齿或者上离屏缓存。这套土办法不精确，但足够发现 90% 的性能退化。

导出图片这块有个经典坑：用DrawToBitmap截控件，只能拿到当前可视区域，超出部分全是空白，而且受屏幕 DPI 影响。正确做法是新建一张足够大的 Bitmap，把绘制逻辑抽成一个接受Graphics参数的函数，直接画到离屏图上：

public Bitmap ExportToBitmap(float scale = 2f) { var bounds = GetContentBounds(); // 所有图元的并集，别用控件尺寸 var w = (int)(bounds.Width * scale); var h = (int)(bounds.Height * scale); var bmp = new Bitmap(Math.Max(w, 1), Math.Max(h, 1)); using var g = Graphics.FromImage(bmp); g.SmoothingMode = SmoothingMode.AntiAlias; g.Clear(Color.White); // 透明底导出 PNG 会变黑，先铺白 g.ScaleTransform(scale, scale); // 放大导出，2 倍起步才够印刷 g.TranslateTransform(-bounds.X, -bounds.Y); // 把内容左上角对齐到画布原点 foreach (var e in _edges) e.Draw(g, scale); foreach (var n in _nodes) n.Draw(g, scale); return bmp; }

scale参数是导出质量的关键，1 倍导出在高分屏上看就是糊的，2 倍起步、需要印刷时给 4 倍。TranslateTransform用负的内容左上角，是为了让导出图紧贴内容，而不是带着一大片空白边距。Clear(Color.White)那行别漏，PNG 透明底在某些看图软件里显示成黑底，评审时容易被误认为导出失败。

撤销重做用命令模式，每个会改变文档的操作封装成一个带Do和Undo的对象，压进两个栈。要点是拖动这类连续操作要在 MouseDown 时压栈、MouseUp 时才算一次，不能在 MouseMove 里每帧压一个，否则一次拖动就产生几百条历史。这个改动量不大，但对可用性的提升非常明显。

从那以后我每接一个自绘控件的活，都先把 GDI 对象数盯上三分钟，再决定要不要继续往下写功能——这个习惯帮我省掉了好几次上线前夜的返工。希望帮到你。

本文还有配套的精品资源，点击获取