简介：面向 C# WinForms 开发者及需要实现类 Visual Studio 停靠布局的桌面应用团队，这份 WeifenLuo.WinFormsUI.Docking 源码与示例包提供了可停靠面板的完整实现参考。其核心 DockPanel 支持顶部、底部、左侧、右侧停靠及浮动窗口，并包含自动隐藏、多文档界面组织等能力，适合用来研究布局控件底层逻辑、快速搭建专业级 MDI 界面或二次定制。压缩包共 196 个文件、约 540KB，以 85 个 cs 源码文件和 15 个 resx 资源文件为主体，配合 bmp、ico 界面素材、sln/csproj 工程文件及 bat 构建脚本，形成较完整的源码、示例与编译辅助结构。已有 489 人学习，说明其在 WinForms 停靠布局领域具有一定参考价值。读者可从中获得 DockState、DockContent 自定义、浮动窗口与自动隐藏等关键机制的实现线索，并借助示例项目理解控件在真实界面中的组织方式，为后续扩展和排错提供依据。尤其适合已有 WinForms 基础、希望补齐停靠布局实现细节的开发者参考。

1. 一个主窗体塞下十几个功能页，靠手写 SplitContainer 已经难以支撑

在维护跑了七八年的 WinForms 老系统时，常会遇到“C# DockPanel 停靠面板”这类需求：左边树、右边属性栏、中间一堆图表页，用户还想自己拖来拖去、关掉再打开、下次启动位置不变。手写 SplitContainer 加 TabControl 能拼出样子，但拖拽停靠、浮动窗口、自动隐藏、布局存盘这四件事，一件比一件难处理。WeifenLuo.WinFormsUI.Docking 这套源码和例子提供的正是这套能力：它把 IDE 那套窗口管理拆成可复用控件，主窗体放一个 DockPanel，业务页继承 DockContent，停靠方向、浮动、停靠区、布局序列化都是现成的。它适合正在给内部工具做工作台界面的 C# 桌面开发者，尤其是不能换 WPF、也不方便引入商业控件的项目；但它不是无成本的库，理解几个核心枚举和持久化约定后再接入，会比直接复制示例代码省力得多。

2. 把库跑起来：源码编译、NuGet 引用和第一个 DockContent

拿到一套 DockPanel 源码后，很多人第一反应是双击 sln 项目文件后按 F5，结果要么是缺某个 framework 目标包，要么是编译过了运行起来一片灰。本章提供可直接照着做的接入步骤：先选定接入路线，再把主窗体改造成容器，最后做一个能被停靠、能被序列化的页面。

2.1 三条接入路线，先根据项目约束选定一条

同一份源码有三种用法，选错会让后续维护成本翻倍。

我一般优先选 NuGet，除非明确要改绘制逻辑。源码包最大的价值其实在于“能读”，遇到停靠行为不符合预期时可以直接打断点看DockContentHandler怎么算的，而不是靠猜。如果你的项目需要二次分发且不能带第三方二进制，那就把WeifenLuo.WinFormsUI.Docking这个工程整个加进解决方案，注意它的输出目录和主项目的bin要一致，否则设计器加载控件时会报“无法加载程序集”。

还有一点容易忽略：这套库的不同分支目标框架不完全一样，老分支只提供 .NET Framework 的包，新分支会额外提供 .NET Core 及更高版本的目标。选包前先打开 nuspec 或项目文件的TargetFrameworks看一眼，比装完再报错省事。

2.2 主窗体改造：三步把普通 Form 变成停靠容器

不要去拖工具箱里那个DockPanel，手工写更可控。第一步建一个普通 WinForms 窗体，第二步在构造函数里创建 DockPanel 并铺满，第三步把主题和文档样式定下来。

// MainForm.cs using System.Windows.Forms; using WeifenLuo.WinFormsUI.Docking; public partial class MainForm : Form { private readonly DockPanel _dockPanel = new DockPanel(); public MainForm() { InitializeComponent(); // 1) 主题要在任何 DockContent 出现之前设置， // 否则已创建的面板拿不到主题样式 _dockPanel.Theme = new VS2015LightTheme(); // 2) 容器铺满窗体，别再套一层 Panel _dockPanel.Dock = DockStyle.Fill; _dockPanel.DocumentStyle = DocumentStyle.DockingSdi; _dockPanel.ShowDocumentIcon = true; // 3) 关闭拖动时的虚线预览，低配机器上体验更稳 _dockPanel.ShowAutoHideContentOnHover = true; Controls.Add(_dockPanel); IsMdiContainer = false; // 和 MDI 混用会打架 } }

