✅ 一、为什么老版本微信能被 UIAutomation 遍历，而新版本不能？

🟢 旧版微信（如 4.0.3）

• 主窗口类名是 QMainWindow
• 使用的是 Qt Widgets 技术栈
• 控件本质上是 Windows 窗口（Win32 window）、句柄（HWND）
• 因此 UIAutomation 能够枚举控件（通过 Accessible / UIA provider）

👉 所有子控件都有 Windows 句柄 → 可以被 UIAutomation 查找和操作。

---

🔴 新版微信（如 4.0.5 以后）

你看到的主窗口类名是：

qt51514QWindowIcon

特点：

• Qt 升级到 Qt 5.15+
• 主 UI 技术栈从 Qt Widgets 转为 Qt Quick(QML)/Qt Quick Controls
• Qt Quick 使用 OpenGL 渲染 UI，绝大多数控件没有独立 HWND
• 整个界面绘制到 1～2 个大窗口中（通常只有主窗口一个）

👉 结果：UIAutomation 无法枚举控件，因为根本不存在控件的句柄

⚠ 因此，新版微信的 UI 不再暴露传统 Windows 控件 → 遍历失败是正常现象。

---

✅ 二、Qt Widgets 与 Qt Quick 的核心区别（与你的问题直接相关）

项目	Qt Widgets (旧版微信)	Qt Quick/QML (新版微信)
渲染方式	原生 Win32 控件	GPU/OpenGL 渲染到一张画布
子控件句柄	每个控件有 HWND	几乎没有子窗口
UIAutomation	能遍历控件	无法遍历（只有一层窗口）
自动化可行性	高	极低，需要其他方法

---

✅ 三、新版微信自动化的 对策 / 替代方案

由于 UIAutomation 基本不可用了，你可以考虑以下方案：

---

✔ 1. Accessibility 接口（Qt 的 QAccessible）

Qt Quick 可以提供 QAccessible 信息，但 需要应用本身启用。

➡ 微信官方未启用，无直接可用。

⚠ 除非你做 DLL 注入开启 Qt Accessibility，不然不可行。

---

✔ 2. OCR + 控件位置映射（最常用可行方案）

行业主流方案（大部分自动化框架都这样做）。

流程如下：

1. 截图窗口画面
2. OCR 识别文字/图标位置
3. 将坐标映射到窗口
4. 使用鼠标/键盘模拟器发送操作

工具：

• PaddleOCR
• 腾讯 OCR
• Windows.Graphics.Capture + Win32 input

👉 这是目前最实际、最稳定、最不容易被封的方案。

---

✔ 3. 内部 Hook / dll 注入（高级方案）

通过 DLL 注入微信，直接 hook QtQuick 渲染树：

可 hook：

• QQuickItem
• QQuickWindow
• QSGNode

实现：

• 自动从 Qt 的 item tree 中找控件
• 调用 QMetaObject 直接触发 signal/slot

⚠ 难度极高，且可能触发安全策略。

---

✔ 4. 使用官方 API 的替代方案（如 itchat, wxauto）

如果你只是做消息自动化，而不是 UI 自动化：

• wxauto（基于 OCR+模拟点击）
• itchat-uos（基于 Web 底层协议）
• wechatbot 等（协议层）

👉 如果你的目标是消息、联系人等操作，不推荐操作 UI。

---

✔ 5. 使用 Windows UIA 的图像识别模式（WAII / Computer Vision UIA）

新版 Windows (Win11) 提供：

UI Automation → Image-based controls

允许用控件截取的图像查找控件。

但微信的窗口对 GPU 渲染，效果有限。

---

✅ 四、最佳建议（根据你的情况）

如果你的目标是：

🎯 操作微信 PC 端 UI（点击、输入）

➡ 最推荐的方案：

✔ OCR + 坐标点击 + 输入法文本注入

第三方库如：

• pywinauto（支持 OCR，可二次封装）
• PaddleOCR + pyautogui
• Airtest（主流 UI 自动化框架）

---

🎯 实现微信聊天、收发消息等功能

➡ 直接使用协议层，不操控 UI
避免 UI 自动化（难度高且易失效）