简介：对于已有 Winform 项目、希望引入 WPF 高级界面的桌面端开发者，这份资料以 DataGrid 控件作为完整案例，系统讲解通过 ElementHost 实现两类框架互操作的流程。压缩包内共有二十九个文件，C# 源码文件、界面资源文件、配置文件、可执行程序等类型齐全，整体大小仅为 41KB，工程结构简单，适合快速阅读和参考修改。内容覆盖从创建 WPF 用户控件、在 Winform 窗体中挂载，到数据绑定与界面刷新的完整链路，重点说明了 DataContext 赋值、MVVM 解耦思想和跨线程更新界面的注意事项。通过实际代码和项目布局，读者能够理解混合界面开发中的关键技术节点，并直接迁移到自己项目中。该资源已有一千四百六十三人学习，对需要用更现代交互方式增强现有桌面应用的开发者来说，是一个省时高效的参考资料。 如果你的主力技术栈是Winform，但又眼馋WPF那些炫酷的控件、灵活的样式和MVVM式的数据绑定，那么"在Winform里调用WPF控件"绝对是你能用上的大杀器。今天我不讲空话，直接带你把这件事从原理到实战彻底跑通，包括那些文档里不会告诉你的坑。
1. 为什么Winform要请WPF来"外援"？
先说清楚一个很多人心里犯嘀咕的问题，既然选型时已经用了Winform，为什么还要费劲去调用WPF控件？这不是自找麻烦，而是Winform原生控件在某些场景下确实到了天花板。
1.1 Winform原生控件的天花板在哪里
Winform的控件体系基于GDI+，绘制效率高、上手快，但它的硬伤也很明显：控件外观基本是"死"的。你想做一个带圆角、阴影、渐变背景的按钮，要么用第三方皮肤库，要么自己去重写OnPaint，工作量不小。WPF这边完全不同，它的渲染基于DirectX，控件本质是"画"出来的，样式和模板完全解耦，改外观只需要换一套XAML模板，不需要碰逻辑代码。
再者是数据绑定能力。Winform虽然也支持数据绑定，但和WPF的依赖属性绑定、INotifyPropertyChanged自动刷新比起来，简直像手动挡和自动挡的区别。以前我在Winform里做一个实时刷新的仪表盘，用BackgroundWorker加Invoke刷新UI，代码里全是线程调度和委托调用。同样的效果用WPF的Binding，数据源一变界面自动更新，完全不用手动刷。
1.2 什么场景下"塞WPF控件"才是正解
要明确一点，我推荐的做法是局部嵌入，不是把整个项目迁到WPF。比较典型的场景有这么几类：
- 数据可视化类需求：图表、仪表盘、热力图、实时曲线，Winform下成熟的商业控件价格不菲，而WPF生态里的开源图表库（比如LiveCharts）功能强大、视觉效果好，完全可以直接嵌进来用。
- 复杂交互表单：WPF的DataGrid支持模板列，可以非常方便地在单元格里放按钮、复选框、下拉框。像热词里提到的"DataGrid某一行CheckBox选中后点击按钮删除"，用Winform的DataGridView做还得操心单元格绘制，WPF里用绑定加命令就干净利落。
- 界面美化和动效：WPF对动画、模糊、透明效果支持极好。如果你的软件需要做引导页、消息弹窗、炫酷的加载动画，用WPF实现比Winform硬画容易太多。
换句话说，当你的界面需求开始涉及动态效果、复杂数据绑定、灵活自定义外观这几点时，就是该考虑引入WPF控件的时候了。
2. 环境准备与最小可运行示例：先让控件"住"进来
方向定了，接下来先把环境跑通。核心思路很简单：Winform和WPF本是两个UI框架，它们的窗口句柄体系、消息循环机制都不一样，需要在中间加一个"翻译官"，也就是ElementHost。
2.1 ElementHost：Winform和WPF之间的"转换插座"
先理解一个概念：WPF的控件不是传统意义上的Win32控件，它没有独立的窗口句柄（HWND）。WPF整个界面是一个或多个Window，里面的所有控件共享一个可视化树。Winform的控件布局依赖HWND，它没法直接识别WPF的可视化树，所以需要ElementHost这个"转换插座"——它本身是一个Winform控件，有HWND，能放进Form里；同时它内部承载了一个WPF的HwndSource，负责把WPF内容绘制到Winform窗口中。
打个比方，Winform窗口是一间只支持两脚插头的房间，WPF控件是三角插头的电器，ElementHost就是那个万能转换插座，把WPF的"插头形状"变成Winform认识的"插座形状"。
2.2 手写一个最小示例：从项目创建到控件挂载
我不会一上来就给你一堆封装好的代码，我们先写最小可运行的版本，理解了它再去加功能。前提是安装好Visual Studio，建议2022版，我会用.NET Framework 4.8和.NET 6都测过，步骤几乎一样。
第一步，创建一个WPF用户控件库。新建项目，选择"C# - WPF用户控件库"，项目名可以叫WpfControlsLibrary。这个项目里默认会生成一个UserControl1.xaml，我建议把它改名成MyCustomControl，改法很简单：右键文件重命名，然后打开XAML文件和后台代码文件，把类名改成一致的MyCustomControl。
用一段简单的代码验证挂载效果。在MyCustomControl.xaml里写：
<UserControl x:Class="WpfControlsLibrary.MyCustomControl" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> <Grid Background="#1E1E2E"> <StackPanel VerticalAlignment="Center" HorizontalAlignment="Center"> <TextBlock Text="我是WPF里的控件" FontSize="20" Foreground="White" HorizontalAlignment="Center"/> <Button Content="点我试试" Click="Button_Click" Margin="0,10,0,0" Padding="10,5"/> </StackPanel> </Grid> </UserControl>后台代码加一个点击事件：
using System.Windows; namespace WpfControlsLibrary { public partial class MyCustomControl : UserControl { public MyCustomControl() { InitializeComponent(); } private void Button_Click(object sender, RoutedEventArgs e) { MessageBox.Show("WPF控件的按钮被点击了"); } } }第二步，在同一个解决方案下新建一个Winform项目。解决方案右键 -> 添加 -> 新建项目 -> 选择"C# - Windows窗体应用"。这里要注意，两个项目的目标框架最好保持一致，如果WPF用户控件库用的是.NET Framework 4.8，Winform项目也用4.8，省得遇到程序集加载兼容性的烦心事。
第三步，给Winform项目添加引用。右键Winform项目的引用 -> 添加引用，在项目选项卡里勾选WpfControlsLibrary项目。然后还要手动添加几个关键的Framework程序集，WindowsBase、PresentationCore、PresentationFramework，以及WindowsFormsIntegration。如果找不到，可以在程序集选项卡的搜索框里直接搜，默认会有。
第四步，在Winform窗体里使用ElementHost承载WPF控件。把Form1.cs的后台代码改成这样：
using System.Windows.Forms.Integration; namespace WinFormsApp { public partial class Form1 : Form { public Form1() { InitializeComponent(); // 创建一个ElementHost ElementHost host = new ElementHost(); host.Dock = DockStyle.Fill; // 实例化WPF用户控件 WpfControlsLibrary.MyCustomControl wpfControl = new WpfControlsLibrary.MyCustomControl(); // 把WPF控件赋值给ElementHost host.Child = wpfControl; // 把ElementHost加到窗体 this.Controls.Add(host); } } }这段代码的核心就是三件事：创建ElementHost、实例化WPF控件、把控件赋值给host.Child。赋值完成后，ElementHost会自动把WPF的界面"翻译"到Winform窗口里。按F5运行，窗体里应该能看到WPF控件的内容。
这里有个很关键的细节：初始化顺序。ElementHost的Child属性必须在Form的构造或Load事件中赋值，不要等到窗体已经Show之后再赋值，否则容易闪屏或出现空窗。另外，如果WPF控件本身有比较耗时的初始化逻辑，建议在Form的Shown事件里再挂载，保证主窗口先显示出来，再加载WPF内容，体验会好很多。
3. 双向通信与数据交互：控件不是摆来看的
界面挂上去了，接下来逃不过的就是数据交互。Winform和WPF虽然是两个世界，但它们的对象本质都是C#类，所以跨框架的通信比想象中要简单。我把通信方向拆成两个方向讲：从Winform到WPF，以及从WPF回传Winform。
3.1 Winform到WPF：直接操作依赖属性与控件属性
如果WPF控件暴露的是普通的CLR属性，那Winform这边直接赋值就行。比如我想在WPF的TextBlock里显示Winform端的一个变量，那就在MyCustomControl这个用户控件里写一个普通属性：
public string DisplayText { get { return MyTextBlock.Text; } set { MyTextBlock.Text = value; } }这里MyTextBlock是XAML里TextBlock的x:Name。然后Winform端直接这样调用：
wpfControl.DisplayText = "来自Winform的数据";如果在WPF控件里用了MVVM模式，ViewModel里的属性通常是依赖属性（DependencyProperty），赋值方式也是直接访问属性名即可，因为依赖属性本身就是一个.NET属性包装器。比如：
wpfControl.SetValue(MyCustomControl.SomeKeyProperty, value);这里多说一句，在Winform里访问WPF控件属性时，尽量用主线程。WPF的依赖属性绑定多线程限制很严，在非UI线程直接改属性会抛异常。
3.2 WPF回传Winform：事件、委托与Dispatcher的线程问题
WPF控件里的按钮点击、选择变化等交互，怎么通知Winform端？最直接的方式是定义事件。改造一下MyCustomControl：
public event EventHandler<string> DataSubmitted; private void SubmitButton_Click(object sender, RoutedEventArgs e) { DataSubmitted?.Invoke(this, InputTextBox.Text); }然后在Winform端订阅事件：
wpfControl.DataSubmitted += (s, value) => { MessageBox.Show("WPF回传的数据：" + value); };看起来简单，但有个大坑很容易踩：如果WPF控件内部触发了异步操作，或者数据来自另一个线程，事件触发的线程不一定是UI线程。比如你在WPF控件里用async/await加载了什么数据，完成后触发的事件在UI线程，那没问题；但如果用Task.Run触发，事件的接收方在Winform这边，就必须用Invoke方法切回UI线程。
最稳妥的写法是在Winform端加一个统一的调度方法：
private void SafeUpdateControl(Action action) { if (this.InvokeRequired) { this.Invoke(action); } else { action(); } }然后用它来包裹所有需要更新Winform控件状态的代码，避免跨线程操作异常。我见过不少人在这一步翻车，界面一卡要么假死要么频繁抛异常，多半就是线程切换没处理好。
3.3 数据共享的实际场景：集合绑定与实时刷新
实际开发中更常见的需求是共享列表数据，比如热词里提到的DataGrid某一行CheckBox选中后点击按钮删除。WPF的DataGrid配合MVVM，比Winform的DataGridView处理这种行内交互舒服得多。做法是：
在WPF的用户控件里，定义一个ViewModel，包含一个ObservableCollection<Item>集合，Item类实现INotifyPropertyChanged：
public class Item : INotifyPropertyChanged { public string Name { get; set; } private bool _isChecked; public bool IsChecked { get => _isChecked; set { _isChecked = value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(IsChecked))); } } public event PropertyChangedEventHandler PropertyChanged; }然后DataGrid绑定这个集合，删除按钮通过Command绑定到ViewModel的DeleteCheckedItems方法。Winform端只需把集合的数据源塞进去，剩下的界面刷新、行选中变色、删除逻辑全部由WPF这边自己解决。这种"各自管好自己那一亩三分地"的做法，能让代码边界特别清晰。
还要注意一点：Winform端往WPF的ObservableCollection跨线程加项时，同样需要在UI线程操作。如果你在后台线程往集合加数据，集合的CollectionChanged事件会触发WPF绑定更新，但WPF的UI线程约束会直接抛异常。解决方案是在WPF控件的代码里封装一个方法，内部通过Dispatcher.Invoke来做。
3.4 PropertyGrid只能查看不能修改的替代方案
热词里有一条"winform的propertygrid只能查看不能修改怎么办"，这个问题的原因通常是PropertyGrid绑定的对象没有实现ICustomTypeDescriptor，或者属性是只读的。如果你已经对PropertyGrid折腾了很久，不妨直接用WPF的DataGrid或者PropertyGrid姊妹控件来接管这个场景。在ElementHost里放一个WPF的DataGrid，把对象集合绑定进去，列模板里加上编辑框、下拉框，修改体验比原生的PropertyGrid还灵活。关键是，WPF的DataGrid绑定修改后的值会自动同步回数据源，不需要写一堆赋值代码。
4. 焦点、弹窗与渲染分层：最容易翻车的三个细节
说实话，写"第2章"的例子时如果你直接上手跑，大概率不会出事。但你一旦把项目往复杂了做，就会撞上Winform和WPF混搭时特有的问题，我把最容易翻车的三个坑拎出来讲清楚。
4.1 键盘焦点问题：WPF控件抢焦点不还给Winform
Winform和WPF各有自己的焦点管理机制，ElementHost夹在中间，焦点归属有时候会变得很奇怪。一个典型场景是：你在Winform界面上有几个文本框和一个WPF的DataGrid，用户用Tab键切换输入框，按了几次Tab之后焦点钻进了WPF控件里，然后就再也切不出来了。这是因为WPF控件内部自己维护了焦点作用域，Tab键的焦点移动在WPF的那棵可视化树里循环，根本不往外跳。
处理方案有两类。
一类是不改代码，靠设计规避：把WPF控件和Winform控件按区域严格分开，不要在一个表单里交错摆放，比如左边全部是Winform控件，右半部分是一个完整的WPF容器。这样用户在不同区域之间切换时，用鼠标点击自然而然完成焦点转移，不会靠Tab键跨域。
另一类是代码干预：监听WPF控件的LostKeyboardFocus事件，在焦点离开WPF控件前手动把焦点还给特定的Winform控件。或者在Winform窗体的KeyDown事件里拦截Tab键，强制跳到指定控件。这类方法我一般放在后期才做，因为你得先明确用户到底需要什么样的Tab顺序。
4.2 弹窗与下拉菜单被Winform层"盖住"
这是混搭UI的老大难问题。WPF控件里如果弹出一个上下文菜单、弹出下拉列表、或者用户点了一个按钮弹出子窗口，你会发现弹出来的内容经常跑到Winform的控件下面去，或者怎么调Z序都不对。原因是Winform窗口与WPF弹窗各自使用不同的HWND层级，Winform控件的Z序在某些情况下会盖住WPF的Popup。
解决思路有三层：
第一层，尽量用ElementHost的IsSynchronizedWithCurrentItem等布局机制，避免WPF控件和Winform控件重叠。出现遮挡通常是因为两者在界面上有交叉区域。
第二层，给WPF控件的元素设置Popup.AllowsTransparency="True"，让WPF的Popup能以独立窗口形式弹出，不会浸染到Winform的Z序环境里。它在WPF内部是以另一个顶层窗口的形式存在，只要不遮住Winform窗口，表现基本正常。
第三层，如果问题出在WPF内嵌的WebBrowser或者其他ActiveX控件上，那就真得看场景了，这类控件本身也有空域问题，混搭时更加挑剔。
4.3 空域问题：WPF与Winform的"谁在上谁在下"
说穿了，上述焦点和遮挡问题都源自一个底层概念——空域（Airspace）。WPF和Winform在同一个Form里共存时，实际上是一个区域内WPF在渲染、另一个区域Winform在渲染，它们之间的覆盖顺序不能像普通控件那样自由调整。Winform的控件总是会"穿透"到WPF的上层，除非你用ElementHost给它们划定边界。
举一个典型例子：WPF控件区域内放了一个Winform的PictureBox，想让PictureBox显示在WPF元素之上。这种事在"纯Winform"里很容易，放哪就盖哪，但在混搭环境里，PictureBox的HWND通常处于Winform窗口的顶级Z序，WPF的内容只能待在ElementHost这个"洞"里，没法覆盖PictureBox。
这个问题没有银弹。我的经验是，在混搭UI设计阶段就把界面分区做干净，避免WPF和Winform控件在同一个视觉区域里层层叠加。万一实在要重叠，优先把那个应该在上面显示的内容用对应框架的控件重新实现。
5. 性能、初始化速度与启动优化
Winform调用WPF控件，性能开销是绕不开的话题，尤其是首次加载，我实测下来会有明显的延迟。
5.1 首次加载为什么会卡顿
当你new一个WPF用户控件并赋给ElementHost时，背后要初始化WPF运行时环境、加载一堆WPF程序集（PresentationFramework、PresentationCore、WindowsBase等），还要做首帧渲染的初始化。这些加起来几百毫秒到一两秒都有可能，机器配置越差越明显。
另一个常见的卡顿是程序集加载抖动：如果WPF控件库很大，引用了一堆第三方DLL，第一次访问时JIT要编译这些程序集，也会拖慢速度。还有，如果你在WPF控件的构造函数里写了耗时操作，那加载时间就是肉眼可见地卡。
5.2 我实测有效的优化措施
第一，延迟挂载。不在Form的构造函数里创建WPF控件，而是放到Shown事件里，或者放到按钮点击、某个Tab页激活时再首次创建。这样至少保证主窗口先弹出来，用户不会觉得"整个程序卡住了"。
第二，减少WPF控件库的体积。把用不到的XAML资源删掉，不要在App.xaml里放全局样式和资源字典，WPF控件库通常没有App.xaml，但如果你从别处拷代码过来，可能带入一堆资源，全部加载很耗时。
第三，用静态类缓存WPF控件实例。如果某个WPF控件在多个窗口之间复用，可以考虑做成单例，创建一次，多个ElementHost之间挂载同一个实例，只要不频繁移除宿主就不会销毁。不过要注意，一个WPF控件实例同时给多个ElementHost用会有问题，必须是一个宿主对应一个实例。
第四，关闭不需要的WPF效果。特效和动画是WPF的卖点，但也是性能负担。如果WPF控件的视觉树很复杂，渲染开销会吃掉不少CPU和GPU资源。在Winform主机里嵌入时，可以设置RenderOptions.ProcessRenderMode为RenderMode.SoftwareOnly来避开GPU兼容性问题，代价是略降低绘制效率。优先保证稳定性和兼容性，大部分界面需求用不到GPU性能。
5.3 分辨率与缩放：别在低分屏上把布局撑爆
热词里提到"笔记本分辨率低"和"Winform界面高度过长"的问题，这在混搭场景里同样适用。WPF控件默认支持按DPI缩放，但Winform窗体没有完全适配DPI Awareness时，两者在缩放上会出现错位。一个典型例子是Winform窗体设成100%缩放，WPF控件却按125%缩放，结果控件内容比宿主大了一圈，出现截断。
我的做法是，在Winform项目的入口处声明PerMonitorV2 DPI感知，具体就是在Program.cs的Main方法上加上[STAThread]特性，并调用Application.SetHighDpiMode(HighDpiMode.PerMonitorV2)方法。如果项目是.NET Framework，可能需要手动在app.manifest里声明DPI感知。彻底适配后，WPF控件和Winform控件能按同一套缩放规则工作，不会出现互相错位。
6. 这个方案的边界：什么时候不适合用WPF控件
最后要泼一盆冷水，WPF控件不是万能的，有些场景硬塞反而会更痛苦。
6.1 高频实时刷新的复杂场景
如果有一个画面需要在短时间内刷新大量数据，比如高性能的工业监控界面每秒刷新几十个图表，WPF的绑定和渲染机制反而会成为瓶颈。WPF的依赖属性绑定在频繁更新时会产生额外开销，尤其是通过INotifyPropertyChanged触发时。在这种场景下，Winform的双缓冲绘制或者直接GDI+画反而更有优势。
我做过一个测试：一个实时波形控件，每秒刷新60帧，WPF的绑定性价比明显不如Winform重绘。所以高频、低延迟、简单的可视化，现在仍建议留在Winform原生环境。只有当界面复杂度上升、需要大量交互和动态样式时，WPF才值得引入。
6.2 混合UI的维护成本
一旦项目里混用两套UI框架，团队维护成本会上升。新同学得同时懂Winform和WPF的控件模型，排查问题时要同时考虑两种框架的控件行为。项目越复杂，这种成本越明显。我的建议是：引入WPF控件之前，先做技术评估，用表格列出哪些界面放在Winform、哪些放在WPF、数据如何交互、谁负责维护、将来怎么交接，不要因为几行炫酷的XAML上头。
如果项目还在早期，且整个系统都在标准Windows环境跑，我建议直接全量迁到WPF；但如果是维护了多年的Winform老项目，别急着重构，把WPF控件当作局部增强模块插入，既能快速见效又不伤筋动骨，这才是混搭方案真正的价值所在。
我在几个老项目里就是用这种方式，把原本死板的报表界面逐步换成了WPF的表格、图表和交互控件，每个模块迁移完都单独测试验收。整个过程风险可控，用户看到的是界面一步步变好，而不是大刀阔斧的重构事故。
本文还有配套的精品资源，点击获取