这段代码有三个关键点。Theme赋值必须靠前，这是我在一个项目里排查了两小时才确认的问题：先Show面板再设主题，标题栏颜色会停留在默认样式，得重建面板才恢复。DocumentStyle决定中间文档区的行为，DockingSdi是单文档界面式（每个文档一个 Tab），DockingMdi会走 MDI 子窗体那套逻辑，SystemMdi则是真正的系统 MDI。业务系统里绝大多数情况用DockingSdi，它不依赖IsMdiContainer，也不会出现子窗体最小化后跑到主窗体左下角的情况。ShowAutoHideContentOnHover控制鼠标悬停自动隐藏条是否弹出内容，做演示系统时建议打开，做数据录入系统建议关掉，避免误触。

IsMdiContainer = false这行看着多余，但确实有人把它设成 true 后又放 DockPanel，结果浮动窗口关不掉。两者是两套窗口管理机制，不要混用。

2.3 第一个可停靠页面：继承 DockContent 而不是包 Panel

业务页面有两种做法：把已有的 UserControl 塞进一个 DockContent 容器，或者直接让窗体继承DockContent。前者改动小，后者能用设计器直接摆控件、能设图标和 Tab 文本，长期维护更舒服。

// SolutionPanel.cs using System.Windows.Forms; using WeifenLuo.WinFormsUI.Docking; public partial class SolutionPanel : DockContent { public SolutionPanel() { InitializeComponent(); // 关闭按钮只隐藏，不销毁实例 HideOnClose = true; // 只允许停靠在左侧，或者拖出来浮动 DockAreas = DockAreas.DockLeft | DockAreas.Float; // Tab 上显示的文本，也可在设计器里设 TabText = "解决方案"; } }

HideOnClose = true是这套库里最值得记住的开关。默认情况下点关闭按钮走的是Close()，窗体被 Dispose，而你代码里的字段还指着那个已销毁的实例，下次Show直接抛ObjectDisposedException。设成 true 之后关闭动作变成Hide()，实例和内部状态都保留，重新打开时滚动位置、选中项还在。代价是程序退出时要自己清理，别指望窗体自动释放。

DockAreas是权限边界，不是初始位置。它限制用户能把这个面板拖到哪，和Show时传的DockState是两回事。上例里用户只能把它停到左边或浮起来，想拖到底部会被拒绝，这个能力在做“日志面板不许停中间”这类需求时很好用。

页面做好后，在主窗体里调用：

// 在主窗体 Load 之后调用，保证 Handle 已创建 var solution = new SolutionPanel(); solution.Show(_dockPanel, DockState.DockLeft); var editor = new EditorPanel(); editor.Show(_dockPanel, DockState.Document);

Show(DockPanel, DockState)是这套库的标准入口，第一个参数是宿主容器，第二个是初始停靠位置。注意DockState.Document只对允许进文档区的面板有效，如果DockAreas里没包含Document，这行会静默失败或者把面板挤到别处，不报错。我第一次遇到时以为是库的缺陷，后来才发现是自己把DockAreas限死了。

2.4 首次运行必须过的四道关

第一道是目标框架和平台。库本身对 AnyCPU 友好，但如果你的项目里混了 x86 的原生依赖，浮动窗口在某些机器上会渲染异常，建议统一到 x64 或 x86，别留 AnyCPU 加Prefer32Bit的组合。

第二道是高 DPI。主窗体的AutoScaleMode设成Font，并在 app.manifest 里声明 DPI 感知级别，否则 125% 缩放下停靠条宽度会算错，表现为标签被裁掉一截。

第三道是中文界面。库内部的右键菜单、浮动窗口菜单文案走的是资源文件，默认只有英文，需要自己在资源项目里补一份本地化资源，键名对齐原资源。不想改资源也可以，用DockPanel暴露的字符串配置项逐条覆盖，只是条目比较多。

第四道是工具箱。设计器里找不到DockPanel是常态，右键工具箱“选择项”浏览到编译出来的 dll 即可。如果继承DockContent的窗体在设计器里报“无法为设计器创建实例”，临时把基类改成Form，设计完再改回来，这是老版本 Visual Studio 设计器的老毛病，和库本身没关系。

