简介：面向希望用C# Winform实现微信自动化的开发者，以FlaUI为自动化核心的完整工程，系统展示了定时任务、自动回复、群聊机器人三大功能的落地思路，覆盖从消息监听、界面元素定位到逻辑判断与模拟发送的完整链路，适合有一定Winform基础并想进阶UI自动化的学习人群。压缩包共含365个文件，约47.83MB，其中127个dll为核心依赖，55个cs源码文件对应主程序和消息处理、定时任务、配置管理模块，另有json和resources等用于存放规则与界面资源，文件结构便于按模块对照学习。目前已有659人学习下载。通过源码与工程目录可掌握FlaUI常用的元素查找、事件监听和用户交互方法，并能够基于配置文件快速修改自动回复规则或定时发送场景，参考价值集中体现在一套可直接改造的微信自动化管理框架。
1. 项目整体思路与方案选型
先说清楚我当时做这个项目的原因：公司运营那边每天要在微信上手动给一批客户发同样的通知文案，工作量不大但极其枯燥，一不小心还会发错对象。于是我想着能不能做一个Winform小程序，替运营把“打开微信、找到联系人、输入内容、发出去”这条链路自动化掉，让同事在界面上点个按钮就能跑。把需求拆解完，整个工具的核心就是如何稳定地“操作”微信PC客户端。市面上能走的路其实不少，但真正适合这个场景的并不太多。
1.1 为什么选FlaUI而不是模拟键鼠或逆向协议
最早我考虑过最暴力的方式：直接调用Win32 API，模拟鼠标移动和键盘输入，也就是让程序自己“演”一次人工操作。这种方案实现起来确实快，几行代码就能移动鼠标到指定坐标，然后发送回车。但缺点也相当致命：微信窗口一旦移动、缩放、或者屏幕上弹出一个聊天框，坐标就全乱了，维护成本巨高，完全扛不住真实使用。另一个方向是直接抓取微信的通讯协议，模拟客户端发包请求，这种方式效率和稳定性都最好，但是需要逆向分析、处理加密和风控，风险和工作量都很大，不适合一个内部工具。
所以我把目光放在微软官方的UI Automation技术上，也就是通过系统暴露出来的控件树来识别界面元素。Winform里要直接用UI Automation API写起来比较繁琐，于是我用的是社区里知名度很高的封装库FlaUI。FlaUI把UIAutomation接口封装得比较友好，不需要管COM对象生命周期，查找控件也方便，同时支持UIA2和UIA3两种模式。我选用的是UIA3模式，因为UIA3实现更完整，对微信这种基于自绘控件的程序识别效果普遍更好。
1.2 Winform在项目里的定位边界
这里要明确一点：FlaUI只负责“操作微信”，Winform只负责“给人用”。也就是说，Winform做配置界面、日志展示、任务调度，FlaUI做底层驱动，二者通过异步任务协作。我不建议把业务逻辑堆在窗体代码里，容易失控。我的做法是单独封装一个WeChatAutomation类，对外暴露连接、发送消息、获取未读列表等方法，Winform窗体只调用这些方法并绑定进度显示。
这种分层的好处是，哪怕后续微信升级导致底层控件选择器变化，也只需要改WeChatAutomation内部代码，界面完全不用动。对一个小工具来说，这种边界能省掉很多踩坑时间。
2. 环境准备与前置知识
动手写代码之前，环境配置里面有几个细节值得先说明白。很多人在第一步就翻车，不是FlaUI用不了，而是项目配置没对齐。
2.1 引入FlaUI依赖与项目整体配置
我用的是Visual Studio 2022，创建一个.NET Framework 4.8的Winform项目。为什么不用.NET 6以上的Winform？主要是考虑到有些内网办公电脑没有安装较新的.NET运行时，Framework 4.8基本上Windows 10/11自带的，部署最省心。然后通过NuGet搜索安装FlaUI.Core和FlaUI.UIA3，我把版本锁定在比较稳定的版本上，避免自动升级带来意外破坏。
安装完还需要注意两件事：第一，项目平台目标必须显式设为x64。微信PC客户端是64位进程，而Winform默认情况下是AnyCPU，在64位系统上会以64位运行，问题不大；但如果项目里勾选了“首选32位”，那一定跑不通，会直接报无法连接到目标进程。第二，微信必须以桌面方式登录运行，不能把它丢在托盘里最小化到隐藏。FlaUI本质上是读取系统UI Automation树，隐藏窗口的会话区域无法被正常识别。
2.2 微信客户端版本与基础操作流程
我开发时使用的微信版本是当时PC端3.9.x的某个版本，后来4.0版本在部分电脑上控件结构有变化，这点后面会专门说。这里先说正常流程：微信需要保持登录状态，界面语言建议中文，因为控件Name值会跟随语言切换。如果要在无人值守场景下跑，最好关闭微信的自动更新，同时把系统休眠设成“从不”，否则定时任务半夜跑着跑着机器睡过去了。
操作链路归纳起来其实就三条：找到微信主窗口、定位到目标控件、对控件执行动作。FlaUI执行动作并不是直接模拟鼠标点屏幕坐标，而是对控件对象调用Pattern，比如用Invoke调用按钮点击、用ValuePattern给输入框设置文本。这套机制比模拟键鼠靠谱得多，因为控件在屏幕上的位置变了也不影响。
3. 核心细节与关键实现
当你有了一个会动的Winform界面，真正决定自动化成败的就是控件识别和交互这两个环节。我把核心实现拆成三块来讲：连接窗口、搜索聊天会话、发送消息。
3.1 程序化连接微信主窗口
第一步是拿到微信主窗口的AutomationElement对象。可以通过进程ID去连接，也可以直接通过窗口标题查找。微信主窗口标题通常是“微信”，在登录成功后还会带登录用户的昵称，为了稳妥我直接用进程ID连接，然后从进程的MainWindow获取。
using FlaUI.Core; using FlaUI.UIA3; public class WeChatAutomation { private Application _app; private UIA3Automation _automation; private AutomationElement _mainWindow; public bool ConnectWeChat() { var processes = Process.GetProcessesByName("WeChat"); if (processes.Length == 0) return false; _automation = new UIA3Automation(); _app = Application.Attach(processes[0].Id); _mainWindow = _app.GetMainWindow(_automation); return _mainWindow != null; } }连不上主窗口时，绝大多数原因是权限不够。Winform程序需要以管理员权限运行才能访问属于当前桌面会话的UI自动化树，否则Windows会拒绝部分跨进程访问。我的处理办法是在app.manifest里把requestedExecutionLevel设为requireAdministrator。如果你不想每次弹UAC，至少也要保证微信和Winform工具以同一用户权限启动。
3.2 控件识别与搜索策略
微信聊天窗口里的控件并不是标准的原生控件，很多是自绘区域，但FlaUI依然能从上到下遍历出对应的列表项、编辑框和按钮。我习惯先用FlaUI自带的FlaUInspect工具截取微信窗口的控件树，找到“会话列表项”和“消息输入框”的特征。关键点在于：不同版本微信可能暴露不同的AutomationId，但Name比较稳定。所以我倾向于同时用条件组合查找，例如搜索ControlType为Edit且Name为“发送消息”的节点。
var editBox = _mainWindow.FindFirstDescendant(cf => cf.ByControlType(ControlType.Edit).And(cf.ByName("发送消息"))); var sendButton = _mainWindow.FindFirstDescendant(cf => cf.ByControlType(ControlType.Button).And(cf.ByName("发送")));这里要注意，FindFirstDescendant默认是深度优先遍历，如果页面上有大量会话消息，遍历可能会有点慢。如果感觉卡顿，可以先缩小搜索范围：先找到“会话”面板容器，再在容器内部查找子元素，效率提升明显。我自己实测下来，整个查找过程控制在几百毫秒以内，完全可接受。
3.3 向会话发送消息与回车逻辑
找到输入框后，用ValuePattern或者SetValue方法把文本填进去，然后点击发送按钮。UIA3环境下，微信输入框有时候ValuePattern不可用，这种情况下继续使用Focus加SendKeys组合。用SendKeys时要先让输入框获得焦点，接着发送文本，需要注意文本里的特殊字符比如花括号、加号会被解释为组合键修饰符，需要做转义。我的方案是优先用ValuePattern：
if (editBox.Patterns.Value.IsSupported) { var valuePattern = editBox.Patterns.Value.Pattern; valuePattern.SetValue(message); } else { editBox.Focus(); Keyboard.TypeSimultaneously(Keys.Control, Keys.A); Keyboard.Type(message); }发送时我倾向于调用回车而不是点按钮，因为微信输入框在回车时就会触发发送，减少了找按钮这一步。用FlaUI的Keyboard模拟回车也很简单：
Keyboard.Press(VirtualKeyShort.ENTER); Keyboard.Release(VirtualKeyShort.ENTER);回车发送有一个小坑：如果聊天内容是多行文本，你可能希望用换行而不是直接发送。这时需要把回车键换成用Shift+Enter组合换行，然后再单独触发发送。可以根据业务场景配置一个开关，默认是回车直接发送，避免自动回复时频繁误伤。
4. 实操全过程与代码整合
有了上面的基础能力，接下来就可以把它们整合到一个完整的流程里。这一节我按照从登录到自动回复的完整链路，展示实际落地时的关键代码和运行效果。
4.1 从连接窗口到发送一条消息
Winform界面上设置两个按钮，一个“连接微信”，一个“发送测试”。点击“连接微信”后，后台线程去执行ConnectWeChat，同时把日志实时追加到界面TextBox里。对于耗时操作，一定不要占用UI线程，否则界面会假死。
完整发送流程是这样的：先确保已连接到主窗口，然后根据联系人名称在左侧会话列表中查找对应条目。因为微信最近聊天的列表是按时间排序的，如果目标联系人不在会话列表里，就需要用到搜索框，输入联系人名称后回车，再定位输入框。搜索操作虽然多了一步，但稳定性比直接遍历聊天列表高很多。
public void SendMessage(string contact, string message) { var searchBox = _mainWindow.FindFirstDescendant(cf => cf.ByName("搜索")); if (searchBox != null) { searchBox.Focus(); Keyboard.Type(contact); Keyboard.Press(VirtualKeyShort.ENTER); Keyboard.Release(VirtualKeyShort.ENTER); Task.Delay(500).Wait(); } var editBox = FindMessageInput(); SetValueWithFallback(editBox, message); Task.Delay(200).Wait(); Keyboard.Press(VirtualKeyShort.ENTER); Keyboard.Release(VirtualKeyShort.ENTER); }这一步里Task.Delay必不可少。微信窗口的元素刷新有延迟，特别是搜索完联系人后，输入框并不会立刻准备好。我的经验是每次操作结束后至少等待300～500毫秒，有条件的话可以按固定状态轮询，比如等到输入框可用再执行下一步。起初我图快，把延迟全设为100毫秒，结果连续发送时经常丢消息。
4.2 实现自动回复与批量通知
为了支撑运营的需求，我在这个基础上设计了一个“关键词自动回复”模式。Winform界面上放一个DataGridView，用来维护规则表，每一行有三列：联系人关键词、匹配回复内容、是否启用。后台每2秒扫描一次微信主窗口中的未读消息列表，如果发现新消息且联系人名称匹配规则表中的关键词，就自动回复对应内容。
核心是一个定时轮询方法：
private async void TimerScanLoop() { while (_running) { try { var unreadItems = _wechat.GetUnreadItems(); foreach (var item in unreadItems) { if (rules.Any(r => item.Contact.Contains(r.Keyword))) { var rule = rules.First(r => item.Contact.Contains(r.Keyword)); _wechat.SendMessage(item.Contact, rule.Reply); } } } catch (Exception ex) { Log(ex.Message); } await Task.Delay(2000); } }GetUnreadItems内部会遍历会话列表，读取每个列表项的名字和未读徽标。有的版本未读数不是独立控件，而是直接拼在列表Name里，比如“张三(3)”，所以解析时要多一步字符串处理。我比较推荐的做法是读取列表项Name之后，用正则提取括号或点前缀，再判断是否为新增未读。还要自己维护一个已处理的会话集合，避免同一消息被重复回复。
这里我要特别提醒一点：自动回复这种功能一旦跑起来是有风险性的，代码里一定要做二次确认。至少要在界面上显示“最后一次回复时间”、“回复内容预览”，以及一个紧急停止按钮。真实场景中，同事看到自动回复内容有错别字，点一下停止比杀进程要友好得多。
4.3 Winform窗体缩放与控件布局的经验
热词里提到“winform 窗体缩放 尺寸改不了”，我估计很多人都遇到过窗口大小调整后，控件跟不上。简单说两点：一是设置好窗体FormBorderStyle，如果希望用户能缩放就别用FixedSingle；二是内容面板要配合TableLayoutPanel或Dock属性做自适应。我自己的工具主界面左侧是联系人规则列表，右侧是日志区，分别设置了Dock=Left和Dock=Fill。
如果使用固定的像素间距，在高DPI缩放下会显得特别小或错位。需要在Program.cs入口提前调用SetProcessDpiAwareness，并让Winform对系统DPI感知。具体可以这样：
[DllImport("user32.dll")] private static extern bool SetProcessDPIAware(); [STAThread] static void Main() { SetProcessDPIAware(); Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MainForm()); }不处理DPI的话，在2K或4K屏幕上会出现窗口模糊、按钮错位的问题，这一点在写自动化工具时尤其明显，因为模糊的界面虽然不影响UI Automation识别，但影响人工检查状态。
5. 常见坑点与排查技巧实录
自动化工具写完了，真正花时间的不是开发，而是跑一段时间之后处理各种不稳定因素。下面这些坑我和同事在测试过程中都真实遇到过，整理成速查表供参考。
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 连接微信主窗口返回null | 进程名不对或者权限不足 | 确认WeChat.exe进程名；以管理员运行工具 |
| 找不到输入框/发送按钮 | 微信版本升级控件结构变化 | 用FlaUInspect重新抓取控件属性，更新选择器 |
| 发送内容总是少字符或乱码 | 中英文切换、快捷输入法干扰 | 关闭输入法；用ValuePattern而不是模拟打字 |
| 搜索联系人后没有结果 | 界面还在刷新，等待时间不够 | 增加轮询，等待搜索列表项出现 |
| 程序运行几小时后变慢 | 未释放UIA3Automation资源 | 每个操作循环结束后调用Dispose，或复用单例并延迟释放 |
| 断网后自动回复失效 | 微信本身进入离线状态 | 检测主窗口Title，包含“微信”但无网络时停止操作 |
5.1 控件识别不到？先怀疑元素引用和延迟
FlaUI最典型的坑是“对象已分离”。我们在循环中保存了一个AutomationElement，下一次再访问它的属性时，如果微信里对应的控件已经重建，就会抛异常。微信是自绘界面，列表项滚动后控件会不断创建和销毁，必须每次操作都重新查找最近的可交互元素，不要缓存控件长引用。
另外我发现把查找条件写得太严格反而容易出错。比如用AutomationId=“1001”做精确匹配，某些版本里这个ID会变，但Name=“发送”一直稳定。所以我现在的写法是Id和Name综合评分，先用Name找，找不到再降级为ContainsName模糊匹配，这样能在不同版本上通用。
5.2 微信版本更新与兼容性策略
我在开发后不久，微信有一次大版本升级，旧脚本果然跑不起来了。崩溃点主要在输入框的ControlType从Edit变成了Document，查找条件直接失效。之后我养成了一个习惯：把定位条件全部放到外部配置文件里，比如JSON或XML，代码运行时动态读取。每次微信更新以后，我只重新抓取一次控件树，更新配置文件，不需要重新编译整个程序。
{ "SearchBox": { "Name": "搜索", "ControlType": "Edit" }, "InputBox": { "Name": "发送消息", "ControlType": "Document" }, "SendButton": { "Name": "发送", "ControlType": "Button" } }这种做法的好处显而易见，尤其对于自动化小工具来说，可维护性比性能更重要。
5.3 稳定性保障和错误隔离
最后再分享一点架构上的经验。自动化过程只要有一个环节出错，比如某条消息发送失败，不应该影响下一条。所以我在每个联系人发送任务外面都加了try/catch，并把异常信息写到单独的队列里，由界面的日志线程统一打点。连续失败超过3次就自动暂停整个任务，避免出现“会话定位偏了，疯狂给错对象发内容”的灾难。
起初我还做过一个最小化到托盘的功能，后来发现Winform窗口一旦最小化，虽然UI Automation树还在，但某些隐藏控件的Pattern会失效。干脆把窗体设计成始终置顶的小面板，操作过程中也不允许用户手动缩放窗口。这个限制虽然简单，却避免了很多灵异问题。
根据我个人的实际经验，这类工具的维护重点永远不在代码本身，而在于对目标应用版本变化的响应能力。如果你打算长期使用，一定要把定位条件配置化和错误隔离做好，否则每次微信发版都是一次灾难。最后再分享一个小技巧：调试阶段在FlaUInspect里打开“监听模式”，一边手动操作微信一边观察控件属性变化，会比反复改代码重新运行高效得多。
本文还有配套的精品资源，点击获取
