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 三种刷新策略全量、脏矩形与离屏缓存刷新的粒度直接决定拖动的手感。源码里能看到三种做法的痕迹理解它们的取舍才知道什么时候该用哪种。策略调用方式帧率表现代码复杂度适用规模全量重绘Invalidate()节点少时够用50 个以上开始掉帧最低50 个节点以内脏矩形Invalidate(Rectangle)只刷变化区域节点数影响小中等几十到几百个离屏缓存每个节点缓存 Bitmap最快但内存占用高最高上千节点或复杂图元源码默认走脏矩形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 ListGuid 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存盘就是平铺的数组读盘后重建一个DictionaryGuid, 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.DeserializeFlowDocument(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% 的性能退化。检查项合格线不达标先看哪里拖动单节点 GDI 对象数稳定不增长OnPaint 里未释放的 Pen/Brush100 节点拖动平均帧耗时小于 16ms抗锯齿开关、脏矩形范围连续拖动 10 分钟后内存波动小于 20MB事件订阅未解绑、路径对象泄漏缩放到 400% 后文字清晰度无锯齿无模糊文字是否随 Graphics 变换缩放导出图片这块有个经典坑用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 对象数盯上三分钟再决定要不要继续往下写功能——这个习惯帮我省掉了好几次上线前夜的返工。希望帮到你。本文还有配套的精品资源点击获取