3. 停靠布局的核心参数：DockState、DockAreas 与文档区样式

把面板显示出来只是开始，真正决定体验的是“它能停在哪、默认停在哪、用户能不能改”。这三个问题分别由DockAreas、DockState、AllowEndUserDocking回答。理解它们的分工，能省掉大量“为什么拖不动”的排查时间。

3.1 DockState 的取值与业务映射

DockState是“当前处于什么位置”的状态量，既是Show的入参，也是运行时读取的属性。它的取值和业务语义可以这样对照：

DockState是可读可写的，读的时候拿的是当前真实位置，写的时候等价于重新停靠。比较稳的写法是通过DockHandler操作：

// 读取当前停靠状态 DockState state = panel.DockHandler.DockState; // 切到自动隐藏（贴边收起） panel.DockHandler.DockState = DockState.DockRightAutoHide; // 判断是否处于浮动状态 if (panel.DockHandler.IsFloat) { // 浮动窗口可以单独设位置和大小 panel.DockHandler.FloatPane.FloatWindow.Location = new Point(200, 200); }

DockHandler是每个 DockContent 背后的状态机，面板的停靠、浮动、显示隐藏都由它管。不要直接改panel.Parent或者panel.Dock，那会绕过状态机，导致布局树和实际显示不一致，序列化出来的 XML 也会错乱。这是踩过坑之后才养成的习惯：凡是涉及停靠位置的改动，一律走DockHandler。

3.2 DockAreas 与用户操作的权限边界

DockAreas是位标志枚举，决定“允许停在哪”。默认值通常是DockAreas.All，也就是用户想拖到哪就拖到哪。对工具类面板这没问题，但对文档类面板就得收一收。

// 属性面板：只允许停右侧或浮动，不许进文档区 propertyPanel.DockAreas = DockAreas.DockRight | DockAreas.Float; // 日志面板：只允许底部停靠和自动隐藏 logPanel.DockAreas = DockAreas.DockBottom | DockAreas.DockBottomAutoHide; // 禁止用户拖动整个面板（位置只能由代码控制） propertyPanel.AllowEndUserDocking = false; // 禁止用户把别的面板拖进来形成 Tab 组 propertyPanel.AllowEndUserNestedDocking = false;

AllowEndUserDocking和AllowEndUserNestedDocking是两个常被混淆的属性。前者关掉后，用户不能拖动面板本身；后者关掉后，用户不能把其他面板拖到这个面板的标题上形成标签组。做固定布局的看板类界面时，两个都关掉最省心；做灵活的 IDE 式工作台时，两个都保持开启。

有个细节：DockAreas里如果不包含当前DockState对应的值，面板会先被强制移走。比如面板本来在DockLeft，你把DockAreas改成只有Float，它会被弹出来变成浮动窗口。这个行为不报错，但会让用户觉得“面板自己跳走了”，运行时动态改DockAreas时要留意。

3.3 文档区：DocumentStyle 的四种模式差异

DocumentStyle只影响中间文档区，但影响很大。

DockingSdi是最常用的：每个文档是容器内的一个 Tab，不产生系统子窗体，任务栏上只有一个主窗口。适合绝大多数业务系统。

DockingMdi走的是 MDI 那套逻辑，文档窗口有独立的最小化/最大化按钮，但浮动行为会和停靠区打架，尤其是文档被拖出主窗口时容易出现空白区域。

DockingWindow会让文档区表现得像一个独立窗口，多屏场景下有用，但用户容易找不到主窗口。

SystemMdi是原生 MDI，配合IsMdiContainer使用，和停靠面板的其余部分关系不大，除非你在做老系统迁移，否则不建议。

切换DocumentStyle必须在没有任何文档打开的时候做，如果有文档存在再改，已经打开的文档不会重新布局，得全部关掉重开。这个限制在源码里没写注释，只能靠试。

3.4 停靠区宽度与嵌套比例

面板初始宽度是用户第一眼看到的东西。左边导航栏拉得太宽、右边属性栏挤成一条缝，都是常见抱怨。

// 主窗体初始化阶段设置各停靠区的初始占比（0~1 的相对比例） _dockPanel.DockLeftPortion = 0.20; _dockPanel.DockRightPortion = 0.24; _dockPanel.DockBottomPortion = 0.28; // 文档区中间的竖直分割线位置 _dockPanel.DocumentTabStripLocation = DocumentTabStripLocation.Top;

