1. 項(xiàng)目概述為什么PostMessage/SendMessage模擬按鍵會“失靈”如果你正在用Delphi、VB.NET或者C這類語言嘗試通過PostMessage或SendMessage這兩個Windows API來模擬鍵盤鼠標(biāo)操作結(jié)果發(fā)現(xiàn)按鍵要么石沉大海、毫無反應(yīng)要么像“鬼畜”一樣瘋狂重復(fù)觸發(fā)那你絕對不是一個人。這幾乎是每個Windows桌面自動化開發(fā)者都會踩的經(jīng)典大坑。我見過太多項(xiàng)目從簡單的自動填表工具到復(fù)雜的游戲輔助腳本都在這兩個看似簡單的API上栽了跟頭。問題的核心遠(yuǎn)不止“調(diào)用一下API”那么簡單。PostMessage和SendMessage是Windows消息機(jī)制的核心它們的工作方式?jīng)Q定了其模擬輸入的行為充滿了“邊界條件”。很多人包括早期的我都天真地以為只要把WM_KEYDOWN、WM_KEYUP或者WM_LBUTTONDOWN這些消息扔給目標(biāo)窗口它就會像真人操作一樣響應(yīng)。但現(xiàn)實(shí)是一個正在播放全屏動畫的游戲窗口、一個處于忙碌狀態(tài)的輸入法候選框或者一個設(shè)置了特殊消息過濾的第三方控件都可能讓你的消息被直接無視或者引發(fā)意想不到的連鎖反應(yīng)比如按鍵重復(fù)。更讓人困惑的是網(wǎng)上充斥著大量零散的代碼片段和過時的教程它們往往只展示“成功”的那一面卻對失敗場景避而不談。當(dāng)你把代碼復(fù)制過來發(fā)現(xiàn)不work時那種挫敗感非常強(qiáng)烈。本文將徹底拆解PostMessage和SendMessage在模擬輸入時的底層邏輯、適用場景、致命陷阱以及排查鏈路。我會結(jié)合大量實(shí)際調(diào)試案例告訴你為什么消息會發(fā)送失敗為什么按鍵會重復(fù)以及面對不同場景如游戲、后臺窗口、失去焦點(diǎn)的控件時你應(yīng)該如何選擇工具鏈SendInput、keybd_event等和設(shè)計消息發(fā)送策略。目標(biāo)只有一個讓你不僅能寫出能跑的代碼更能寫出健壯、可靠、適應(yīng)復(fù)雜環(huán)境的自動化腳本。2. 消息機(jī)制深度解析PostMessage與SendMessage的本質(zhì)區(qū)別要解決問題必須先理解工具。PostMessage和SendMessage雖然名字相似但行為模式天差地別用錯了場景失敗是必然的。2.1 PostMessage異步的“投遞員”你可以把PostMessage想象成一個高效的郵差。它的工作是把一封寫著“按鍵按下”指令的信消息投遞到目標(biāo)窗口的消息隊(duì)列Message Queue里然后立刻轉(zhuǎn)身離開不管這封信何時被處理、甚至是否會被處理。這是一個異步非阻塞調(diào)用。關(guān)鍵行為與影響立即返回函數(shù)調(diào)用后立即返回不等待目標(biāo)窗口處理消息。這意味著你無法知道消息是否被成功“消費(fèi)”。依賴消息泵目標(biāo)窗口必須正在運(yùn)行其消息循環(huán)Message Loop即常說的“消息泵”并且沒有阻塞才能從隊(duì)列中取出并處理這封“信”。如果目標(biāo)程序卡死、繁忙例如在進(jìn)行大量計算或渲染或者是一個沒有自己消息泵的控制臺程序你的消息就會永遠(yuǎn)躺在隊(duì)列里直到超時被丟棄。線程關(guān)聯(lián)性PostMessage可以跨線程、甚至跨進(jìn)程發(fā)送消息這是它最大的優(yōu)勢之一。你可以從你的后臺服務(wù)程序向用戶正在操作的前臺記事本窗口發(fā)送按鍵消息。典型失敗場景目標(biāo)窗口無響應(yīng)程序“未響應(yīng)”Not Responding狀態(tài)時消息泵停止工作PostMessage的消息會堆積在隊(duì)列但無法處理。游戲/全屏應(yīng)用許多游戲使用自己的渲染循環(huán)可能接管或繞過了標(biāo)準(zhǔn)的Windows消息泵導(dǎo)致標(biāo)準(zhǔn)窗口消息無法被及時處理。發(fā)送速度過快如果你在一個循環(huán)里快速連續(xù)PostMessage而目標(biāo)窗口處理速度較慢消息隊(duì)列可能會溢出或被合并導(dǎo)致按鍵序列錯亂或丟失。2.2 SendMessage同步的“執(zhí)行官”SendMessage則像一位強(qiáng)勢的特派員。它親自帶著“指令”消息找到目標(biāo)窗口要求它立即當(dāng)場處理并且在目標(biāo)窗口完全處理完這條消息之前特派員會一直堵在門口等待不讓調(diào)用方繼續(xù)執(zhí)行。這是一個同步阻塞調(diào)用。關(guān)鍵行為與影響等待處理調(diào)用線程會被掛起直到目標(biāo)窗口的消息處理函數(shù)Window Procedure完成對該消息的處理并返回結(jié)果。SendMessage函數(shù)本身會返回這個處理結(jié)果。直接調(diào)用處理函數(shù)它不經(jīng)過消息隊(duì)列而是直接調(diào)用目標(biāo)窗口的窗口過程WndProc。這避免了隊(duì)列延遲但也帶來了風(fēng)險。線程死鎖風(fēng)險這是SendMessage最著名的陷阱。如果A線程向B線程的窗口SendMessage而B線程此時正在等待A線程的某個資源比如鎖那么就會形成死鎖兩個線程都卡住?？缇€程使用需極其小心。典型失敗場景跨線程死鎖如上所述是最常見也最難調(diào)試的問題之一。遞歸消息如果在處理SendMessage發(fā)來的消息時代碼又不慎觸發(fā)了另一個SendMessage到自身或關(guān)聯(lián)窗口可能引發(fā)不可預(yù)料的遞歸導(dǎo)致棧溢出或程序邏輯混亂。焦點(diǎn)與狀態(tài)因?yàn)橐罅⒓刺幚砣绻繕?biāo)窗口或控件處于一個“不能處理鍵盤消息”的狀態(tài)例如一個禁用的按鈕SendMessage可能會失敗或產(chǎn)生默認(rèn)處理而PostMessage的消息可能會在控件恢復(fù)可用狀態(tài)后被處理。注意對于模擬輸入我們通常發(fā)送的是WM_KEYDOWN,WM_KEYUP,WM_CHAR以及鼠標(biāo)相關(guān)的WM_LBUTTONDOWN等。這些消息通過SendMessage發(fā)送時會直接觸發(fā)目標(biāo)窗口的按鍵處理邏輯但不會經(jīng)過系統(tǒng)的鍵盤驅(qū)動層。這意味著一些依賴底層鍵盤鉤子Low-Level Keyboard Hook或輸入法編輯器IME的應(yīng)用程序可能無法正確識別這類“模擬”消息。2.3 與keybd_event和SendInput的對比為什么很多文章說“模擬鍵盤要用keybd_event或SendInput”因?yàn)樗鼈兪峭耆煌瑢蛹壍腁PI。keybd_event(已過時但常用)這是一個較老的API。它模擬的是硬件級別的鍵盤事件。當(dāng)你調(diào)用keybd_event時它會向系統(tǒng)的設(shè)備驅(qū)動層注入一個鍵盤掃描碼事件。這個事件會進(jìn)入系統(tǒng)的原始輸入流經(jīng)過Windows輸入子系統(tǒng)處理最終作為一個“真實(shí)的”鍵盤事件分發(fā)給前臺窗口。因此幾乎所有程序包括游戲、DirectInput應(yīng)用都能識別。但它只能模擬前臺輸入且是全局的。SendInput(現(xiàn)代替代品)這是keybd_event的升級版功能更強(qiáng)大、更靈活。它同樣在驅(qū)動層模擬輸入可以構(gòu)造一個包含鍵盤、鼠標(biāo)事件的輸入流INPUT結(jié)構(gòu)數(shù)組并原子性地注入。它支持發(fā)送到后臺窗口通過指定INPUT結(jié)構(gòu)中的dwFlags包含KEYEVENTF_UNICODE等標(biāo)志并結(jié)合目標(biāo)窗口句柄但后臺接收的兼容性依然取決于目標(biāo)程序。核心結(jié)論P(yáng)ostMessage/SendMessage是在應(yīng)用層模擬“窗口收到了一個按鍵消息”而keybd_event/SendInput是在系統(tǒng)層模擬“用戶物理按下了鍵盤”。前者輕量、精準(zhǔn)針對特定窗口但兼容性差后者兼容性極佳像真人在操作但不夠精準(zhǔn)通常是全局或前臺。3. “發(fā)送不成功”的完整排查鏈路與解決方案當(dāng)你的PostMessage或SendMessage沒有產(chǎn)生任何效果時不要盲目修改代碼。遵循一個系統(tǒng)的排查鏈路可以快速定位問題。3.1 第一步確認(rèn)目標(biāo)窗口句柄是否正確且有效這是最基礎(chǔ)也最常出錯的一步。一個無效的句柄NULL或已關(guān)閉的窗口句柄會導(dǎo)致發(fā)送失敗。排查方法使用SpyVisual Studio工具或類似工具如WinSpy這是最重要的步驟。手動定位到你想要發(fā)送消息的窗口或控件查看它的句柄、類名、標(biāo)題。用你的程序獲取的句柄與Spy顯示的進(jìn)行對比。動態(tài)句柄問題很多現(xiàn)代UI框架如WPF、Electron的控件句柄是動態(tài)生成的每次界面重繪都可能變化。你不能在程序啟動時獲取一次句柄就用到底。需要在每次發(fā)送消息前重新查找窗口句柄。使用FindWindow、FindWindowEx或EnumWindows等API進(jìn)行實(shí)時查找。子控件與父窗口你要操作的是一個按鈕(Button)還是一個文本框(Edit)確保你獲取的是最精確的那個子控件句柄而不是它的父窗口。向父窗口發(fā)送針對子控件的消息通常無效。代碼示例實(shí)時查找記事本編輯框// 假設(shè)我們要找記事本的編輯區(qū)域 HWND hwndNotepad FindWindow(LNotepad, NULL); // 查找記事本主窗口 if (hwndNotepad) { // 記事本的編輯區(qū)域是一個名為Edit的類 HWND hwndEdit FindWindowEx(hwndNotepad, NULL, LEdit, NULL); if (hwndEdit) { // 現(xiàn)在 hwndEdit 才是正確的目標(biāo)句柄 PostMessage(hwndEdit, WM_CHAR, (WPARAM)A, 0); } }3.2 第二步檢查目標(biāo)窗口狀態(tài)與消息泵獲得了正確句柄消息還是沒反應(yīng)接下來檢查接收方的狀態(tài)。排查點(diǎn)窗口是否可見且啟用使用IsWindowVisible和IsWindowEnabled函數(shù)檢查。向一個隱藏(WS_VISIBLE為false)或禁用(WS_DISABLED)的窗口發(fā)送消息可能被系統(tǒng)過濾。程序是否卡死如果目標(biāo)程序主線程卡死消息泵停止PostMessage的消息會堆積。SendMessage則會導(dǎo)致你的調(diào)用線程也一起卡死。是否為控制臺窗口控制臺窗口cmd, PowerShell有自己獨(dú)特的事件處理機(jī)制對標(biāo)準(zhǔn)窗口消息支持有限。模擬控制臺輸入更推薦WriteConsoleInputAPI。消息被過濾或吞掉了目標(biāo)窗口可能在其窗口過程WndProc中對你發(fā)送的特定消息如WM_KEYDOWN進(jìn)行了特殊處理比如直接返回0而不調(diào)用DefWindowProc導(dǎo)致標(biāo)準(zhǔn)按鍵行為未觸發(fā)?；蛘叱绦虬惭b了全局鉤子攔截了你的模擬消息。調(diào)試技巧在目標(biāo)程序中下斷點(diǎn)。如果你有目標(biāo)程序的源代碼在其WndProc函數(shù)里針對WM_KEYDOWN等消息下斷點(diǎn)看你的消息是否成功送達(dá)并被處理。使用SendMessageTimeout替代SendMessage。它可以設(shè)置一個超時時間避免因目標(biāo)窗口無響應(yīng)而導(dǎo)致你的線程無限期掛起。LRESULT lResult; DWORD_PTR dwResult; if (SendMessageTimeout(hwndTarget, WM_KEYDOWN, VK_RETURN, 0, SMTO_ABORTIFHUNG, 1000, dwResult)) { // 消息在1秒內(nèi)被處理或至少被投遞 } else { DWORD err GetLastError(); // 可能是 ERROR_TIMEOUT (1460) // 處理超時或失敗 }3.3 第三步驗(yàn)證消息參數(shù)與順序消息送到了處理了但效果不對可能是參數(shù)或順序錯了。鍵盤消息的關(guān)鍵參數(shù)wParam: 虛擬鍵碼Virtual-Key Code如VK_A表示A鍵VK_RETURN表示回車鍵。lParam: 一個32位值包含了重復(fù)次數(shù)、掃描碼、擴(kuò)展鍵標(biāo)志、上下文碼、前一個鍵狀態(tài)等復(fù)雜信息。自己構(gòu)造lParam極易出錯。常見錯誤lParam構(gòu)造錯誤對于WM_KEYDOWN和WM_KEYUPlParam的第30位表示前一個鍵狀態(tài)0表示之前是抬起1表示之前是按下。如果你連續(xù)發(fā)送兩個WM_KEYDOWN而中間沒有WM_KEYUP第二個WM_KEYDOWN的lParam中前一個鍵狀態(tài)位就應(yīng)該是1。手動計算很麻煩。缺少WM_CHAR消息很多文本輸入控件如Edit不僅需要WM_KEYDOWN/WM_KEYUP還需要一個WM_CHAR消息來產(chǎn)生實(shí)際的字符。正確的順序通常是WM_KEYDOWN-WM_CHAR-WM_KEYUP。修飾鍵狀態(tài)不同步模擬CtrlC時你需要先發(fā)送WM_KEYDOWN給VK_CONTROL然后發(fā)送WM_KEYDOWN給C鍵再發(fā)送WM_KEYUP給C鍵最后發(fā)送WM_KEYUP給VK_CONTROL。順序錯亂或遺漏會導(dǎo)致復(fù)制功能失效。一個相對可靠的發(fā)送“A”鍵的序列// 假設(shè) hwndEdit 是目標(biāo)編輯框句柄 // 1. 按下 Shift如果需要大寫 PostMessage(hwndEdit, WM_KEYDOWN, VK_SHIFT, 0); // 2. 按下 A 鍵 PostMessage(hwndEdit, WM_KEYDOWN, A, 0); // 3. 發(fā)送字符消息 PostMessage(hwndEdit, WM_CHAR, A, 0); // 4. 抬起 A 鍵 PostMessage(hwndEdit, WM_KEYUP, A, 0); // 5. 抬起 Shift PostMessage(hwndEdit, WM_KEYUP, VK_SHIFT, 0);提示對于更復(fù)雜的模擬建議使用MapVirtualKeyAPI來根據(jù)虛擬鍵碼獲取正確的掃描碼用于構(gòu)造lParam。或者更簡單粗暴的方法是直接發(fā)送WM_CHAR消息來輸入字符這通常對文本框有效但無法觸發(fā)快捷鍵如CtrlS。4. “重復(fù)按鍵”鬼畜現(xiàn)象的成因與根治比發(fā)送失敗更惱人的是消息成功觸發(fā)了但目標(biāo)程序像抽風(fēng)一樣連續(xù)執(zhí)行了多次操作。這通常不是你的代碼循環(huán)寫錯了而是Windows消息機(jī)制和程序處理邏輯共同作用的結(jié)果。4.1 成因一消息隊(duì)列的“自動重復(fù)”這是最常見的原因。當(dāng)你長時間按住一個物理鍵時系統(tǒng)會先產(chǎn)生一個WM_KEYDOWN然后根據(jù)鍵盤設(shè)置控制面板-鍵盤-重復(fù)延遲、重復(fù)速度自動向焦點(diǎn)窗口的消息隊(duì)列里定時插入帶有特定標(biāo)志的WM_KEYDOWN消息直到你松開鍵產(chǎn)生WM_KEYUP。當(dāng)你使用PostMessage發(fā)送WM_KEYDOWN時如果lParam參數(shù)構(gòu)造不當(dāng)特別是第30位前一個鍵狀態(tài)被錯誤地設(shè)置為0而目標(biāo)程序又恰好在處理WM_KEYDOWN時沒有立即響應(yīng)比如有短暫延遲系統(tǒng)或程序自身可能會誤認(rèn)為這是一個“新的、獨(dú)立的按鍵按下”從而可能觸發(fā)內(nèi)部的自動重復(fù)邏輯或者你的代碼邏輯被重復(fù)執(zhí)行。解決方案精確構(gòu)造lParam確保在發(fā)送連續(xù)的按鍵模擬時比如模擬按住方向鍵移動后續(xù)的WM_KEYDOWN消息的lParam中第30位前一個鍵狀態(tài)應(yīng)設(shè)置為1。這需要仔細(xì)計算。使用SendInput替代SendInput在驅(qū)動層模擬其“按下”和“抬起”狀態(tài)是明確的不會產(chǎn)生這種應(yīng)用層的自動重復(fù)歧義。對于需要持續(xù)按下的操作如游戲中的奔跑用SendInput發(fā)送一次按下等待再發(fā)送抬起是更可靠的做法。避免快速連續(xù)PostMessage在循環(huán)中發(fā)送消息時加入適當(dāng)?shù)难舆t如Sleep(10)讓目標(biāo)程序有時間處理完上一個消息可以減少消息隊(duì)列的混亂。4.2 成因二目標(biāo)程序的多重消息處理循環(huán)一些程序特別是游戲和多媒體應(yīng)用可能有多個消息循環(huán)或自定義的事件處理系統(tǒng)。你發(fā)送的窗口消息可能被主消息泵、渲染循環(huán)、DirectInput系統(tǒng)等多個地方同時捕獲并處理導(dǎo)致一次發(fā)送多次響應(yīng)。案例一個簡單的游戲窗口你向游戲窗口發(fā)送WM_KEYDOWN (VK_SPACE)想讓人物跳躍。游戲可能同時有主窗口的WndProc處理了這條消息觸發(fā)了一次跳躍。DirectInput或XInput設(shè)備輪詢時也從消息隊(duì)列里獲取到了這個“按鍵事件”又觸發(fā)了一次跳躍。游戲引擎的自定義輸入系統(tǒng)也訂閱了鍵盤事件再次觸發(fā)。結(jié)果就是一次發(fā)送人物連跳了三下。解決方案識別程序類型對于游戲和圖形應(yīng)用優(yōu)先考慮SendInput或更底層的驅(qū)動級模擬。嘗試發(fā)送到不同的句柄有時需要發(fā)送給游戲窗口的特定子控件或甚至線程ID而不是頂級窗口。用Spy觀察游戲運(yùn)行時哪些窗口接收了真實(shí)的鍵盤消息。終極方案硬件級模擬如果程序?qū)endInput都有防護(hù)或過濾可能需要考慮更底層但風(fēng)險也更高的方式如使用鍵盤過濾驅(qū)動需要簽名復(fù)雜度極高但這已超出一般自動化范疇需謹(jǐn)慎評估。4.3 成因三焦點(diǎn)切換與消息派發(fā)時序這個問題在VB.NET等環(huán)境中模擬鼠標(biāo)點(diǎn)擊時尤其典型對應(yīng)熱詞“vb.net模擬鼠標(biāo)失去焦點(diǎn)”。場景還原你用PostMessage向一個后臺按鈕發(fā)送WM_LBUTTONDOWN和WM_LBUTTONUP來模擬點(diǎn)擊。代碼邏輯是按下 - 抬起。但是當(dāng)WM_LBUTTONDOWN消息到達(dá)時系統(tǒng)可能會先將焦點(diǎn)切換到目標(biāo)窗口按鈕所在的窗口這個焦點(diǎn)切換事件本身也會產(chǎn)生一系列消息。如果焦點(diǎn)切換耗時或者你的WM_LBUTTONUP發(fā)送得太快可能在焦點(diǎn)切換完成前就到了。此時按鈕可能處于一個“正在獲取焦點(diǎn)”的中間狀態(tài)導(dǎo)致點(diǎn)擊事件處理異常甚至可能因?yàn)榻裹c(diǎn)變化系統(tǒng)或程序自己又補(bǔ)發(fā)了一次鼠標(biāo)消息造成重復(fù)點(diǎn)擊的假象。解決方案確保窗口在點(diǎn)擊前已激活/聚焦先發(fā)送WM_ACTIVATE或SetForegroundWindow然后短暫延遲如50-100ms再發(fā)送鼠標(biāo)點(diǎn)擊消息序列。使用SendMessage代替PostMessageSendMessage的同步特性可以確?！鞍聪隆毕⒈煌耆幚砗笤賵?zhí)行發(fā)送“抬起”消息的代碼避免了因異步性導(dǎo)致的時序問題。但要注意跨線程死鎖風(fēng)險。合并消息有些控件更響應(yīng)WM_LBUTTONDOWN和WM_LBUTTONUP的組合消息WM_COMMAND或BN_CLICKED。直接發(fā)送BM_CLICK消息對于按鈕控件可能是更簡單可靠的方式。// 模擬點(diǎn)擊一個按鈕比發(fā)送鼠標(biāo)消息更直接 SendMessage(hwndButton, BM_CLICK, 0, 0);5. 實(shí)戰(zhàn)場景下的API選型與策略理解了原理和坑點(diǎn)后面對具體場景我們該如何選擇5.1 場景一自動化辦公軟件如記事本、Word、瀏覽器表單特點(diǎn)標(biāo)準(zhǔn)Windows控件有完善的消息泵對窗口消息響應(yīng)良好。推薦方案PostMessage/SendMessage。策略優(yōu)先使用PostMessage避免死鎖。對于文本框輸入直接發(fā)送WM_CHAR消息序列通常最簡單有效。對于按鈕點(diǎn)擊嘗試直接發(fā)送BM_CLICK。使用FindWindowEx精確獲取子控件句柄。在連續(xù)操作間添加少量延遲Sleep(15~30)模仿人類操作速度提高穩(wěn)定性。5.2 場景二游戲或全屏圖形應(yīng)用如Unity游戲、模擬器特點(diǎn)可能使用自定義渲染循環(huán)、DirectInput、Raw Input等對標(biāo)準(zhǔn)窗口消息支持差。推薦方案SendInput。策略使用SendInput構(gòu)造鍵盤鼠標(biāo)輸入序列。確保程序運(yùn)行時目標(biāo)窗口是前臺窗口否則輸入可能被其他窗口接收。對于需要后臺掛機(jī)的游戲研究其是否支持后臺消息。有些游戲可以通過發(fā)送特定消息到其渲染窗口來響應(yīng)。這需要逆向分析通用性差。絕對不要嘗試用PostMessage向一個全屏DirectX游戲發(fā)送WM_KEYDOWN99%會失敗。5.3 場景三后臺自動化目標(biāo)窗口最小化或非激活特點(diǎn)目標(biāo)窗口不處于前臺甚至可能被遮擋。推薦方案組合拳。策略嘗試PostMessage這是最理想的因?yàn)樗灰蟠翱诩せ睢５芏喑绦蛟诜羌せ顮顟B(tài)下會忽略或簡化處理鍵盤消息。嘗試SendMessage風(fēng)險是可能因窗口線程繁忙導(dǎo)致調(diào)用線程阻塞。使用SendInput配合AttachThreadInput這是一個高級技巧。通過AttachThreadInput將你的線程輸入隊(duì)列與目標(biāo)窗口線程關(guān)聯(lián)然后使用SendInput模擬輸入有時可以讓后臺窗口接收到輸入。但此API不穩(wěn)定且可能引發(fā)副作用需謹(jǐn)慎測試。降低依賴設(shè)計你的自動化邏輯使其不依賴于精確的鍵盤鼠標(biāo)模擬。例如通過Windows UI AutomationUIA框架、直接調(diào)用程序的COM接口或內(nèi)部API來操作這些方式對窗口狀態(tài)依賴更小。5.4 一個綜合性的健壯發(fā)送函數(shù)示例下面是一個考慮了部分陷阱的、用于向標(biāo)準(zhǔn)編輯控件發(fā)送文本的Delphi/Pascal示例函數(shù)原理與其他語言相通procedure SendTextToEdit(hEdit: HWND; const AText: WideString); var i: Integer; ch: WideChar; vk, scan: Word; lParamDown, lParamUp: LPARAM; begin if not IsWindow(hEdit) or not IsWindowVisible(hEdit) or not IsWindowEnabled(hEdit) then Exit; // 基礎(chǔ)檢查 for i : 1 to Length(AText) do begin ch : AText[i]; vk : VkKeyScanW(ch); // 獲取虛擬鍵碼和Shift狀態(tài) scan : MapVirtualKeyW(vk and $FF, MAPVK_VK_TO_VSC); // 獲取掃描碼 // 構(gòu)造 lParam (簡化版實(shí)際應(yīng)根據(jù)前一個狀態(tài)位更精細(xì)控制) lParamDown : 1 or (scan shl 16); // 重復(fù)次數(shù)1 掃描碼 lParamUp : lParamDown or $C0000000; // 加上抬起標(biāo)志 // 處理Shift等修飾鍵這里簡化實(shí)際需要處理VkKeyScan返回的高字節(jié) if (vk and $FF00) 0 then begin // 例如如果需要Shift先按下Shift PostMessage(hEdit, WM_KEYDOWN, VK_SHIFT, 0); Sleep(10); end; // 發(fā)送按鍵序列 PostMessage(hEdit, WM_KEYDOWN, vk and $FF, lParamDown); Sleep(15); // 關(guān)鍵延遲讓消息被處理 PostMessage(hEdit, WM_CHAR, Ord(ch), 0); Sleep(10); PostMessage(hEdit, WM_KEYUP, vk and $FF, lParamUp); Sleep(15); // 抬起修飾鍵 if (vk and $FF00) 0 then begin PostMessage(hEdit, WM_KEYUP, VK_SHIFT, 0); Sleep(10); end; // 字符間延遲模擬真人輸入 Sleep(50 Random(30)); // 加入隨機(jī)延遲更自然 end; end;這個函數(shù)的要點(diǎn)說明前置檢查確保目標(biāo)窗口有效、可見、可用。鍵碼轉(zhuǎn)換使用VkKeyScanW和MapVirtualKeyW來正確獲取虛擬鍵碼和掃描碼比硬編碼更通用。修飾鍵處理嘗試處理Shift等狀態(tài)但這是一個簡化版真實(shí)場景中還需處理Ctrl、Alt等。關(guān)鍵延遲在WM_KEYDOWN和WM_KEYUP之間以及字符之間加入了Sleep。這是防止消息隊(duì)列過載、處理不及時導(dǎo)致丟失或重復(fù)的關(guān)鍵實(shí)踐。延遲時間需要根據(jù)目標(biāo)程序的響應(yīng)速度微調(diào)。隨機(jī)化在字符輸入間隔加入隨機(jī)延遲使模擬行為更接近真人避免被簡單的反自動化機(jī)制檢測。最后記住沒有銀彈。Windows消息模擬是一個需要大量測試和調(diào)試的領(lǐng)域。最有效的方法是先用Spy等工具觀察真實(shí)操作時產(chǎn)生了哪些消息、按什么順序、發(fā)給了哪個句柄然后用你的代碼去精確復(fù)現(xiàn)這一過程。當(dāng)PostMessage/SendMessage之路走不通時不要猶豫評估使用SendInput甚至更專業(yè)的UI自動化框架這才是通往穩(wěn)健自動化的正確路徑。