第一个脚本：三行核心流程三个核心对象，理清查找链条等待、截图和几个实战坑
业务系统没有 API、没有命令行接口，数据只能靠人肉点点点才能导出来——这种场景在银行柜面、ERP 客户端、各种行业老软件里太常见了。Web 端有 Selenium，移动端有 Appium，偏偏 Windows 桌面应用一直缺一个顺手又统一的自动化方案。pywinauto 就是来补这个缺的：它通过 Win32 API 和微软的 UI Automation（UIA）去读窗口里的控件树，再按标题、类名、控件类型这些语义条件精准定位元素，而不是靠屏幕坐标瞎点。说白了，它模拟的是真人操作，但每一步都走"看得懂界面"的路线。
安装就一条命令的事：
pip install pywinauto
动手写脚本前，有个关键选择必须做对——选后端。pywinauto 有 win32 和 uia 两种后端，相当于两套和 Windows 界面打交道的"语言"。选错了，你会发现检查工具里明明看得到的控件，代码里死活找不到，这不是库的 bug，是沟通语言不对。
经验法则很简单：MFC、VB6、VCL 这些传统老程序，用；WinForms、WPF、UWP、Qt5 这类现代界面，用。拿不准的话，先用微软的 Inspect.exe 看一眼控件层级，再决定用哪个后端，比瞎试快得多。
backend="win32"
backend="uia"
看一个记事本的例子，pywinauto 的核心工作流其实就三步：启动或连接程序、定位窗口、操作控件。
frompywinautoimportApplication# 启动记事本app = Application(backend="uia").start("notepad.exe")# 连接窗口，用正则匹配标题，避免标题变动导致定位失败app = Application(backend="uia").connect(title_re=".*Notepad.*")main_window = app.top_window()# 定位文本编辑区并输入内容edit_area = main_window.child_window(control_type="Document")edit_area.type_keys("Hello pywinauto", with_spaces=True)
这里有个很实用的细节：比更常用。比如微信已经扫码登录好了，你让脚本去重新启动一个微信让它扫码登录，根本不现实。用直接接管已经打开的窗口，才是生产环境里的正确姿势。
connect()
start()
connect(title="微信")
pywinauto 的对象模型就三件套：管进程，管整个桌面，是"查找说明书"。
Application
Desktop
WindowSpecification
重点说说，它非常有意思：它不是一个真实窗口，只是一份记录了查找条件的说明书，真正的查找动作要等到你真正用它的时候才触发。这种延迟查找机制的好处是，窗口还没弹出来的时候你就可以先定义好规则，等界面就绪了再触发查找，天然契合桌面程序异步弹窗的特性。
WindowSpecification
调试的时候，用打印控件树，这是最省力的方式：
print_control_identifiers()
main_window.print_control_identifiers(depth=3)
输出会列出一棵完整的控件树，方括号里是每个控件的可用名称，那行是现成的定位写法，直接复制就能用。对照着写定位代码，比盲猜效率高一个量级。
child_window(...)
程序启动时界面没就绪，直接操作控件容易翻车。别用死等，试试，它等的是 CPU 占用回落到阈值以下，相当于等"加载真正完成"，比固定睡几秒又稳又快。
time.sleep()
wait_cpu_usage_lower(threshold=2.5)
脚本跑完了怎么证明它干过活？直接返回 PIL Image 对象，随手存个截图，自动化测试报告就有图有真相了。
capture_as_image()
最后提醒几个容易踩的坑：Chrome 要用启动参数才能被 UIA 识别；生产环境建议关掉属性访问的"魔法查找"（），不然访问不存在的属性不会立刻报错，错误会延迟到真正执行时才炸出来，排查起来很酸爽。
--force-renderer-accessibility
allow_magic_lookup=False
pywinauto 只支持 Windows 平台，跨平台场景得另找方案，这是它的边界，也是它的专注。你在项目里用它自动化过什么软件？踩过哪些坑？评论区聊聊。
热门跟贴