这里的Portion是相对比例而不是像素，用户拖动分割条之后会被覆盖成新值，并随布局一起序列化。所以不要在每次启动时无条件重设，否则用户调整好的宽度每次开机都被打回原形。正确做法是：只有首次启动（没有布局文件）时才用这组默认值。

如果某个版本的属性名被标记为过时或者改了名字，等价的兜底方案是直接改布局 XML 里对应节点的属性，比如根节点的DockLeftPortion。这也说明一件事：布局 XML 不只是给人看的存档，它本身就是一份可编辑的配置文件，遇到诡异的默认布局问题，打开 XML 看一眼比调半天代码快。

嵌套停靠（一个停靠区里再分上下两块）不需要额外代码，把两个面板Show到同一个DockState就会自动形成标签组；想让它们上下排列而不是叠成 Tab，需要先Show第一个，再用第二个面板的DockHandler指定相对位置。这部分源码里的示例工程有完整演示，直接跑一遍比看文档快。

4. 布局持久化：ToXml/FromXml 把用户的工作台存下来

用户花十分钟把面板摆成自己顺手的样子，第二天开机全乱，这是最伤体验的一类问题。这套库自带布局序列化，但它有明确的调用时机和匹配规则，用错了就是“存了也白存”。

4.1 为什么不能只存 DockState

有人图省事，退出时遍历所有面板把DockState存进配置，启动时再逐个Show。这条路走不通，原因有三个。

第一，DockState只能表达“在左边/在底部”这种粗粒度位置，表达不了停靠区里的嵌套结构、分割条比例、面板之间的先后顺序，也表达不了标签组。第二，浮动窗口的位置和大小完全丢失。第三，用户如果调整了两个左侧面板的上下顺序，这个顺序在DockState里根本没有对应字段。

库提供的SaveToXml/LoadFromXml是整棵布局树的快照，包含面板的持久化标识、停靠结构、分割比例、浮动窗口矩形、自动隐藏状态。它才是这套东西的正确用法。

4.2 序列化与还原的完整代码

// LayoutService.cs —— 布局存取封装 using System.IO; using System.Windows.Forms; using WeifenLuo.WinFormsUI.Docking; public static class LayoutService { private static string LayoutPath => Path.Combine(Application.StartupPath, "layout.xml"); // 保存：建议在窗体关闭前调用 public static void Save(DockPanel dockPanel) { // 先落临时文件再替换，避免写到一半崩溃留下坏档 string tmp = LayoutPath + ".tmp"; dockPanel.SaveAsXml(tmp); if (File.Exists(LayoutPath)) File.Delete(LayoutPath); File.Move(tmp, LayoutPath); } // 加载：失败要能回退到默认布局 public static bool Load(DockPanel dockPanel, DeserializeDockContent resolver) { if (!File.Exists(LayoutPath)) return false; try { // 返回值表示是否成功应用 return dockPanel.LoadFromXml(LayoutPath, resolver); } catch (Exception) { // 布局文件损坏或版本不兼容，删掉走默认布局 File.Delete(LayoutPath); return false; } } }

SaveAsXml传路径即可，内部会写 UTF-8 XML。先写临时文件再Move的写法看着啰嗦，但它救过我一次：用户在保存瞬间强制关机，直接覆盖导致的半截 XML 让程序每次启动都崩溃，而LoadFromXml抛的异常信息完全看不出是文件问题。

LoadFromXml需要第二个参数，一个把字符串映射回面板实例的委托。这是整个持久化里最关键的一环：

// MainForm.cs 中的解析器 private IDockContent GetContentFromPersistString(string persistString) { // 默认的 PersistString 就是类型的完整名称 if (persistString == typeof(SolutionPanel).ToString()) return _solutionPanel; if (persistString == typeof(PropertyPanel).ToString()) return _propertyPanel; if (persistString == typeof(LogPanel).ToString()) return _logPanel; // 返回 null 表示这个面板在当前版本不存在，库会跳过它 return null; }

调用时机也要对：

