如何通过Python控制无CLI支持的纯GUI应用实现自动化操作

纯硬编码屏幕坐标的鼠标模拟点击是鲁棒性最差的实现路径，优先度排在所有方案的最后一位。这类硬写固定坐标的脚本（比如直接调用pyautogui.click(123, 456)），只要窗口被拖动、DPI缩放比例变化、主题修改导致菜单边距变动，就会直接点错位置完全失效，根本不适合长期使用。 #

Linux/Debian 环境下的分层最优方案 #

按照实现成本从低、稳定性从高到低排序：

• 第一优先级：基于AT-SPI原生无障碍接口的UI元素直接调用
  Debian/Ubuntu系桌面默认搭载AT-SPI无障碍框架，所有基于GTK/Qt开发的正规GUI应用（和Inkscape这类程序技术栈一致），都会默认在框架的全局元素注册树中暴露所有可交互控件的原生对象，完全不需要定位屏幕坐标。
  Python侧直接通过系统源安装python3-pyatspi库即可对接：启动G应用后，遍历AT-SPI的全局窗口树，找到对应目标窗口下的目标菜单项控件对象，直接调用对象自带的doAction()方法，就能触发和鼠标点击完全一致的效果——哪怕窗口被最小化、被拖动到屏幕外、DPI缩放比例调整，只要控件本身存在，操作就能成功，完全不受窗口位置影响。
• 第二优先级：基于D-Bus的应用原生接口透传
  绝大多数没有对外声明CLI接口的纯GUI应用，都会在用户会话的D-Bus总线上注册自身的服务接口，不需要额外的无障碍权限就能调用。通过pydbus库直接对接会话总线上的G应用服务，就可以直接触发打开文件、导出、参数配置这类内置动作，连UI层都不需要经过，稳定性远高于任何形式的界面模拟。
• 第三优先级：语义化的控件定位模拟
  如果遇到刻意关闭AT-SPI支持、也没有暴露D-Bus接口的程序，再考虑模拟操作，但绝对不要用硬编码的固定坐标。可以通过python-xlib、xdotool拿到目标窗口的控件相对位置，结合图像模板匹配定位目标控件的实时坐标，再触发点击——哪怕窗口大小改变、位置移动，定位逻辑都能自动适配，不会因为窗口偏移直接失效。

Windows平台的对应实践 #

逻辑和Linux侧完全对齐，同样优先避开纯坐标模拟：

• 第一优先级对接Windows原生UI Automation框架，Python侧用pywinauto库直接遍历G应用的控件树，直接调用控件的invoke()方法触发动作，和Linux下AT-SPI的效果一致。
• 针对传统Win32程序，可以直接通过窗口句柄给对应控件发送WM_COMMAND类系统消息，直接触发菜单绑定的动作，不需要任何模拟输入。
• 次选方案直接通过键盘快捷键触发对应菜单项：绝大多数GUI程序的菜单动作都绑定了快捷键，直接给目标窗口发送对应的快捷键组合（比如导出操作通常绑定Ctrl+Shift+E），比层层模拟鼠标点击的容错率高一个数量级。

比界面点击更简便的旁路实现路径 #

很多时候不需要走完UI操作的全流程，可以直接绕开界面层拿结果：

• 先检查G应用的本地配置目录~/.config/应用名/，绝大多数GUI程序都支持读取预设的启动配置、脚本文件，启动后可以自动加载预设工程、执行导出动作，全程不需要人工交互。
• 观察应用的临时缓存目录：如果操作目标是让G生成指定输出文件，很多程序在加载完预设工程后，会自动把渲染结果、编辑内容写入固定的缓存路径，等程序启动完成直接取缓存文件即可，根本不需要触发导出按钮。
• 如果没有找到现成接口，先手动给G应用的目标操作绑定自定义全局/应用内快捷键，后续全程通过键盘指令触发操作，比鼠标模拟的稳定性高得多。

注：所有方案都不需要逆向、修改G应用的二进制文件，完全基于系统提供的原生接口实现。

内容的提问来源于stack exchange，提问作者user7085000