EnumChildWindows是Windows API中用于递归枚举指定父窗口所有子窗口（含嵌套子窗口）的函数，通过回调函数逐个传递句柄，支持深度遍历与条件过滤，是黑盒自动化测试的关键入口点。
EnumChildWindows 是 Windows API 中最常被误用、但又绕不开的黑盒自动化入口点。它不依赖目标程序源码，也不需要 .NET 反射或 UIA，适合测试 Win32、MFC、WinForms 甚至部分 WPF（启用 Win32 子窗口模式时）的老系统。
你不需要等目标程序暴露接口，只要它有窗口句柄，就能从外层“摸进去”。
怎么用 EnumChildWindows 找到 TextBox 和 Button 的句柄
关键不是“枚举一次”，而是递归+条件过滤+控件识别组合。很多新手卡在第一步：只调了一次 EnumChildWindows，结果只拿到主窗体的直接子控件（比如菜单栏、状态栏），漏掉了嵌套在 Panel 或 GroupBox 里的真实控件。
实际操作要分三步走：
- 先用
FindWindow拿到目标进程主窗口句柄（靠ClassName或WindowName，SPY++ 可查） - 再用
EnumChildWindows遍历所有子窗口，回调函数里检查GetClassName和GetWindowText - 对每个子窗口继续调
EnumChildWindows，实现深度遍历（别忘了加递归终止条件，比如深度 > 10）
常见错误是把 TextBox 识别成 EDIT 类，把 Button 识别成 Button 类——没错，Win32 下它们的原生类名就是这些，不是 .NET 的控件名。
示例片段（简化版）：
private List<IntPtr> _foundHandles = new();
private void EnumAllChildren(IntPtr hWndParent, int depth = 0) {
if (depth > 8) return;
EnumChildWindows(hWndParent, (hWnd, lParam) => {
var className = GetClassName(hWnd);
var text = GetWindowText(hWnd);
if (className == "EDIT" && text.Contains("test")) {
_foundHandles.Add(hWnd);
}
if (className == "Button" && text == "Submit") {
_foundHandles.Add(hWnd);
}
EnumAllChildren(hWnd, depth + 1); // 继续向下
return true;
}, IntPtr.Zero);
}为什么 SendMessage 发文本老是失败
SendMessage 对 EDIT 控件发 WM_SETTEXT 看似简单，但容易栽在三个地方：
一是目标控件没就绪：有些 WinForms 程序会在 Load 后延迟初始化控件句柄，直接发消息会静默失败；
二是线程上下文不对：SendMessage 必须由创建该窗口的线程调用，跨线程发会卡住或返回 0；
三是字符编码问题：.NET 字符串默认 UTF-16，但某些老程序只认 ANSI，得用 SendMessageA + Marshal.StringToHGlobalAnsi。
更稳的做法是组合使用：
- 先用
PostMessage发WM_KEYDOWN/WM_CHAR模拟按键输入（绕过线程限制） - 或用
SetForegroundWindow+keybd_event（适合简单场景，但会被用户中断） - 对关键步骤加等待：比如发完文本后，
SendMessage(hWnd, WM_GETTEXTLENGTH, ...)检查长度是否匹配
如何避免被目标程序反自动化检测
不少工业软件（如 PowerMill、SolidWorks 插件界面）或金融客户端会主动检测鼠标/键盘模拟行为，典型表现是：按钮点了没反应、文本框输不进、甚至弹出“检测到异常操作”提示。
这不是你的代码错了，而是它在读 GetAsyncKeyState、监控 WH_CALLWNDPROC 钩子、或检查 GetMessagePos 是否为 (0,0)。
绕过思路很实际：
- 不用
mouse_event，改用SendMessage直接发BM_CLICK给按钮句柄（无鼠标移动痕迹） - 避免全局钩子，所有操作基于已知句柄，不注入 DLL
- 关键操作前调
AllowSetForegroundWindow(ASFW_ANY)，防止焦点抢占失败导致输入丢失 - 加随机延时（50–300ms），避开固定节奏检测逻辑
真正难的不是“能不能点”，而是“点得像不像人”。很多项目败在最后一步：没处理好窗口激活顺序和焦点链，导致 EDIT 控件虽然拿到了句柄，却因没获得输入焦点而丢弃输入。
完整项目结构里最容易被忽略的一环
不是 API 调用，也不是句柄查找，而是进程生命周期管理。
你写了个自动点击工具，跑一遍成功了；但第二遍失败——因为上一次的 FindWindow 找到了残留的旧进程窗口（比如程序崩溃后没彻底退出），句柄还在，但内部状态已损坏。
正确做法是：
- 每次操作前，用
Process.GetProcessesByName校验目标进程是否存活且只有一个实例 - 必要时先
Terminate旧进程（注意权限），再启动新实例 - 用
WaitForInputIdle等待主窗口完成初始化，而不是盲目Thread.Sleep(2000) - 所有句柄缓存加时效标记，超 5 秒未刷新就视为失效，重新查找
这层逻辑不写进 Services 层，而是放在最外层的执行协调器里——它不关心“怎么点”，只负责“什么时候点、点谁、点失败了怎么办”。这才是工业级黑盒自动化能长期跑稳的关键。
