关于AHK中ControlSend功能及底层Win32 API依赖函数的问询

你问到的AHK里的ControlSend确实是个很巧妙的函数——毕竟它既不像你测试的那样直接用SendMessage/PostMessage发普通的WM_KEYDOWN（那样窗口根本不认），也不靠keybd_event/SendInput做全局按键模拟（毕竟后台窗口也能精准接收）。我翻了AHK的源码和Win32的相关实现，给你拆解一下它到底依赖哪些核心API：

• FindWindowEx：这是第一步，ControlSend需要先定位到目标窗口里的具体控件（如果没指定控件名，就默认找窗口内第一个可接收输入的控件）。AHK会先根据你指定的窗口标识（比如ahk_pid %mypid%）拿到主窗口句柄，再用这个API遍历子控件，找到合适的输入目标。
• AttachThreadInput：这是让后台窗口能接收按键的关键！当目标窗口处于后台时，它的线程和当前AHK进程的线程输入上下文是分离的。这个API可以把AHK线程的输入状态附加到目标窗口的线程上，确保后续发送的按键消息能被目标窗口的消息循环正确识别和处理。
• MapVirtualKey：用来完成虚拟键码和扫描码之间的转换。因为Win32的按键消息（比如WM_KEYDOWN）的lParam参数里需要包含正确的扫描码，AHK会用这个API把你传入的字符（比如"a"）转换成对应的虚拟键码和扫描码，填充到消息参数里。
• SendMessageTimeout/SendMessage：最后就是发送实际的按键消息了。针对不同控件，AHK会选择不同的消息：
  • 对于标准编辑框、富文本框这类控件，它会优先发送WM_CHAR消息（直接传递字符的ASCII码），效率更高也更可靠；
  • 对于一些自定义控件，会发送完整的WM_KEYDOWN + WM_KEYUP消息对，并且严格按照Win32的规范填充lParam里的扫描码、重复计数、扩展键标志等参数——这也是你之前直接用SendMessage失败的原因：你没填对这些关键参数，窗口的消息处理函数根本不认你发的消息。

另外，你的示例脚本里的ControlSend,,{%key%}, ahk_pid %mypid%，AHK内部的处理流程就是：通过PID找到窗口句柄 → 用FindWindowEx定位输入控件 → 调用AttachThreadInput关联线程 → 用MapVirtualKey转换键码 → 发送对应的WM_CHAR或按键消息对 → 解除线程输入关联。

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