protected override void OnLoad(EventArgs e) { base.OnLoad(e); if (!LayoutService.Load(_dockPanel, GetContentFromPersistString)) { // 没有布局文件或加载失败，走首次启动的默认布局 ApplyDefaultLayout(); } }

必须放在OnLoad之后，不能在构造函数里调。构造函数阶段窗体句柄还没创建，浮动窗口恢复位置时拿不到屏幕信息，表现就是还原后所有浮动面板都堆在屏幕左上角。这个坑很隐蔽，因为它只在有浮动面板时才发作。

4.3 面板增删与版本升级的兼容处理

业务会变，面板会加会删。默认用类型全名做持久化标识，好处是零配置，坏处是重命名类或换命名空间后旧布局全部失配，用户升级后一片空白。

稳妥做法是重写持久化标识，用一个稳定的字符串常量：

public partial class SolutionPanel : DockContent { // 用固定串而不是类型名，重命名类不会影响旧布局 protected override string GetPersistString() { return "panel.solution"; } }

对应解析器改成匹配字符串常量。这样即使以后把SolutionPanel重构成NavigationPanel，旧布局文件依然能还原。

删面板时不需要做任何事，解析器返回null，库会忽略这个节点。新增面板则要小心：如果新面板在旧布局文件里不存在，它不会被自动显示，需要在Load返回true之后补一段“确保核心面板已显示”的逻辑：

// 布局还原后，兜底显示必须存在的面板 if (_dockPanel.Contents.Count == 0) { _solutionPanel.Show(_dockPanel, DockState.DockLeft); _editorPanel.Show(_dockPanel, DockState.Document); }

还有一种情况：用户从旧版本升级，布局文件里的面板数量比新版本少。这时还原出来的界面会缺几个入口，用户找不到功能就以为是 Bug。我的处理方式是在设置里放一个“重置界面布局”的菜单项，直接删布局文件后走默认布局，比在代码里做各种兼容判断省事，用户也容易理解。

5. 避坑与排查：五个真实踩过的坑

这套库文档不算多，很多行为要靠源码和实验确认。下面五条是按“现象—原因—解决”整理的高频问题，基本覆盖了接入初期的绝大部分翻车场景。

5.1 主题设置了但界面还是灰的

现象：代码里明明写了_dockPanel.Theme = new VS2015DarkTheme()，运行起来标签栏还是浅色，只有部分边框变了。

原因：主题设置晚于内容创建。主题在应用时会遍历当前已有的面板和皮肤对象刷新样式，之后再Show出来的面板虽然继承了容器主题，但内部子控件的颜色已经按旧样式初始化过，不会二次刷新。另外，面板里自己放的DataGridView、ToolStrip、TextBox这些标准控件根本不归主题管，它们只认BackColor/ForeColor。

解决：把Theme赋值放到InitializeComponent()之后、任何Show之前，这是唯一可靠的时机。子控件颜色在面板构造函数里显式跟随主题：

public PropertyPanel() { InitializeComponent(); var theme = DockPanel.Theme; // 从宿主容器取当前主题 if (theme != null) { // 具体颜色属性名随版本不同，用智能提示确认 BackColor = theme.ToolWindowBackColor; ForeColor = theme.ToolWindowForeColor; propertyGrid.BackColor = theme.ToolWindowBackColor; } }

运行期切换主题同理：换完之后要遍历_dockPanel.Contents逐个重设背景色，否则只有新打开的面板是新的配色。

5.2 关闭面板后再打开抛 ObjectDisposedException

现象：用户点面板右上角关闭，再从菜单打开，程序抛异常，堆栈指向Show。

原因：HideOnClose默认是 false，点关闭走的是真正的Close()，窗体被释放，而成员字段仍指向那个对象。这是最典型的“库没问题、用法有问题”。

解决：交互型面板统一设HideOnClose = true；如果确实需要释放（比如面板里有大图缓存），那就在关闭后把字段置 null，打开时重新 new 一个：

private EditorPanel _editor; private void ShowEditor() { if (_editor == null || _editor.IsDisposed) _editor = new EditorPanel(); _editor.Show(_dockPanel, DockState.Document); }

判断IsDisposed这一步不能省，只判 null 挡不住已经被释放的实例。

5.3 布局还原后文档区一片空白

现象：程序退出时保存正常，下次启动界面骨架都在，但中间的文档页没了，日志里也没有异常。

原因：三个可能，按概率排序是——解析器返回了 null（PersistString对不上）、LoadFromXml调用过早（句柄未创建）、文档内容本身是运行时动态创建的（比如根据数据库记录生成），启动时根本没实例可以返回。

解决：先确认解析器匹配用的是typeof(Xxx).ToString()还是自定义常量，两者必须和保存端一致；再把加载移到OnLoad；对于动态文档，还原时返回一个占位面板，或者干脆在还原后清空文档区，只恢复工具面板的布局。第三种情况是最常见的误会，文档页不是布局丢了，而是它本来就没有固定实例。

提示：排查时可以在解析器里打一行Debug.WriteLine(persistString)，看看实际进来的字符串长什么样，比对着 XML 猜快得多。

5.4 高 DPI 下浮动窗口标题栏错位

现象：125% 或 150% 缩放下，拖出来的浮动窗口标题栏高度不对，关闭按钮被裁掉，或者停靠条的标签文字下半截看不见。

原因：主窗体没有声明 DPI 感知，或者AutoScaleMode用了None/Dpi而库内部的尺寸计算是按字体算的。库的布局计算大量依赖字体高度，缩放模式不匹配时算出来的分割条宽度是错的。

解决：主窗体AutoScaleMode = AutoScaleMode.Font，字体用系统默认的Segoe UI/Microsoft YaHei UI而不要硬写固定尺寸；在 app.manifest 里声明 DPI 感知；如果项目不能改 manifest，在Program.Main里调用应用级 DPI 设置接口，让进程知道自己运行在缩放环境里。改完记得在 100%、125%、150% 三档下各跑一遍，只在 100% 下测等于没测。

5.5 一次显示十几个面板卡住两三秒

现象：带有“恢复上次会话”功能的程序，启动时批量Show十几个面板，界面冻结明显。

原因：每次Show都会触发布局重算，包括停靠树重建、皮肤重绘、浮动窗口创建。十几块面板串行处理，中间还会触发多次无效重绘，累积起来就是秒级卡顿。

解决：用挂起/恢复把批量操作包起来，让布局只算一次。

_dockPanel.SuspendLayout(); try { foreach (var panel in _panels) panel.Show(_dockPanel, panel.DefaultState); } finally { _dockPanel.ResumeLayout(true); // true 表示立即执行挂起的布局 }

ResumeLayout(true)的参数别漏，传 false 的话布局要等下一次消息循环才生效，某些情况下会看到面板闪一下才归位。另外，如果面板构造里有耗时操作（比如读配置文件、查数据库），把这部分挪到Load事件里异步做，不要放在构造函数里拖慢整个批量显示。

6. 主题、性能与验收：交付给用户前的最后一公里

主题这块有个现实约束：库的主题只负责它自己的标题栏、停靠条、分割线，业务面板里的控件得自己跟进。我的做法是抽一个IThemeAware接口，面板实现ApplyTheme(ThemeBase theme)，主窗体切换主题时遍历_dockPanel.Contents逐个调用。这样新增面板时不会漏掉配色，也不用在十几处地方复制粘贴颜色赋值。

public interface IThemeAware { void ApplyTheme(ThemeBase theme); } // 主窗体切换主题 private void SwitchTheme(ThemeBase theme) { _dockPanel.Theme = theme; foreach (IDockContent content in _dockPanel.Contents) { if (content is IThemeAware aware) aware.ApplyTheme(theme); } }

性能上除了批量显示时的挂起布局，还有两个值得做的优化。一是首次启动不要把所有面板都Show出来，只显示核心的几块，其余的在用户第一次点菜单时惰性创建，冷启动时间能砍掉一半以上。二是浮动窗口不要滥用，每个浮动窗口都是独立的顶层窗口，多了之后窗口管理器切换和 Alt+Tab 都会变卡。

验收环节我用一个固定清单走一遍，每次升级库版本或改主窗体布局代码都重跑：

这张表比任何自动化测试都实用，因为停靠布局的问题几乎都是“看起来对但差一点”，只能靠人眼在真实缩放下确认。我还有个习惯：发布前把布局 XML 打开，手工删掉一个面板节点再启动，确认程序能正常降级而不是崩溃——用户的布局文件被各种同步盘、清理工具破坏的概率，远比想象中高。从那以后我每次动主窗体布局代码，都强制把这张清单和质量检查走一遍，宁可多花二十分钟，也不想在客户现场发现浮动窗口跑到屏幕外面去。

希望帮到你。

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