简介这是一份专为C# WinForm开发者整理的CSkin UI库源码解决传统WinForm界面粗糙、控件样式单一的问题适用于需要快速产出美观桌面客户端的项目场景。源码围绕皮肤管理核心展开包含皮肤配置解析、窗体与常用控件的自绘逻辑、多状态按钮与边框阴影实现并涉及事件处理、布局管理、控件扩展接口以及.NET Core/5兼容性处理有助于理解UI渲染机制和主题定制方法。压缩包共2000个文件其中560个cs源文件构成代码主体846个gif、230个png、213个jpg等图片素材用于皮肤与控件状态展示配套35个resx和33个resources资源文件、22个config配置、18个dll另含一批HTML、CSS及ASP.NET示例页面整包大小约25.24MB。已有1856人学习下载读者既能直接借鉴整套皮肤主题也能研习双缓冲、控件重用、延迟加载等性能优化技巧适合从入门到进阶的C#桌面开发者学习。1. 先说结论C# UI库 CSkin 源码是一套拿来就能换肤的 WinForm 皮肤引擎某开发者手上有一个跑了五六年的订单系统窗体里全是 WinForms 原生控件界面早就不符合现在的审美。改版计划里最麻烦的不是配色而是标准控件根本不提供“皮肤接口”每个按钮都要重写绘制改动量大到没法排期。CSkin 源码解决的就是这个场景一套 C# 的 WinForm UI 库源码核心是一个皮肤引擎在不改动业务控件使用方式的前提下用 GDI 自绘接管窗体和控件的背景、边框、文本实现整窗换肤。CSkin 源码适合两类人。一类是手里压着老 WinForms 工程的开发者升级界面时不想推倒整个控件层另一类是准备自己写控件库的人自绘、状态机、九宫格、无边框窗体这些基础设施它都集中在一个工程里。下文按“架构 → 运行 → 核心链路 → 避坑 → 改造”往下推涉及绘制细节的地方会用我的理解和常用做法补充方便你把源码跑起来之后再继续改。2. 架构拆解GDI 自绘引擎与控件皮肤分离的设计2.1 WinForm 换肤的三条路线CSkin 选的是哪一条要是你在 WinForms 里做过换肤一定会遇到三种方案。第一种是“换皮不换骨”只改 BackColor 和 FlatStyle把按钮的边框和颜色调一调这种方案对纯色主题还凑合一旦皮肤里要放贴图、圆角、渐变立刻露馅。第二种是“重写控件”继承 Button 然后重写 OnPaint业务代码倒是能继续用但每个项目里这些控件类散落各处最后各自维护各自的绘制越改越乱。第三种是“接管绘制链”CSkin 走的就是这条路它不要求你替换所有控件而是提供一套 SkinButton、SkinList、SkinForm 这样的“皮肤控件”它们从同一个自绘基类继承用同一套公共资源来画自己。三种路线的取舍可以粗略地用下面这张表表达方案改造范围能力边界维护成本只改颜色与 FlatStyle页面级只能换纯色做不了背景贴图和圆角低重写每个控件所有使用点能实现任意绘制中到高接管绘制链CSkin 思路替换控件类型覆盖绝大多数皮肤需求低到中表里第三行的实现成本其实可控因为替换控件类型在业务代码里大多是全局改类名事件、数据绑定、布局逻辑都还在工作量比重头写绘制小很多。这也是我个人更推荐老项目走第三条路的原因既不用把每个控件重写一遍又能把样式问题的修复点收敛到控件库内部。架构落地上CSkin 的做法是分成三个角色主题管理负责加载皮肤资源渲染器负责按状态取图、按九宫格切图控件只负责触发 Invalidate 和把渲染结果画出来。业务代码看到的还是 Button、ListBox 的事件模型底层画的东西已经完全是另一套了。2.2 皮肤状态机normal、hover、down、disable 每个状态画什么自绘控件要显得“像原生控件”第一件事是把状态机建出来。这里的状态指的是鼠标交互状态而不是窗体生命周期状态。常见做法是定义一组枚举再让渲染器根据枚举去取对应图层CSkin 源码里这套设计非常清晰。// 控件状态枚举顺序要与皮肤资源的切图顺序一致 enum SkinStates { Normal 0, // 常规状态 Hover 1, // 鼠标悬停 Pressed 2, // 鼠标按下 Disabled 3 // 禁用 } // 渲染器按状态从皮肤资源包中取背景图 class SkinRenderer { private Bitmap[] m_images; // 初始化时按 Normal/Hover/Pressed/Disabled 顺序加载 public Bitmap GetBackground(SkinStates state) { // state 强转成数组下标取对应状态的背景图 return m_images[(int)state]; } }这里最需要注意的是枚举顺序和图片数组顺序必须严格一致。如果美术出图时把 hover 和 pressed 的顺序错了就会出现“鼠标按下去反而显示悬停态松开才变按下态”的怪异现象看上去像是脚本里状态写反实际上只是资源索引对不上。这个过程我在项目里踩过一次排查了很久才发现是资源打包顺序的问题。很多第三方皮肤包会直接约定一套文件名规范比如 button_normal.png、button_hover.png、button_pressed.png、button_disabled.pngCSkin 的资源组织也类似。这样做的好处是换皮肤时可以整体替换资源目录渲染器代码一行都不用改。平时我写自绘控件时会再往这个状态机上加一层保护状态变化时先判断是否真的变了没变就不触发重绘防止鼠标不停抖动时 Invalidate 被高频调用。2.3 九宫格与透明窗体皮肤不糊的底层原理状态机解决的是“画什么”九宫格解决的是“怎么画才不变形”。按钮宽度固定时问题不大但窗体在运行时可大可小直接把整张背景图拉伸圆角部分会被拉成椭圆边框粗细也会跟着失真。CSkin 的做法是把背景图切成 3x3 的九块四个角不缩放四条边只延展中间区域这样窗体无论拉伸到多大圆角永远保持原图比例。// 将目标区域按九宫格方式分成 9 个小矩形区域 // left/top/right/bottom 分别表示四边不参与拉伸的像素宽度 Rectangle[] SplitNine(Rectangle bounds, int left, int top, int right, int bottom) { int w bounds.Width; int h bounds.Height; return new[] { // 第一行左、中、右 new Rectangle(0, 0, left, top), new Rectangle(left, 0, w - left - right, top), new Rectangle(w - right, 0, right, top), // 第二行 new Rectangle(0, top, left, h - top - bottom), new Rectangle(left, top, w - left - right, h - top - bottom), new Rectangle(w - right, top, right, h - top - bottom), // 第三行 new Rectangle(0, h - bottom, left, bottom), new Rectangle(left, h - bottom, w - left - right, bottom), new Rectangle(w - right, h - bottom, right, bottom) }; }参数说明left/top/right/bottom 对应背景图四边边缘的宽度比如窗体背景圆角半径是 12 像素那这四个值至少设为 12。中间那块会被拉伸但它通常是纯色或渐变怎么拉都看不出来四个角保持原像素尺寸视觉上就能维持圆角清晰。这套逻辑不只用于窗体背景按钮、列表项、输入框的边框都能复用所以一般控件库会把它做进渲染器而不是让每个控件自己实现。无边框窗体是另一条线把 FormBorderStyle 设为 None然后用 Region 把窗体裁剪成圆角矩形再把标题栏和边框的绘制全部搬到自绘流程里。这里有个容易忽略的点Region 裁剪后鼠标点击落在被裁掉的透明区域时窗体根本收不到消息所以还需要在第 4 章要讲的 WM_NCHITTEST 消息里自己处理命中测试把那些区域算成可拖动区域或点击穿透区域。3. 目录与运行从解压到把皮肤跑进你的窗体3.1 源码目录长什么样先分清四块再动手把 CSkin 源码解压开后文件夹虽然多按功能可以归成四块全局基础设施、控件集合、皮肤资源、示例工程。理解这四块比记路径更重要因为二次开发时你会频繁在这几个目录之间跳转。目录职责典型内容阅读优先级基础设施Win32 API 封装、消息常量、渲染器基类高决定整体机制控件集合SkinForm、SkinButton、SkinListBox 等高看具体实现皮肤资源图片、默认主题文件中改样式时用示例工程展示各种控件效果的 Demo高最先运行解压后大致是这样一个结构目录CSkin/ ├── CSkin/ # 控件库主工程源码 │ ├── Control/ # 自绘控件的分类目录 │ │ ├── SkinForm/ # 窗体基类处理标题栏和边框 │ │ ├── SkinButton/ # 按钮相关控件 │ │ └── SkinListBox/ # 列表相关控件 │ ├── Render/ # 渲染器与九宫格处理 │ ├── Win32/ # Win32 API 封装与消息常量 │ └── Resources/ # 默认皮肤资源 ├── Demo/ # 示例工程 └── Theme/ # 主题与皮肤资源目录我在读这类源码时的习惯是先看 Win32 和 Form 基类再看一个最简单的按钮控件最后回来看资源目录。窗口基类决定了消息从哪进来按钮控件决定了绘制怎么落地资源目录则决定了一张图怎么变成实际效果。按这个顺序读下来每个文件的作用就会串成一条线而不是打开一个文件看一个函数。这个结构对二次开发的意义在于你想加一个控件时照着 SkinButton 复制改造就行想换整体风格时只需要动 Render 和 Theme完全不用碰控件类里的业务逻辑。3.2 编译框架版本、平台目标和三个容易忽略的选项源码引入工程的方式有两种。第一种是直接把 CSkin 工程加入你的解决方案项目间引用好处是调试时能 F11 直接进自绘代码第二种是把它编译成 DLL然后在你自己的项目里添加引用。我的习惯是短期内只需要用现成控件就选 DLL 引用打算长期维护主题效果、自己改绘制逻辑就选项目引用否则每次源码改动都要重新编译 DLL很容易出现“改了没生效”的错觉。编译前先确认三个环境选项这三项踩中任何一个都会遇到玄学问题。第一是目标框架版本这类老库大多面向 .NET Framework 4.x如果你的新工程是 .NET 6/8 的 Windows Forms直接把源码搬进来会碰到目标框架不兼容建议先把老库保持在 .NET Framework 4.6.2 或 4.8 上跑通整体迁移往后放。第二是平台目标代码里大量使用 User32/GDI32 的 P/Invoke 时AnyCPU 在 64 位调试下可能表现出不同的消息行为建议固定成 x86 或 x64 再跑。第三是高 DPI 支持需要 app.manifest 里声明感知方式不声明的话一旦系统缩放比例不是 100%绘制坐标和实际像素就会脱节。用 Visual Studio 打开解决方案后把 Demo 项目设为启动项目直接 F5 就能看到全部皮肤控件的效果。如果编译时报“未能加载文件或程序集”绝大多数情况是主工程和 Demo 的目标框架版本不一致把两边的 TargetFramework 对齐再编译就能过。3.3 第一个能跑的换肤示例让按钮用上皮肤跑通 Demo 之后落地到业务项目里其实就两步换窗体基类换按钮类型。事件订阅和数据绑定完全不动。一个最小可运行的示例是这样的// 把默认窗体换成 CSkin 的基类窗体 public partial class MainForm : SkinMain { public MainForm() { InitializeComponent(); // 原生 Button 替换成 SkinButton SkinButton btn new SkinButton { Text 保存订单, Size new Size(120, 34), Location new Point(20, 20), // Style 对应主题资源里的皮肤名 Style Default_Button }; // 业务事件照常挂跟原生按钮没区别 btn.Click (s, e) MessageBox.Show(点击); Controls.Add(btn); } }这里有三个点值得说明。第一SkinMain 是窗体基类它会处理无边框窗体和背景绘制如果你的窗体是从 Form 继承的换肤时把它改成 SkinMain 即可。第二Style 属性是皮肤控件与主题资源的连接点它通过名字映射到主题资源里的某个按钮样式换一组主题资源时控件不用动只要映射关系指到另一套资源名就能整体换肤。第三Click 事件是控件自己内部触发并转发出来的业务代码完全感知不到皮肤层的存在。实际项目里如果不想替换现有窗体的基类也可以不继承 SkinMain只把背景透明化再叠一个皮肤容器但窗口边缘的圆角和标题栏就得自己画建议新手不要走这条路。老老实实用基类才是把换肤成本压到最低的做法。4. 核心模块拆解一个控件从绘制到事件触发的完整链路4.1 入口SkinMain 如何接管窗体的标题栏Windows 窗体的标题栏和边框属于非客户区平时是系统画的。要在标题栏上放自定义背景和按钮就得拦截 WM_NCPAINT 和 WM_NCHITTEST 这两个消息。SkinMain 基类的处理逻辑大致是这样一个骨架protected override void WndProc(ref Message m) { switch (m.Msg) { // 非客户区绘制 case WM_NCPAINT: base.WndProc(ref m); // 系统画完边框后再覆盖绘制自定义标题栏背景 PaintNonClientArea(); return; // 命中测试决定鼠标在窗口哪块区域 case WM_NCHITTEST: base.WndProc(ref m); // 窗体客户区返回 HTCLIENT这里改成 HTCAPTION 以便拖动 if (m.Result (IntPtr)HTCLIENT) { m.Result (IntPtr)HTCAPTION; } return; // 双击标题栏时最大化/还原 case WM_NCLBUTTONDBLCLK: if (m.WParam.ToInt32() HTCAPTION) { ToggleMaximize(); return; } break; } base.WndProc(ref m); }参数说明WM_NCPAINT 分支里先调 base.WndProc 再画是为了让系统先把窗口激活状态处理完然后自定义绘制覆盖在上面。WM_NCHITTEST 的返回值决定鼠标消息最终发给谁返回 HTCAPTION 表示这个区域等同标题栏这样圆角窗体边缘的空白区域也能拖拽移动。如果这里漏了处理就会出现窗体看起来是圆角的但边缘一圈怎么拖都拖不动的别扭手感。除了这两个消息无边框窗体还要处理 WM_NCCALCSIZE它负责告诉系统客户区的大小。因为 FormBorderStyle 已经设成 None系统默认会把整个窗口都当成客户区如果不主动调整计算方式自绘标题栏时会发现内容区域顶到了窗口最上方像标题栏被“吃掉”了一块。这层消息拦截是整个换肤机制里最容易被忽视却又最核心的入口控件层的所有自绘都建立在它确定的客户区范围之上。4.2 三层绘制背景、边框、文本的先后顺序不能乱进入控件 OnPaint 之后渲染顺序是背景 → 边框 → 前景内容。这个顺序一旦乱掉就会出现圆角四周有杂色、文本被框线盖住等奇怪现象。写自绘控件时我会把 OnPaint 拆成三个明确的步骤CSkin 控件同样遵循这个规律protected override void OnPaint(PaintEventArgs e) { Graphics g e.Graphics; g.SmoothingMode SmoothingMode.AntiAlias; // 圆角需要抗锯齿 Rectangle bounds ClientRectangle; // 第一步背景。先裁剪圆角路径防止图片溢出到圆角外 using (GraphicsPath path CreateRoundRectPath(bounds, 6)) { g.SetClip(path); // 根据当前状态渲染对应的背景图或纯色 g.DrawImage(renderer.GetBackground(uiState), bounds); g.ResetClip(); } // 第二步边框用主题色画一圈描边 using (Pen pen new Pen(renderer.GetBorderColor(uiState), 1f)) { g.DrawPath(pen, CreateRoundRectPath(bounds, 6)); } // 第三步文本与图标垂直居中绘制 TextRenderer.DrawText( g, Text, Font, new Point(0, (bounds.Height - Font.Height) / 2), renderer.GetForegroundColor(uiState), TextFormatFlags.HorizontalCenter | TextFormatFlags.NoPadding); }这段代码的核心在于裁剪。背景图直接贴到整个控件区域会在圆角外留下方形底先 SetClip 再 DrawImage就能把超出圆角的部分裁掉。Pen 的宽度虽然写成 1f但 GDI 在绘制时会自动把线条落到像素边界上视觉上经常变成 2 像素。常见做法是给路径内缩 0.5f之后就不会再为“边框粗细不一致”这个事烦恼。文本这里用 TextRenderer 而不是 g.DrawString是因为 GDI 字体的渲染效果与老系统更匹配不会出现换了皮肤之后字体跟系统字体错位的突兀感。如果你在浅色皮肤下看不太出问题换成深色背景再看就会发现抗锯齿没开的圆角边缘会有一圈明显的白色像素残边。这个问题在浅色背景上被盖住了深色主题下会特别扎眼。所以 SmoothingMode.AntiAlias 这行不是性能优化可以砍掉的东西它直接影响圆角边缘质感。4.3 状态切换与事件转发从鼠标消息到业务委托绘制层之外还需要输入层。鼠标进入、按下、离开这些动作不直接触发业务事件而是先修改控件状态再触发重绘。因为 OnPaint 每次绘制时读的是 uiState 这个字段只要状态一变Invalidate 一调下一帧画出来的背景就是另一种状态图视觉反馈就有了。// 鼠标进入时切换到悬停状态 protected override void OnMouseEnter(EventArgs e) { base.OnMouseEnter(e); SetState(SkinStates.Hover); } // 鼠标按下时切换到按下状态 protected override void OnMouseDown(MouseEventArgs e) { base.OnMouseDown(e); if (Enabled) { SetState(SkinStates.Pressed); } } // 统一的状态切换入口状态没变就不重绘 private void SetState(SkinStates newState) { if (uiState newState) return; uiState newState; Invalidate(); }事件转发是最后一步。SkinButton 对外暴露 Click、MouseDown 这些标准事件内部在合适的时机调用事件委托业务代码完全不用感知皮肤层有没有被替换。这意味着未来要是想把 SkinButton 换回系统 Button业务代码基本不用动。这种“绘制内聚、事件外抛”的设计是它比在项目里散落一堆自定义绘制代码要好的原因。有朋友会问状态机能不能顺带做动画我的建议是别把动画逻辑塞进状态机。状态机只负责记录“当前处于哪个状态”动画应该由渲染器或一个独立的定时器驱动。比如按钮从 Hover 变回 Normal 想做淡出渲染器里加一个 progress 字段做插值就行状态机的职责不要扩大。5. 避坑记录DPI、闪烁与GDI对象泄漏的排查5.1 DPI 下控件错位字体和九宫格缩放没跟上现象在 100% 缩放下样式一切正常系统改成 125% 或 150% 之后字体被放大而控件长度没变背景边缘出现白边圆角窗体的圆角也变方了。原因窗口坐标被系统按缩放比例放大了但皮肤资源里的位图还是按原像素尺寸绘制九宫格的四边距离也没有跟随 DPI 变化相当于两套坐标系混在同一个窗口里。很多老控件库在原始设计时根本没考虑过多分辨率这在 DPI 缩放比例大于 125% 的机器上会特别明显。解决在工程里加 app.manifest声明 DPI 感知方式并在程序启动时调用对应的 SetProcessDpiAwareness 接口绘制时用 g.DpiX 和 g.DpiY 对九宫格边距乘缩放系数。对已经写死固定边距的地方建议全局搜九宫格入参统一改成动态计算。如果只是临时演示不涉及新机器部署也可以把系统锁在 96 DPI 下跑但这不是长久之计。提示DPI 问题改起来最麻烦的地方在于它是“环境相关”的很多开发机是 100% 缩放测试机是 150%验收时才发现错位。建议只要是自绘控件开发期就开一台 125% 缩放的机器专门验证。5.2 窗体拖动时白块闪烁现象拖动窗体时自绘按钮和列表表面出现整片白块严重时整个窗口看起来在抖像是没画完就被擦掉了。原因WinForms 默认的绘制流程是“先擦后画”OnPaint 执行前系统会先发 WM_ERASEBKGND 消息把背景刷成白色再走绘制逻辑。自绘控件如果没关掉这个擦除流程擦除和绘制之间存在一个空窗期视觉表现就是闪烁。解决在控件构造函数里把自绘模式和双缓冲全部打开我习惯统一写成这一句SetStyle( ControlStyles.UserPaint | ControlStyles.AllPaintingInWmPaint | ControlStyles.OptimizedDoubleBuffer | ControlStyles.ResizeRedraw, true);这四项设置的含义分别是UserPaint 表示控件自己负责绘制AllPaintingInWmPaint 让系统不再单独发 WM_ERASEBKGND把擦除和绘制合并到一次消息里OptimizedDoubleBuffer 开启双缓冲ResizeRedraw 让控件尺寸变化时自动重绘。设置完之后拖动卡顿和白块基本能消除。如果个别控件还闪检查父容器是不是也在自绘父子都在画同一块区域时会出现二次绘制这种属于层级问题不单纯是双缓冲能解决的。5.3 GDI 对象暴涨画笔和画刷没有及时释放现象程序跑一天或切换主题多次后窗口里的控件开始消失窗体变成半透明块系统弹“内存不足”但进程占用内存其实不高。原因OnPaint 里 new 出来的 Pen、Brush 会进入托管堆但 GDI 句柄的释放是由非托管资源的析构决定的托管对象被 GC 回收不代表句柄立即释放。绘制频率高的时候创建速度超过释放速度GDI 对象数就一路往上走直到逼近系统上限整个进程就变得像黑匣子一样什么都画不出来了。这是我项目里真实遇到过的血泪经验。解决所有临时画笔、画刷、字体都用 using 包裹作用域结束就释放高频使用的画刷从渲染器里的缓存取只在主题切换时统一释放重建。排查时用任务管理器加“GDI 对象”列连续切换主题十次如果对象数没有回落说明有句柄漏了。这个指标在自绘控件库里等同于内存泄漏指标需要跟内存占用一起盯。5.4 换肤后按钮点不动事件失灵现象皮肤按钮显示正常但业务 Click 事件偶尔或完全触发不了有时又变成点两次才生效事件好像被什么东西吞掉了。原因常见有两处。一是自绘控件设置了透明背景透明区域的命中测试返回了 HTTRANSPARENT鼠标直接穿透过去二是控件上方叠了一层皮肤绘制容器容器拦截了鼠标消息业务控件反而接不到。这两种情况排查起来都容易让人怀疑是不是事件订阅写错了其实消息根本没到你订阅的那一层。解决先用窗口句柄查看工具看鼠标点击落在哪个窗口确认是不是有覆盖层挡着然后在 WndProc 里检查 WM_NCHITTEST 分支确保控件主体返回 HTCLIENT。透明背景只是视觉属性不要影响命中测试结果。叠加层容器要设置成不接收鼠标事件把点击原样交给下层业务控件。事件失灵这类问题最怕凭感觉改代码按消息链路查一遍定位到是哪一层吞了消息再针对性修就很快。这四条基本覆盖了自绘控件库最常见的坑。排查自绘界面问题时我建议的顺序是先看消息用工具确认鼠标和绘制消息到了哪一层再看 GDI 对象数排除资源泄漏最后才回头读绘制代码。多数所谓的玄学问题到消息这一步就定位了。6. 二次开发给 CSkin 扩展一套夜间主题的思路6.1 改造点把“皮肤资源包”抽象成“主题描述”CSkin 的默认皮肤以图片资源为主二次开发时如果想做夜间主题最省事的切入点不是去改渲染器而是先加一个主题描述类把每个状态的背景色、边框色、前景色集中定义出来。渲染器优先看图图片不存在或加载失败时退回用颜色画纯色背景和边框逻辑上完全兼容。// 主题描述把所有控件的状态色集中在一个类里 public sealed class ThemeDescriptor { public Color BackNormal { get; set; } public Color BackHover { get; set; } public Color BackPressed { get; set; } public Color Border { get; set; } public Color Fore { get; set; } // 直接在代码里构建夜间主题 public static ThemeDescriptor Dark() { return new ThemeDescriptor { BackNormal Color.FromArgb(30, 30, 30), BackHover Color.FromArgb(50, 50, 50), BackPressed Color.FromArgb(70, 70, 70), Border Color.FromArgb(80, 80, 80), Fore Color.White }; } }参数说明Dark 方法返回一个现成的夜间主题配置BackNormal 是普通状态背景BackHover 是悬停背景BackPressed 是按下背景Border 是描边色Fore 是前景文字色。实际项目里可以再加 Accent 强调色、Disabled 禁用色等字段按业务需要扩展即可。6.2 运行时换肤三件事遍历控件树、暂停布局、触发重绘代码层面的主题定义好之后运行时换肤要做三件事遍历控件树、对每个皮肤控件应用主题、最后统一重绘。遍历整棵控件树时最好用 SuspendLayout 和 ResumeLayout 包住避免换肤过程中布局系统反复计算窗体一闪一闪的。// 遍历控件树并应用主题 // 传入窗体根节点和主题描述 public static void ApplyTheme(Form form, ThemeDescriptor theme) { form.SuspendLayout(); // 暂停布局减少换肤过程中的重排 var controls CollectControls(form); // 递归收集所有子控件 foreach (var c in controls) { // 只处理实现了皮肤接口的控件 if (c is ISkinControl skinCtrl) { skinCtrl.SetTheme(theme); } } form.ResumeLayout(true); // 恢复布局并立即重排 form.Invalidate(true); // 全窗体重绘 }参数说明CollectControls 递归遍历 form.Controls 集合即可注意处理容器嵌套SetTheme 是给皮肤控件新增的接口方法内部把主题色保存下来再调 InvalidateInvalidate 参数为 true 表示子控件一起失效重绘。做完这套改造夜间主题、品牌色切换就只是换一个 ThemeDescriptor 的事图片资源没跟上时也不至于破相。从那以后我每次改动自绘控件都会强制走一遍三步验证先在 Demo 里把所有状态点一遍再用任务管理器盯 GDI 对象数最后把系统缩放到 125% 切一次再跑一遍。这三步在调换肤库代码时救过我很多次希望帮到你。本文还有配套的精品资源点击获取