简介这是一套面向Windows 10平台Python开发者与办公自动化需求者的微信电脑版智能操作工具聚焦解决高频重复性沟通与管理任务如消息自动收发、群成员监控、朋友圈定时互动、文件批量传输、聊天记录结构化导出及用户行为脚本化模拟。资源包共4个文件36KB含核心功能脚本chat.py、详细配置与使用说明的docx文档、简明操作指引txt及项目README.md覆盖从环境部署、WebDriver驱动适配到定时任务编排的完整实践链路。已有68人学习下载适合具备基础Python语法和Selenium操作经验的中级开发者快速上手直接复用或二次开发定制化微信自动化流程。 做微信电脑版自动化这件事我一开始是按“WebDriver”的思路理解的以为能像 Selenium 驱动浏览器那样用一套协议把微信给“驾驭”住。真上手之后才发现微信电脑版是原生 Windows 桌面程序不是跑在浏览器里的网页WebDriver 协议根本够不着这条路从根上就是错的。后来我把方案掰正改用 Win32 UI 自动化加键盘鼠标模拟的组合在 Windows 10 上用 Python 3.8.2 把消息自动收发、群管理、朋友圈互动、文件传输、聊天记录导出、定时任务这六个模块逐一跑通。这篇文章是完整的项目复盘从技术选型、环境准备、功能实现到定时任务编排最后是实测踩坑记录。如果你也在 Windows 10 上对桌面应用做自动化尤其是微信这种带登录态和风控机制的软件这份记录能帮你少走不少弯路。1. 桌面自动化方案的选型WebDriver思路为什么走不通1.1 浏览器自动化和桌面自动化是两个世界Selenium 这一类 WebDriver 工具之所以能控制浏览器是因为浏览器本身提供了调试协议。Chrome 有 DevTools ProtocolFirefox 有 MarionetteWebDriver 通过这套协议往页面里注入脚本再通过脚本操作 DOM 元素点按钮、填表单、读文本都建立在“页面有结构”这个前提上。微信电脑版没有 DOM。它是一个原生 Win32 窗口虽然内部有一部分基于 Chromium 渲染但外壳、菜单、会话列表、输入框这些核心交互并不以网页形式暴露出来。你没法用find_element(By.XPATH, //button[contains(text(),发送)])去定位那个发送按钮因为桌面程序根本不响应 XPath 查询。我并不是说 WebDriver 完全不能用而是它面向的是浏览器和 WebView微信电脑版的自动化需要另一套东西。标题里出现 WebDriver说明很多人第一反应都是“像操作网页一样操作微信”这个想法可以理解但实际项目的技术栈必须换。1.2 三条可走的路线要做 Windows 桌面程序自动化业内比较成熟的路子有三条方案原理优点缺点UI 自动化框架通过 Windows UI Automation API 获取窗口控件树定位按钮、输入框、列表等控件有名称和类型定位相对稳定可读性好自绘控件、Canvas 区域拿不到子元素需要辅助方案坐标图像识别截图后用模板匹配找到目标图标坐标再用鼠标点击任何界面都能操作不用管控件结构分辨率、缩放、窗口位置一变就失效且速度慢混合方案控件树定位稳定区域图像识别处理自绘区域剪贴板辅助输入兼顾稳定性与覆盖范围适合微信这种混合界面开发量最大需要适配不同失效场景微信电脑版刚好是“半原生半自绘”的典型。会话列表、搜索框、输入框这些走的是原生控件UIA 能认出来但朋友圈的信息流、聊天记录里的气泡内容、头像区域基本是自绘的UIA 树里经常只有一个光秃秃的 Pane没有子节点。所以纯 UI 自动化拿不下朋友圈纯图像识别又会因为窗口移动而崩掉。最终我选了混合方案。1.3 技术栈最终确定Python 3.8.2项目指定版本实测对下面几个库的兼容性都很好尤其是 uiautomation 在 3.8 系列下没有奇怪的兼容问题。uiautomation基于 Windows UI Automation API 的封装比 pywinauto 对现代控件的覆盖更全。pyautogui负责鼠标移动、点击、拖拽、滚轮以及一些坐标级别的操作。pyperclip读写剪贴板解决中文文本输入乱码的问题。opencv-python numpy截图和模板匹配主要用于朋友圈互动。apscheduler定时任务调度负责让脚本按节奏自动跑。logging日志记录排除问题时没有日志寸步难行。这套组合的逻辑很清晰uiautomation 负责“能找到的”pyautogui 负责“找不到但看得见的”pyperclip 负责把文字安全地送进输入框apscheduler 负责让整个流程自动化。用下来最大的感受是不要把某一种方案当万能药桌面自动化从来都是组合拳。2. 环境与底层准备给微信电脑版搭好自动化基座2.1 Python 3.8.2 和依赖安装标题里写的是 Python382也就是 Python 3.8.2。这个版本在 2020 年前后非常流行现在虽然已经有更高版本但对 uiautomation 和 pyautogui 这些库来说3.8 反而是一个久经考验的稳定区间。我的建议是项目里既然定了 3.8.2就老老实实装上别中途升级减少变量。依赖安装很简单创建一个requirements.txtuiautomation2.0.19 pyautogui0.9.53 pyperclip1.8.2 opencv-python4.8.1.78 numpy1.24.4 apscheduler3.10.4然后执行pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple这里有两个容易踩的坑。第一个是uiautomation库名容易和robotframework-uiautomation混淆前者是我们要的后者是 Robot Framework 的库装错了跑起来完全不是一回事。第二个是 opencv 在 Python 3.8.2 下安装时numpy 版本不要追太高1.24.4 和它配合得很好装 numpy 2.x 有概率出现二进制不兼容。2.2 微信电脑版版本选择能不变就不变自动化最怕环境变化。微信每次升级都会改界面文案、控件 Name、类名甚至窗口结构一些看似无关紧要的小版本更新可能让脚本里写死的定位条件全部失效。我在项目里固定了一个常用稳定版微信并且做了两件事在微信设置里取消“自动更新”勾选安装完成后把安装目录的写权限收紧或者用绿色版方式解压运行从物理上杜绝自动更新。为什么这么谨慎因为我踩过一次坑某天微信自动更新后原来的搜索框控件 Name 从“搜索”变成了“搜索(CtrlF)”脚本里所有Name搜索的定位全部失效。从那以后我学乖了凡是做桌面自动化第一原则就是锁定版本。2.3 控件树先看看微信窗口长什么样在写自动化逻辑之前第一步永远是“dump 控件树”。用 uiautomation 自带的方法把微信主窗口的所有控件打印出来看看每个区域在 UIA 眼里到底是什么。import uiautomation as auto window auto.WindowControl(searchDepth1, ClassNameWeChatMainWndForPC) window.SetActive() def walk_controls(control, depth0): for child in control.GetChildren(): print( * depth, child.ControlTypeName, |, child.Name, |, child.ClassName) if depth 5: walk_controls(child, depth 1) walk_controls(window)跑完之后你会看到微信主窗口的典型结构大致是左侧会话列表区一般是一个 ListControl内部挂着一堆 ListItemControl每个 ListItem 的 Name 是联系人昵称或群名。右上角搜索框通常是 EditControlName 叫“搜索”。中间消息区是个复杂的容器部分版本能看到消息气泡的 TextControl部分版本只有空 Pane。底部输入框EditControlName 可能是“消息”或为空。发送按钮ButtonControlName 通常叫“发送”。不同版本的微信控件细节差异很大所以脚本里千万不要写死Name搜索这种完全匹配而是要用NameContains(搜索)之类的模糊匹配给版本差异留点余地。2.4 初始化封装写一个 WxAutomation 类把获取窗口、激活窗口、等待控件这些基础操作封装成一个类后续功能模块都基于它来扩展。import time import uiautomation as auto class WxAutomation: def __init__(self, class_nameWeChatMainWndForPC): self.window None self.class_name class_name self.connect() def connect(self): for _ in range(30): self.window auto.WindowControl(searchDepth1, ClassNameself.class_name) if self.window.Exists(3, 1): break time.sleep(1) if not self.window.Exists(3, 1): raise RuntimeError(未找到微信主窗口请确认微信已登录) self.window.SetActive() def wait_control(self, control, timeout10): start time.time() while time.time() - start timeout: if control.Exists(1, 1): return control time.sleep(0.5) raise TimeoutError(控件等待超时)封装之后后面每个功能模块都从这个类继承或者组合调用代码复用率高也方便统一处理异常。3. 六个核心功能逐一拆解从消息收发到聊天记录导出这一章是整个项目的重头戏。我把标题里的六个功能模块按实现方式分了类能靠控件定位的直接用 UIA控件拿不到的转图像识别文本写入统一走剪贴板。3.1 消息自动发送四步法消息发送是最基础的功能核心逻辑是四步搜索联系人、点击会话、定位输入框、写入并发送。import pyperclip import time class WxMessage(WxAutomation): def search_contact(self, name): search_box self.window.EditControl(searchDepth5, NameContains搜索) self.wait_control(search_box) search_box.Click() pyperclip.copy(name) search_box.SendKeys({Ctrl}v) time.sleep(1.5) result self.window.ListItemControl(searchDepth5, Namename) self.wait_control(result) result.Click() time.sleep(1) def send_message(self, text): edit_box self.window.EditControl(searchDepth10) # 通常在消息区底部Name 为空需要自行确认控件树 self.wait_control(edit_box) edit_box.Click() pyperclip.copy(text) edit_box.SendKeys({Ctrl}v) time.sleep(0.5) edit_box.SendKeys({Enter})这里最关键的是中文输入问题。uiautomation 的 SendKeys 对英文字符没问题但遇到中文输入法时经常出现乱码、丢字甚至把微信搞卡。稳妥做法是用pyperclip.copy(text)把文本放进剪贴板再发送CtrlV粘贴相当于模拟人按快捷键粘贴的动作绕开了输入法这一层。发送键也有讲究。微信默认Enter直接发送ShiftEnter换行。如果你的账号在设置里改成了CtrlEnter发送脚本里就得对应调整。我建议在脚本里做一个配置项把发送快捷键抽出来避免换一台电脑就失效。3.2 消息接收与关键词自动回复接收消息的思路比发送绕一点因为微信没有“新消息事件”这种 API 可以监听只能轮询。我用的方法是“锚点对比法”定位当前会话最后一条消息的文本区域读取文本作为锚点每隔几秒重新读取一次和锚点对比如果文本变化说明有新消息进来提取新内容按关键词规则匹配决定是否回复。import time class WxAutoReply(WxMessage): def get_last_message(self): # 消息区域最后一个文本控件不同版本需要调整 msgs self.window.GetChildren() for ctrl in reversed(msgs): if ctrl.ControlTypeName TextControl and ctrl.Name: return ctrl.Name return def monitor(self, keywords_map, interval3): last self.get_last_message() while True: time.sleep(interval) current self.get_last_message() if current ! last: new_msg current[len(last):] if current.startswith(last) else current for keyword, reply in keywords_map.items(): if keyword in new_msg: self.send_message(reply) break last current这里有个坑消息区域的文本控件在 UIA 树里不一定按顺序排列滚动长对话时get_last_message()拿到的可能不是视觉上的最后一条。我建议先用 3.1 的search_contact进入具体会话再读取消息区域最后一个 TextControl这样准确率高很多。另外提醒一句自动回复功能不要做成“对所有人所有消息都回”我很克制的做法是只对特定白名单群或个人启用并且每条自动回复之间至少间隔 5 秒。无差别自动回复容易惹出麻烦也容易被平台的风控系统盯上。3.3 群管理成员遍历、提醒与群公告群管理的几个操作里最容易做的是遍历成员列表最需要谨慎的是踢人、禁言这类权限操作。遍历群成员点击群聊右上角“…”打开聊天信息面板然后用 UIA 遍历面板里的 ListItemControl。def get_group_members(self): # 点击聊天信息面板入口 detail_btn self.window.ButtonControl(searchDepth8, NameContains聊天信息) self.wait_control(detail_btn) detail_btn.Click() time.sleep(1) members [] for item in self.window.ListControl(searchDepth8).GetChildren(): if item.ControlTypeName ListItemControl: members.append(item.Name) return members成员的操作相对复杂。微信的 触发流程是在输入框输入会弹出一个成员选择器然后输入成员昵称微信会自动过滤并高亮匹配项最后点选。代码里需要先定位输入框SendKeys 一个等待选择器出现再输入昵称并点击匹配项。群公告的发布逻辑类似先找到群公告入口点击“发布”在编辑框里写入文本再点击发布按钮。这些操作每一步之间的等待时间不能省尤其是选择器弹窗网络稍微一慢就要 1 到 2 秒。权限边界问题在群管理里特别明显。踢人、改群名这类操作只有管理员能做普通成员根本没有对应按钮。脚本里一定要先判断控件是否存在再决定是否执行不能上来就点击否则会抛出控件查找异常。3.4 朋友圈互动控件不够图像识别来凑朋友圈是最典型的自绘界面。微信在 Windows 上的朋友圈窗口信息流整体是一个大的滚动区域UIA 拿不到“点赞”“评论”这些独立控件只能拿到一个巨大 Pane。这时候只能换一套思路截图 模板匹配。我的实现步骤是打开朋友圈窗口确保窗口在最前面。用 pyautogui 截取整个窗口区域。用 opencv 的matchTemplate在截图里找“点赞”图标的模板。如果匹配到就计算图标在屏幕上的绝对坐标用 pyautogui 点击。点击之后再截图检查点赞图标是否从灰色变成高亮确认操作成功。核心代码思路import cv2 import numpy as np import pyautogui def find_icon(screen, template, threshold0.8): result cv2.matchTemplate(screen, template, cv2.TM_CCOEFF_NORMED) _, max_val, _, max_loc cv2.minMaxLoc(result) if max_val threshold: return max_loc return None实际工程里需要处理的细节不少点赞图标模板要准备多个尺寸以适配不同缩放朋友圈滚动后首次加载的图片可能没渲染完截图前必须等 1 到 2 秒评论输入框弹出后要先用 UIA 定位编辑框再用剪贴板粘贴文本。关于朋友圈互动我想多说一句这个模块做出来容易但请务必控制频率。连续给同一时段的多条朋友圈点赞或者短时间内大量评论这在平台眼里是极其典型的机器人行为。我的做法是每次运行最多处理 5 条并且每条之间随机间隔 10 到 30 秒。3.5 文件传输路径输入与另存为的自动化文件传输分发送和接收两个方向。发送文件的自动化流程是进入目标会话点击输入框旁边的“文件”图标这时会弹出系统的文件选择对话框。这个对话框虽然是 Windows 原生控件UIA 能定位到编辑框但文件选择框在“打开”状态下输入路径有更省事的办法直接按CtrlL把焦点切到路径输入框然后输入完整路径并回车。def send_file(self, filepath): # 点击文件图标 file_btn self.window.ButtonControl(searchDepth8, NameContains文件) self.wait_control(file_btn) file_btn.Click() time.sleep(1.5) # 系统文件对话框 dialog auto.WindowControl(searchDepth1, ClassName#32770) self.wait_control(dialog) dialog.SetActive() dialog.SendKeys({Ctrl}l) time.sleep(0.5) pyperclip.copy(filepath) dialog.SendKeys({Ctrl}v) time.sleep(0.3) dialog.SendKeys({Enter}) time.sleep(0.3) dialog.SendKeys({Enter}) # 确认打开头两次实测时我只发了一个回车结果对话框停在文件列表里没有确认后来才发现文件选择对话框需要两个回车第一个回车选中文件第二个回车确认关闭对话框。接收文件更简单。微信接收文件的“下载”按钮是原生的UIA 能定位到。点击下载后文件会保存到微信设置里的默认目录。我的做法是提前在微信设置里把文件保存路径改到一个固定目录下载完成后用脚本轮询该目录发现新文件就进行后续处理。3.6 聊天记录导出复制粘贴法的边界聊天记录导出有很多条路我选择了一条最笨但最稳妥的模拟人 CtrlA 全选、CtrlC 复制、粘贴保存。思路是这样进入目标会话点击消息区域。发送CtrlA全选当前可视范围内的消息。发送CtrlC复制到剪贴板。读取剪贴板内容追加写入本地 txt 或 markdown 文件。滚动消息区域加载更多历史消息重复上述步骤。def export_chat(self, output_file, max_scroll50): data [] for _ in range(max_scroll): msg_area self.window.PaneControl(searchDepth8, NameContains消息) msg_area.Click() msg_area.SendKeys({Ctrl}a) time.sleep(0.5) msg_area.SendKeys({Ctrl}c) time.sleep(0.5) content pyperclip.paste() if content and content not in data[-1:] : data.append(content) # 向上滚动加载更多 pyautogui.scroll(5) time.sleep(2) with open(output_file, w, encodingutf-8) as f: f.write(\n\n.join(data))这个方案有两个明显的局限。第一图片、语音、视频无法通过复制导出最多只能复制到一些文件名引用第二滚动太快会导致微信来不及加载历史消息复制到的是重复区域所以每次滚动后必须等 2 秒左右。有人可能会提到直接读微信本地 SQLite 数据库导出完整记录包括图片和语音。这个方向技术上确实能实现但涉及数据库解密、密钥提取已经进入逆向工程范畴风险和法律边界都说不清楚我没有采用。如果你只是备份自己的聊天记录文本加截图已经足够别碰那个灰色地带。4. 行为模拟的尺度与风控规避别把账号折腾没了4.1 微信到底在检测什么微信的风控系统不会公开展示自己的规则但从大量实际封号案例和正常使用习惯的反推来看它重点关注的自动化特征主要有四个维度操作频率正常人不会在 1 秒内连续发 5 条消息也不会 3 分钟内把朋友圈从第一屏点到第十屏。间隔一致性每次操作间隔固定 2 秒这种节奏像极了程序里的time.sleep(2)真人操作不可能这么规律。批量行为同一时间段给几十个不同联系人发送内容相同或高度相似的文本这是典型的群发特征。环境异常登录设备、IP 地址、系统环境发生剧烈变化时触发安全验证的概率显著上升。严格的人为随机化是绕不开的。4.2 模拟人类操作的动力学我用了一个简单的随机延迟函数让每次操作之间的间隔不固定import random import time def random_delay(min_sec1.2, max_sec3.5): time.sleep(random.uniform(min_sec, max_sec))这个函数看起来简单但它是整个自动化脚本安全性的基石。所有关键操作之间都要调用它不能省略也不能把间隔设得太短。我实测下来1.2 到 3.5 秒是一个“既不像机器、又不至于慢到影响效率”的区间。鼠标移动也需要模拟。pyautogui 的moveTo默认是瞬间移动真人不可能这样操作。我写了一个分段移动函数让鼠标逐步滑向目标坐标中间加入随机偏移def human_move(target_x, target_y): start_x, start_y pyautogui.position() steps random.randint(8, 14) for i in range(1, steps 1): mid_x start_x (target_x - start_x) * i / steps random.uniform(-2, 2) mid_y start_y (target_y - start_y) * i / steps random.uniform(-2, 2) pyautogui.moveTo(mid_x, mid_y, duration0.02)最关键的一点是操作节流。我绝不会让脚本 7x24 小时不间断运行而是把自动化任务都安排在白天的工作时段晚上和凌晨完全不碰。理由很简单真人不会在凌晨三点批量处理工作消息。4.3 登录态维护二维码过期与掉线检测长时间挂机之后微信可能掉线或者要求重新扫码登录。脚本必须具备检测能力否则后面所有定时任务都会在“没登录”的状态下空转。我采用的检测方法是定时检查主窗口是否存在。主窗口类名WeChatMainWndForPC不存在时说明微信已经退出或者崩了如果出现二维码登录窗口UIA 能检测到标题包含“登录”的窗口此时发一条带告警的日志必要的话通过钉钉机器人或者邮件通知我人工介入。def check_login_state(self): if not self.window.Exists(1, 1): # 尝试重新拉起微信 os.startfile(rC:\Program Files (x86)\Tencent\WeChat\WeChat.exe) time.sleep(15) self.connect() return False return True注意不要尝试任何绕过扫码登录的方案比如注入内存、劫持进程之类这是彻头彻尾的高风险操作出了问题账号没了是小事涉及的合规风险才是大问题。老实走人工扫码这条路最安全。4.4 红线操作这些自动化千万别做总结一下我给自己划的几条红线批量自动加好友。这个行为在平台的风控体系里几乎是“见一个封一个”而且就算侥幸成功加来的好友大概率也是营销号没有任何价值。未经同意的群发广告。这是最招人恨的操作也是微信重点打击的对象。自动拉人进群。和加好友一样风险极高。高频点赞评论骚扰他人。朋友圈互动的本质是社交不是刷存在感机器人的高频点赞只会让别人反感。利用非官方协议接口做客户端。这和“自动化操作 UI”是两个性质已经涉及逆向和协议破解我明确不碰。自动化工具最安全的定位是“帮自己处理自己的数据”比如定时给文件传输助手发提醒、备份自己的聊天记录、管理自己运营的群。一旦越界去骚扰别人等于把工具变成了凶器后果自己承担。5. 定时任务与系统集成让脚本按节奏自己跑5.1 APSchedulerPython 里的定时调度器定时任务这块我用的 APScheduler它比 Windows 任务计划程序更灵活可以直接在 Python 进程里管理多个任务。核心是两种触发器CronTrigger按日历时间触发比如每天早上 9 点、每周五 18 点。IntervalTrigger按固定间隔触发比如每 30 分钟检查一次登录态。一个典型的组合from apscheduler.schedulers.background import BackgroundScheduler from apscheduler.triggers.cron import CronTrigger from apscheduler.triggers.interval import IntervalTrigger import time def morning_notify(): wx.send_message(文件传输助手, 早上好今日工作清单已生成) def check_online(): wx.check_login_state() def export_weekly(): wx.search_contact(某群) wx.export_chat(weekly_backup.md) scheduler BackgroundScheduler(timezoneAsia/Shanghai) scheduler.add_job(morning_notify, CronTrigger(hour9, minute0)) scheduler.add_job(check_online, IntervalTrigger(minutes30)) scheduler.add_job(export_weekly, CronTrigger(day_of_weekfri, hour18, minute0)) scheduler.start() while True: time.sleep(60)时区一定要显式设置不然部署在不同区域的机器上触发时间会和预期差几个小时。我第一版没加 timezone本地测试一切正常换到云服务器上才发现早上九点的任务在凌晨一点就跑了。5.2 定时任务和微信自动化怎么配合定时任务触发时微信可能不在线也可能卡在一个异常状态。所以每个任务函数的第一件事就是检查登录状态第二件事是确保微信窗口在前台。def safe_task(task_func): def wrapper(*args, **kwargs): if not wx.check_login_state(): log.error(微信未登录任务取消: %s, task_func.__name__) return wx.window.SetActive() try: task_func(*args, **kwargs) except Exception as e: log.exception(任务执行失败: %s, task_func.__name__) return wrapper用这个装饰器包住所有定时任务日志里能看到每次任务的执行结果。就算某次任务崩了也不会影响后续调度。5.3 Windows 任务计划程序兜底Python 脚本本身有可能崩溃或者被杀掉APScheduler 调度得再好也白搭。这时候就需要 Windows 任务计划程序做一层兜底。我在项目里创建了一个名为WechatAutomation的任务计划设置开机自启并且勾选“如果任务失败每隔 5 分钟重新启动”。启动脚本用 bat 包装echo off cd /d C:\wechat_auto C:\Python382\python.exe main.py run.log 21配合 logging 同时输出控制台和文件出问题的时候打开run.log一眼就能定位到是哪个任务、哪一步挂了。日志时间戳要带毫秒因为微信同一个操作触发两次的间隔往往只有几秒不带毫秒很难判断执行顺序。6. 实测踩坑录升级、输入法、控件漂移这些坑6.1 微信一升级控件名全变了这是所有桌面自动化项目的头号杀手。某次微信自动更新后搜索框的 Name 从“搜索”变成了“搜索(CtrlF)”控件类名虽然没有变但 Name 的变化直接让Name搜索的定位全部失效。解决办法有两个而且必须同时做。第一是锁版本从根源上杜绝升级第二是写代码时用模糊匹配NameContains(搜索)而不是Name搜索。两个措施叠加之后即使微信偶尔静默升级脚本的容错率也高一些。6.2 中文输入乱码和丢字这个坑我前面提过但值得单独展开。uiautomation 的SendKeys本质上是把按键事件发送给窗口英文字符每一个都有对应的虚拟键码没问题但中文是输入法层面的组合输入SendKeys 发送的按键序列经过输入法转换后经常出现错乱。我第一次实现发消息时中文消息有时变成拼音有时变成乱码有时直接没进去。改成剪贴板大法之后问题彻底消失。细节上还有一个坑剪贴板操作偶尔会失败比如被其他程序占用所以pyperclip.copy之后应该做一次校验。def set_clipboard(text, retry3): for _ in range(retry): pyperclip.copy(text) if pyperclip.paste() text: return True time.sleep(0.5) raise RuntimeError(剪贴板写入失败)这个校验函数我加了之后再也没出现过“以为是发送成功实际消息为空”的问题。6.3 控件查找超时等待与重试微信启动慢、网络卡顿、窗口切换动画未结束都可能导致控件暂时不存在。我最初写脚本时直接window.ButtonControl(Name发送)如果控件还没加载完就点击直接抛异常。后来所有控件定位都封装了一层重试等待def wait_for(func, timeout10, interval0.5): start time.time() while time.time() - start timeout: try: result func() if result.Exists(1, 1): return result except Exception: pass time.sleep(interval) raise TimeoutError(等待控件超时)实践中等待时间根据控件类型区分窗口类控件给 10 秒按钮给 5 秒列表项给 3 秒。不需要每次都等满没等到才会走完整个超时流程。6.4 虚拟列表滚动加载的坑微信的会话列表和聊天记录是虚拟列表只渲染屏幕内可见的部分。如果直接遍历 ListControl 的所有子节点拿到的只是当前可视区域的那几个滚动之后才会加载新的。这个特性对聊天记录导出影响最大。我在导出逻辑里每个滚动周期都重新获取消息区域控件并重新点击就是为了确保焦点在消息区域CtrlA 选中的是当前看到的全部内容而不是微信窗口的其他部分。朋友圈滚动也有类似问题滚动太快图片区域会显示“加载失败”或者灰色占位图截图模板匹配自然就找不到点赞图标。我的做法是每次滚轮滚动之后强制等待 2 秒给图片渲染留足时间。6.5 DPI 缩放与坐标偏移Windows 10 在 125% 或 150% 缩放下pyautogui 的屏幕坐标和部分 UIA 控件返回的坐标会不一致导致点击位置偏移。这个问题一度让我非常头大明明控件定位到了点击却点到了旁边。最简单的解决办法是把系统缩放设为 100%。如果你需要高清显示可以在 python.exe 的兼容性设置里勾选“替代高 DPI 缩放行为”让进程自己感知 DPI。但要注意这个设置只对当前 python.exe 有效打包成 exe 后需要重新设置。更通用的做法是用 UIA 控件的BoundingRectangle属性拿到精确的屏幕矩形pyautogui 点击时用矩形中心点不要自己硬编码坐标偏移量。6.6 长时间挂机卡死与内存增长微信长时间自动化运行后内存占用会缓慢增长消息区域越来越卡脚本响应速度越来越慢。我最初以为是脚本内存泄漏排查半天发现是微信自身的问题——长时间不重启它的渲染缓存会越积越多。解决办法很粗暴但有效每 4 到 6 个小时用任务计划程序定时执行一个维护任务把微信进程完全关闭再重新拉起。如果你开启了微信的“自动登录”重启后不需要重新扫码可以无缝衔接。但这里有一个节奏控制的问题重启频率不能太密。每 1 小时重启一次微信的风控系统会觉得这个登录状态太诡异反而增加风险。4 到 6 小时是比较合理的区间白天保持在线晚上还可以额外降低频率。整个项目做完我最大的体会是桌面自动化不是做不到而是别把它想象成 Web 自动化那样清明透彻。微信不是给你写脚本用的所以工具要软一点、聪明一点、克制一点。固定在同一个 Windows 环境、锁定微信版本、用 UIA 加图像识别的混合方案是目前最实用的组合而比技术更重要的是在边界内使用它。如果你也在折腾类似的东西希望这份记录能让你少踩几个我踩过的坑。本文还有配套的精品资源点击获取
简介这是一套面向Windows 10平台Python开发者与办公自动化需求者的微信电脑版智能操作工具聚焦解决高频重复性沟通与管理任务如消息自动收发、群成员监控、朋友圈定时互动、文件批量传输、聊天记录结构化导出及用户行为脚本化模拟。资源包共4个文件36KB含核心功能脚本chat.py、详细配置与使用说明的docx文档、简明操作指引txt及项目README.md覆盖从环境部署、WebDriver驱动适配到定时任务编排的完整实践链路。已有68人学习下载适合具备基础Python语法和Selenium操作经验的中级开发者快速上手直接复用或二次开发定制化微信自动化流程。 做微信电脑版自动化这件事我一开始是按“WebDriver”的思路理解的以为能像 Selenium 驱动浏览器那样用一套协议把微信给“驾驭”住。真上手之后才发现微信电脑版是原生 Windows 桌面程序不是跑在浏览器里的网页WebDriver 协议根本够不着这条路从根上就是错的。后来我把方案掰正改用 Win32 UI 自动化加键盘鼠标模拟的组合在 Windows 10 上用 Python 3.8.2 把消息自动收发、群管理、朋友圈互动、文件传输、聊天记录导出、定时任务这六个模块逐一跑通。这篇文章是完整的项目复盘从技术选型、环境准备、功能实现到定时任务编排最后是实测踩坑记录。如果你也在 Windows 10 上对桌面应用做自动化尤其是微信这种带登录态和风控机制的软件这份记录能帮你少走不少弯路。1. 桌面自动化方案的选型WebDriver思路为什么走不通1.1 浏览器自动化和桌面自动化是两个世界Selenium 这一类 WebDriver 工具之所以能控制浏览器是因为浏览器本身提供了调试协议。Chrome 有 DevTools ProtocolFirefox 有 MarionetteWebDriver 通过这套协议往页面里注入脚本再通过脚本操作 DOM 元素点按钮、填表单、读文本都建立在“页面有结构”这个前提上。微信电脑版没有 DOM。它是一个原生 Win32 窗口虽然内部有一部分基于 Chromium 渲染但外壳、菜单、会话列表、输入框这些核心交互并不以网页形式暴露出来。你没法用find_element(By.XPATH, //button[contains(text(),发送)])去定位那个发送按钮因为桌面程序根本不响应 XPath 查询。我并不是说 WebDriver 完全不能用而是它面向的是浏览器和 WebView微信电脑版的自动化需要另一套东西。标题里出现 WebDriver说明很多人第一反应都是“像操作网页一样操作微信”这个想法可以理解但实际项目的技术栈必须换。1.2 三条可走的路线要做 Windows 桌面程序自动化业内比较成熟的路子有三条方案原理优点缺点UI 自动化框架通过 Windows UI Automation API 获取窗口控件树定位按钮、输入框、列表等控件有名称和类型定位相对稳定可读性好自绘控件、Canvas 区域拿不到子元素需要辅助方案坐标图像识别截图后用模板匹配找到目标图标坐标再用鼠标点击任何界面都能操作不用管控件结构分辨率、缩放、窗口位置一变就失效且速度慢混合方案控件树定位稳定区域图像识别处理自绘区域剪贴板辅助输入兼顾稳定性与覆盖范围适合微信这种混合界面开发量最大需要适配不同失效场景微信电脑版刚好是“半原生半自绘”的典型。会话列表、搜索框、输入框这些走的是原生控件UIA 能认出来但朋友圈的信息流、聊天记录里的气泡内容、头像区域基本是自绘的UIA 树里经常只有一个光秃秃的 Pane没有子节点。所以纯 UI 自动化拿不下朋友圈纯图像识别又会因为窗口移动而崩掉。最终我选了混合方案。1.3 技术栈最终确定Python 3.8.2项目指定版本实测对下面几个库的兼容性都很好尤其是 uiautomation 在 3.8 系列下没有奇怪的兼容问题。uiautomation基于 Windows UI Automation API 的封装比 pywinauto 对现代控件的覆盖更全。pyautogui负责鼠标移动、点击、拖拽、滚轮以及一些坐标级别的操作。pyperclip读写剪贴板解决中文文本输入乱码的问题。opencv-python numpy截图和模板匹配主要用于朋友圈互动。apscheduler定时任务调度负责让脚本按节奏自动跑。logging日志记录排除问题时没有日志寸步难行。这套组合的逻辑很清晰uiautomation 负责“能找到的”pyautogui 负责“找不到但看得见的”pyperclip 负责把文字安全地送进输入框apscheduler 负责让整个流程自动化。用下来最大的感受是不要把某一种方案当万能药桌面自动化从来都是组合拳。2. 环境与底层准备给微信电脑版搭好自动化基座2.1 Python 3.8.2 和依赖安装标题里写的是 Python382也就是 Python 3.8.2。这个版本在 2020 年前后非常流行现在虽然已经有更高版本但对 uiautomation 和 pyautogui 这些库来说3.8 反而是一个久经考验的稳定区间。我的建议是项目里既然定了 3.8.2就老老实实装上别中途升级减少变量。依赖安装很简单创建一个requirements.txtuiautomation2.0.19 pyautogui0.9.53 pyperclip1.8.2 opencv-python4.8.1.78 numpy1.24.4 apscheduler3.10.4然后执行pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple这里有两个容易踩的坑。第一个是uiautomation库名容易和robotframework-uiautomation混淆前者是我们要的后者是 Robot Framework 的库装错了跑起来完全不是一回事。第二个是 opencv 在 Python 3.8.2 下安装时numpy 版本不要追太高1.24.4 和它配合得很好装 numpy 2.x 有概率出现二进制不兼容。2.2 微信电脑版版本选择能不变就不变自动化最怕环境变化。微信每次升级都会改界面文案、控件 Name、类名甚至窗口结构一些看似无关紧要的小版本更新可能让脚本里写死的定位条件全部失效。我在项目里固定了一个常用稳定版微信并且做了两件事在微信设置里取消“自动更新”勾选安装完成后把安装目录的写权限收紧或者用绿色版方式解压运行从物理上杜绝自动更新。为什么这么谨慎因为我踩过一次坑某天微信自动更新后原来的搜索框控件 Name 从“搜索”变成了“搜索(CtrlF)”脚本里所有Name搜索的定位全部失效。从那以后我学乖了凡是做桌面自动化第一原则就是锁定版本。2.3 控件树先看看微信窗口长什么样在写自动化逻辑之前第一步永远是“dump 控件树”。用 uiautomation 自带的方法把微信主窗口的所有控件打印出来看看每个区域在 UIA 眼里到底是什么。import uiautomation as auto window auto.WindowControl(searchDepth1, ClassNameWeChatMainWndForPC) window.SetActive() def walk_controls(control, depth0): for child in control.GetChildren(): print( * depth, child.ControlTypeName, |, child.Name, |, child.ClassName) if depth 5: walk_controls(child, depth 1) walk_controls(window)跑完之后你会看到微信主窗口的典型结构大致是左侧会话列表区一般是一个 ListControl内部挂着一堆 ListItemControl每个 ListItem 的 Name 是联系人昵称或群名。右上角搜索框通常是 EditControlName 叫“搜索”。中间消息区是个复杂的容器部分版本能看到消息气泡的 TextControl部分版本只有空 Pane。底部输入框EditControlName 可能是“消息”或为空。发送按钮ButtonControlName 通常叫“发送”。不同版本的微信控件细节差异很大所以脚本里千万不要写死Name搜索这种完全匹配而是要用NameContains(搜索)之类的模糊匹配给版本差异留点余地。2.4 初始化封装写一个 WxAutomation 类把获取窗口、激活窗口、等待控件这些基础操作封装成一个类后续功能模块都基于它来扩展。import time import uiautomation as auto class WxAutomation: def __init__(self, class_nameWeChatMainWndForPC): self.window None self.class_name class_name self.connect() def connect(self): for _ in range(30): self.window auto.WindowControl(searchDepth1, ClassNameself.class_name) if self.window.Exists(3, 1): break time.sleep(1) if not self.window.Exists(3, 1): raise RuntimeError(未找到微信主窗口请确认微信已登录) self.window.SetActive() def wait_control(self, control, timeout10): start time.time() while time.time() - start timeout: if control.Exists(1, 1): return control time.sleep(0.5) raise TimeoutError(控件等待超时)封装之后后面每个功能模块都从这个类继承或者组合调用代码复用率高也方便统一处理异常。3. 六个核心功能逐一拆解从消息收发到聊天记录导出这一章是整个项目的重头戏。我把标题里的六个功能模块按实现方式分了类能靠控件定位的直接用 UIA控件拿不到的转图像识别文本写入统一走剪贴板。3.1 消息自动发送四步法消息发送是最基础的功能核心逻辑是四步搜索联系人、点击会话、定位输入框、写入并发送。import pyperclip import time class WxMessage(WxAutomation): def search_contact(self, name): search_box self.window.EditControl(searchDepth5, NameContains搜索) self.wait_control(search_box) search_box.Click() pyperclip.copy(name) search_box.SendKeys({Ctrl}v) time.sleep(1.5) result self.window.ListItemControl(searchDepth5, Namename) self.wait_control(result) result.Click() time.sleep(1) def send_message(self, text): edit_box self.window.EditControl(searchDepth10) # 通常在消息区底部Name 为空需要自行确认控件树 self.wait_control(edit_box) edit_box.Click() pyperclip.copy(text) edit_box.SendKeys({Ctrl}v) time.sleep(0.5) edit_box.SendKeys({Enter})这里最关键的是中文输入问题。uiautomation 的 SendKeys 对英文字符没问题但遇到中文输入法时经常出现乱码、丢字甚至把微信搞卡。稳妥做法是用pyperclip.copy(text)把文本放进剪贴板再发送CtrlV粘贴相当于模拟人按快捷键粘贴的动作绕开了输入法这一层。发送键也有讲究。微信默认Enter直接发送ShiftEnter换行。如果你的账号在设置里改成了CtrlEnter发送脚本里就得对应调整。我建议在脚本里做一个配置项把发送快捷键抽出来避免换一台电脑就失效。3.2 消息接收与关键词自动回复接收消息的思路比发送绕一点因为微信没有“新消息事件”这种 API 可以监听只能轮询。我用的方法是“锚点对比法”定位当前会话最后一条消息的文本区域读取文本作为锚点每隔几秒重新读取一次和锚点对比如果文本变化说明有新消息进来提取新内容按关键词规则匹配决定是否回复。import time class WxAutoReply(WxMessage): def get_last_message(self): # 消息区域最后一个文本控件不同版本需要调整 msgs self.window.GetChildren() for ctrl in reversed(msgs): if ctrl.ControlTypeName TextControl and ctrl.Name: return ctrl.Name return def monitor(self, keywords_map, interval3): last self.get_last_message() while True: time.sleep(interval) current self.get_last_message() if current ! last: new_msg current[len(last):] if current.startswith(last) else current for keyword, reply in keywords_map.items(): if keyword in new_msg: self.send_message(reply) break last current这里有个坑消息区域的文本控件在 UIA 树里不一定按顺序排列滚动长对话时get_last_message()拿到的可能不是视觉上的最后一条。我建议先用 3.1 的search_contact进入具体会话再读取消息区域最后一个 TextControl这样准确率高很多。另外提醒一句自动回复功能不要做成“对所有人所有消息都回”我很克制的做法是只对特定白名单群或个人启用并且每条自动回复之间至少间隔 5 秒。无差别自动回复容易惹出麻烦也容易被平台的风控系统盯上。3.3 群管理成员遍历、提醒与群公告群管理的几个操作里最容易做的是遍历成员列表最需要谨慎的是踢人、禁言这类权限操作。遍历群成员点击群聊右上角“…”打开聊天信息面板然后用 UIA 遍历面板里的 ListItemControl。def get_group_members(self): # 点击聊天信息面板入口 detail_btn self.window.ButtonControl(searchDepth8, NameContains聊天信息) self.wait_control(detail_btn) detail_btn.Click() time.sleep(1) members [] for item in self.window.ListControl(searchDepth8).GetChildren(): if item.ControlTypeName ListItemControl: members.append(item.Name) return members成员的操作相对复杂。微信的 触发流程是在输入框输入会弹出一个成员选择器然后输入成员昵称微信会自动过滤并高亮匹配项最后点选。代码里需要先定位输入框SendKeys 一个等待选择器出现再输入昵称并点击匹配项。群公告的发布逻辑类似先找到群公告入口点击“发布”在编辑框里写入文本再点击发布按钮。这些操作每一步之间的等待时间不能省尤其是选择器弹窗网络稍微一慢就要 1 到 2 秒。权限边界问题在群管理里特别明显。踢人、改群名这类操作只有管理员能做普通成员根本没有对应按钮。脚本里一定要先判断控件是否存在再决定是否执行不能上来就点击否则会抛出控件查找异常。3.4 朋友圈互动控件不够图像识别来凑朋友圈是最典型的自绘界面。微信在 Windows 上的朋友圈窗口信息流整体是一个大的滚动区域UIA 拿不到“点赞”“评论”这些独立控件只能拿到一个巨大 Pane。这时候只能换一套思路截图 模板匹配。我的实现步骤是打开朋友圈窗口确保窗口在最前面。用 pyautogui 截取整个窗口区域。用 opencv 的matchTemplate在截图里找“点赞”图标的模板。如果匹配到就计算图标在屏幕上的绝对坐标用 pyautogui 点击。点击之后再截图检查点赞图标是否从灰色变成高亮确认操作成功。核心代码思路import cv2 import numpy as np import pyautogui def find_icon(screen, template, threshold0.8): result cv2.matchTemplate(screen, template, cv2.TM_CCOEFF_NORMED) _, max_val, _, max_loc cv2.minMaxLoc(result) if max_val threshold: return max_loc return None实际工程里需要处理的细节不少点赞图标模板要准备多个尺寸以适配不同缩放朋友圈滚动后首次加载的图片可能没渲染完截图前必须等 1 到 2 秒评论输入框弹出后要先用 UIA 定位编辑框再用剪贴板粘贴文本。关于朋友圈互动我想多说一句这个模块做出来容易但请务必控制频率。连续给同一时段的多条朋友圈点赞或者短时间内大量评论这在平台眼里是极其典型的机器人行为。我的做法是每次运行最多处理 5 条并且每条之间随机间隔 10 到 30 秒。3.5 文件传输路径输入与另存为的自动化文件传输分发送和接收两个方向。发送文件的自动化流程是进入目标会话点击输入框旁边的“文件”图标这时会弹出系统的文件选择对话框。这个对话框虽然是 Windows 原生控件UIA 能定位到编辑框但文件选择框在“打开”状态下输入路径有更省事的办法直接按CtrlL把焦点切到路径输入框然后输入完整路径并回车。def send_file(self, filepath): # 点击文件图标 file_btn self.window.ButtonControl(searchDepth8, NameContains文件) self.wait_control(file_btn) file_btn.Click() time.sleep(1.5) # 系统文件对话框 dialog auto.WindowControl(searchDepth1, ClassName#32770) self.wait_control(dialog) dialog.SetActive() dialog.SendKeys({Ctrl}l) time.sleep(0.5) pyperclip.copy(filepath) dialog.SendKeys({Ctrl}v) time.sleep(0.3) dialog.SendKeys({Enter}) time.sleep(0.3) dialog.SendKeys({Enter}) # 确认打开头两次实测时我只发了一个回车结果对话框停在文件列表里没有确认后来才发现文件选择对话框需要两个回车第一个回车选中文件第二个回车确认关闭对话框。接收文件更简单。微信接收文件的“下载”按钮是原生的UIA 能定位到。点击下载后文件会保存到微信设置里的默认目录。我的做法是提前在微信设置里把文件保存路径改到一个固定目录下载完成后用脚本轮询该目录发现新文件就进行后续处理。3.6 聊天记录导出复制粘贴法的边界聊天记录导出有很多条路我选择了一条最笨但最稳妥的模拟人 CtrlA 全选、CtrlC 复制、粘贴保存。思路是这样进入目标会话点击消息区域。发送CtrlA全选当前可视范围内的消息。发送CtrlC复制到剪贴板。读取剪贴板内容追加写入本地 txt 或 markdown 文件。滚动消息区域加载更多历史消息重复上述步骤。def export_chat(self, output_file, max_scroll50): data [] for _ in range(max_scroll): msg_area self.window.PaneControl(searchDepth8, NameContains消息) msg_area.Click() msg_area.SendKeys({Ctrl}a) time.sleep(0.5) msg_area.SendKeys({Ctrl}c) time.sleep(0.5) content pyperclip.paste() if content and content not in data[-1:] : data.append(content) # 向上滚动加载更多 pyautogui.scroll(5) time.sleep(2) with open(output_file, w, encodingutf-8) as f: f.write(\n\n.join(data))这个方案有两个明显的局限。第一图片、语音、视频无法通过复制导出最多只能复制到一些文件名引用第二滚动太快会导致微信来不及加载历史消息复制到的是重复区域所以每次滚动后必须等 2 秒左右。有人可能会提到直接读微信本地 SQLite 数据库导出完整记录包括图片和语音。这个方向技术上确实能实现但涉及数据库解密、密钥提取已经进入逆向工程范畴风险和法律边界都说不清楚我没有采用。如果你只是备份自己的聊天记录文本加截图已经足够别碰那个灰色地带。4. 行为模拟的尺度与风控规避别把账号折腾没了4.1 微信到底在检测什么微信的风控系统不会公开展示自己的规则但从大量实际封号案例和正常使用习惯的反推来看它重点关注的自动化特征主要有四个维度操作频率正常人不会在 1 秒内连续发 5 条消息也不会 3 分钟内把朋友圈从第一屏点到第十屏。间隔一致性每次操作间隔固定 2 秒这种节奏像极了程序里的time.sleep(2)真人操作不可能这么规律。批量行为同一时间段给几十个不同联系人发送内容相同或高度相似的文本这是典型的群发特征。环境异常登录设备、IP 地址、系统环境发生剧烈变化时触发安全验证的概率显著上升。严格的人为随机化是绕不开的。4.2 模拟人类操作的动力学我用了一个简单的随机延迟函数让每次操作之间的间隔不固定import random import time def random_delay(min_sec1.2, max_sec3.5): time.sleep(random.uniform(min_sec, max_sec))这个函数看起来简单但它是整个自动化脚本安全性的基石。所有关键操作之间都要调用它不能省略也不能把间隔设得太短。我实测下来1.2 到 3.5 秒是一个“既不像机器、又不至于慢到影响效率”的区间。鼠标移动也需要模拟。pyautogui 的moveTo默认是瞬间移动真人不可能这样操作。我写了一个分段移动函数让鼠标逐步滑向目标坐标中间加入随机偏移def human_move(target_x, target_y): start_x, start_y pyautogui.position() steps random.randint(8, 14) for i in range(1, steps 1): mid_x start_x (target_x - start_x) * i / steps random.uniform(-2, 2) mid_y start_y (target_y - start_y) * i / steps random.uniform(-2, 2) pyautogui.moveTo(mid_x, mid_y, duration0.02)最关键的一点是操作节流。我绝不会让脚本 7x24 小时不间断运行而是把自动化任务都安排在白天的工作时段晚上和凌晨完全不碰。理由很简单真人不会在凌晨三点批量处理工作消息。4.3 登录态维护二维码过期与掉线检测长时间挂机之后微信可能掉线或者要求重新扫码登录。脚本必须具备检测能力否则后面所有定时任务都会在“没登录”的状态下空转。我采用的检测方法是定时检查主窗口是否存在。主窗口类名WeChatMainWndForPC不存在时说明微信已经退出或者崩了如果出现二维码登录窗口UIA 能检测到标题包含“登录”的窗口此时发一条带告警的日志必要的话通过钉钉机器人或者邮件通知我人工介入。def check_login_state(self): if not self.window.Exists(1, 1): # 尝试重新拉起微信 os.startfile(rC:\Program Files (x86)\Tencent\WeChat\WeChat.exe) time.sleep(15) self.connect() return False return True注意不要尝试任何绕过扫码登录的方案比如注入内存、劫持进程之类这是彻头彻尾的高风险操作出了问题账号没了是小事涉及的合规风险才是大问题。老实走人工扫码这条路最安全。4.4 红线操作这些自动化千万别做总结一下我给自己划的几条红线批量自动加好友。这个行为在平台的风控体系里几乎是“见一个封一个”而且就算侥幸成功加来的好友大概率也是营销号没有任何价值。未经同意的群发广告。这是最招人恨的操作也是微信重点打击的对象。自动拉人进群。和加好友一样风险极高。高频点赞评论骚扰他人。朋友圈互动的本质是社交不是刷存在感机器人的高频点赞只会让别人反感。利用非官方协议接口做客户端。这和“自动化操作 UI”是两个性质已经涉及逆向和协议破解我明确不碰。自动化工具最安全的定位是“帮自己处理自己的数据”比如定时给文件传输助手发提醒、备份自己的聊天记录、管理自己运营的群。一旦越界去骚扰别人等于把工具变成了凶器后果自己承担。5. 定时任务与系统集成让脚本按节奏自己跑5.1 APSchedulerPython 里的定时调度器定时任务这块我用的 APScheduler它比 Windows 任务计划程序更灵活可以直接在 Python 进程里管理多个任务。核心是两种触发器CronTrigger按日历时间触发比如每天早上 9 点、每周五 18 点。IntervalTrigger按固定间隔触发比如每 30 分钟检查一次登录态。一个典型的组合from apscheduler.schedulers.background import BackgroundScheduler from apscheduler.triggers.cron import CronTrigger from apscheduler.triggers.interval import IntervalTrigger import time def morning_notify(): wx.send_message(文件传输助手, 早上好今日工作清单已生成) def check_online(): wx.check_login_state() def export_weekly(): wx.search_contact(某群) wx.export_chat(weekly_backup.md) scheduler BackgroundScheduler(timezoneAsia/Shanghai) scheduler.add_job(morning_notify, CronTrigger(hour9, minute0)) scheduler.add_job(check_online, IntervalTrigger(minutes30)) scheduler.add_job(export_weekly, CronTrigger(day_of_weekfri, hour18, minute0)) scheduler.start() while True: time.sleep(60)时区一定要显式设置不然部署在不同区域的机器上触发时间会和预期差几个小时。我第一版没加 timezone本地测试一切正常换到云服务器上才发现早上九点的任务在凌晨一点就跑了。5.2 定时任务和微信自动化怎么配合定时任务触发时微信可能不在线也可能卡在一个异常状态。所以每个任务函数的第一件事就是检查登录状态第二件事是确保微信窗口在前台。def safe_task(task_func): def wrapper(*args, **kwargs): if not wx.check_login_state(): log.error(微信未登录任务取消: %s, task_func.__name__) return wx.window.SetActive() try: task_func(*args, **kwargs) except Exception as e: log.exception(任务执行失败: %s, task_func.__name__) return wrapper用这个装饰器包住所有定时任务日志里能看到每次任务的执行结果。就算某次任务崩了也不会影响后续调度。5.3 Windows 任务计划程序兜底Python 脚本本身有可能崩溃或者被杀掉APScheduler 调度得再好也白搭。这时候就需要 Windows 任务计划程序做一层兜底。我在项目里创建了一个名为WechatAutomation的任务计划设置开机自启并且勾选“如果任务失败每隔 5 分钟重新启动”。启动脚本用 bat 包装echo off cd /d C:\wechat_auto C:\Python382\python.exe main.py run.log 21配合 logging 同时输出控制台和文件出问题的时候打开run.log一眼就能定位到是哪个任务、哪一步挂了。日志时间戳要带毫秒因为微信同一个操作触发两次的间隔往往只有几秒不带毫秒很难判断执行顺序。6. 实测踩坑录升级、输入法、控件漂移这些坑6.1 微信一升级控件名全变了这是所有桌面自动化项目的头号杀手。某次微信自动更新后搜索框的 Name 从“搜索”变成了“搜索(CtrlF)”控件类名虽然没有变但 Name 的变化直接让Name搜索的定位全部失效。解决办法有两个而且必须同时做。第一是锁版本从根源上杜绝升级第二是写代码时用模糊匹配NameContains(搜索)而不是Name搜索。两个措施叠加之后即使微信偶尔静默升级脚本的容错率也高一些。6.2 中文输入乱码和丢字这个坑我前面提过但值得单独展开。uiautomation 的SendKeys本质上是把按键事件发送给窗口英文字符每一个都有对应的虚拟键码没问题但中文是输入法层面的组合输入SendKeys 发送的按键序列经过输入法转换后经常出现错乱。我第一次实现发消息时中文消息有时变成拼音有时变成乱码有时直接没进去。改成剪贴板大法之后问题彻底消失。细节上还有一个坑剪贴板操作偶尔会失败比如被其他程序占用所以pyperclip.copy之后应该做一次校验。def set_clipboard(text, retry3): for _ in range(retry): pyperclip.copy(text) if pyperclip.paste() text: return True time.sleep(0.5) raise RuntimeError(剪贴板写入失败)这个校验函数我加了之后再也没出现过“以为是发送成功实际消息为空”的问题。6.3 控件查找超时等待与重试微信启动慢、网络卡顿、窗口切换动画未结束都可能导致控件暂时不存在。我最初写脚本时直接window.ButtonControl(Name发送)如果控件还没加载完就点击直接抛异常。后来所有控件定位都封装了一层重试等待def wait_for(func, timeout10, interval0.5): start time.time() while time.time() - start timeout: try: result func() if result.Exists(1, 1): return result except Exception: pass time.sleep(interval) raise TimeoutError(等待控件超时)实践中等待时间根据控件类型区分窗口类控件给 10 秒按钮给 5 秒列表项给 3 秒。不需要每次都等满没等到才会走完整个超时流程。6.4 虚拟列表滚动加载的坑微信的会话列表和聊天记录是虚拟列表只渲染屏幕内可见的部分。如果直接遍历 ListControl 的所有子节点拿到的只是当前可视区域的那几个滚动之后才会加载新的。这个特性对聊天记录导出影响最大。我在导出逻辑里每个滚动周期都重新获取消息区域控件并重新点击就是为了确保焦点在消息区域CtrlA 选中的是当前看到的全部内容而不是微信窗口的其他部分。朋友圈滚动也有类似问题滚动太快图片区域会显示“加载失败”或者灰色占位图截图模板匹配自然就找不到点赞图标。我的做法是每次滚轮滚动之后强制等待 2 秒给图片渲染留足时间。6.5 DPI 缩放与坐标偏移Windows 10 在 125% 或 150% 缩放下pyautogui 的屏幕坐标和部分 UIA 控件返回的坐标会不一致导致点击位置偏移。这个问题一度让我非常头大明明控件定位到了点击却点到了旁边。最简单的解决办法是把系统缩放设为 100%。如果你需要高清显示可以在 python.exe 的兼容性设置里勾选“替代高 DPI 缩放行为”让进程自己感知 DPI。但要注意这个设置只对当前 python.exe 有效打包成 exe 后需要重新设置。更通用的做法是用 UIA 控件的BoundingRectangle属性拿到精确的屏幕矩形pyautogui 点击时用矩形中心点不要自己硬编码坐标偏移量。6.6 长时间挂机卡死与内存增长微信长时间自动化运行后内存占用会缓慢增长消息区域越来越卡脚本响应速度越来越慢。我最初以为是脚本内存泄漏排查半天发现是微信自身的问题——长时间不重启它的渲染缓存会越积越多。解决办法很粗暴但有效每 4 到 6 个小时用任务计划程序定时执行一个维护任务把微信进程完全关闭再重新拉起。如果你开启了微信的“自动登录”重启后不需要重新扫码可以无缝衔接。但这里有一个节奏控制的问题重启频率不能太密。每 1 小时重启一次微信的风控系统会觉得这个登录状态太诡异反而增加风险。4 到 6 小时是比较合理的区间白天保持在线晚上还可以额外降低频率。整个项目做完我最大的体会是桌面自动化不是做不到而是别把它想象成 Web 自动化那样清明透彻。微信不是给你写脚本用的所以工具要软一点、聪明一点、克制一点。固定在同一个 Windows 环境、锁定微信版本、用 UIA 加图像识别的混合方案是目前最实用的组合而比技术更重要的是在边界内使用它。如果你也在折腾类似的东西希望这份记录能让你少踩几个我踩过的坑。本文还有配套的精品资源点击获取
