做自定義虛擬鍵盤這個(gè)需求聽(tīng)起來(lái)特別直接屏幕上擺幾個(gè)按鍵點(diǎn)擊就往輸入框里懟字符完事。但我最早在觸摸屏一體機(jī)上試水的時(shí)候光焦點(diǎn)這一個(gè)問(wèn)題就折騰了一周——每點(diǎn)一下鍵盤輸入框就失焦用戶辛辛苦苦輸?shù)揭话氲膬?nèi)容直接斷在中間。后來(lái)才明白虛擬鍵盤真正的難度根本不在畫按鍵而在于它要把自己偽裝成一套完整的輸入系統(tǒng)去對(duì)接頁(yè)面原有的輸入邏輯還不能喧賓奪主。這篇文章是我?guī)状螌?shí)操下來(lái)的一次完整復(fù)盤內(nèi)容包括技術(shù)方案選型、事件綁定鏈路、觸摸屏適配、數(shù)據(jù)驅(qū)動(dòng)布局還有那些文檔里不會(huì)寫的坑。不管你是要在普通Web頁(yè)面里做一個(gè)可定制按鍵的軟鍵盤還是在工業(yè)觸摸屏、自助終端上做一套專屬輸入組件這份指南都能當(dāng)做一個(gè)還算靠譜的起點(diǎn)。1. 虛擬鍵盤不是改個(gè)系統(tǒng)鍵盤皮膚這么簡(jiǎn)單1.1 先劃清楚邊界系統(tǒng)鍵盤和自定義鍵盤各自管什么移動(dòng)端瀏覽器里一個(gè)input聚焦之后系統(tǒng)鍵盤自動(dòng)彈出來(lái)這是操作系統(tǒng)給出的默認(rèn)輸入方案。它體驗(yàn)好、兼容強(qiáng)但你幾乎沒(méi)法控制它按鍵長(zhǎng)什么樣、允許輸入什么字符、按下之后額外觸發(fā)什么業(yè)務(wù)邏輯全部黑盒。自定義虛擬鍵盤恰恰相反——它拿回的是輸入過(guò)程的控制權(quán)。你可以決定鍵盤上只出現(xiàn)數(shù)字和大寫字母可以讓某個(gè)按鍵按下后不僅輸入字符還聯(lián)動(dòng)查詢可以為了讓戴手套的工人也能準(zhǔn)確點(diǎn)按而把按鍵做到60px高。但代價(jià)是系統(tǒng)原本替你處理的焦點(diǎn)管理、光標(biāo)移動(dòng)、輸入法組合、撤銷棧全部要自己接一遍。這里要特別提醒一下如果不是因?yàn)榭刂茩?quán)的需求只是覺(jué)得系統(tǒng)鍵盤丑想換個(gè)皮膚那大概率不該自己開(kāi)發(fā)。改造現(xiàn)有開(kāi)源庫(kù)或者用現(xiàn)成組件改樣式成本低得多。1.2 我拆解過(guò)的三類真實(shí)需求場(chǎng)景A工業(yè)觸摸屏人機(jī)界面。某設(shè)備廠商的10寸工控屏沒(méi)有物理鍵盤操作工人需要輸入批次號(hào)、物料編碼和工號(hào)。系統(tǒng)自帶的軟鍵盤字體小、按鍵密在車間光照下幾乎看不清而且彈出來(lái)之后經(jīng)常遮住正在查看的字段。這類需求的核心不是輸入效率而是大按鍵、高對(duì)比度、穩(wěn)定可靠按鍵布局要能按客戶要求定制比如把數(shù)字和字母分區(qū)排列。場(chǎng)景B自助終端。掛號(hào)機(jī)、排隊(duì)叫號(hào)機(jī)、信息查詢機(jī)這類設(shè)備輸入范圍非常收斂通常只有數(shù)字、身份證號(hào)、手機(jī)號(hào)。業(yè)務(wù)上要求不能輸字母和特殊符號(hào)界面風(fēng)格要和整機(jī)統(tǒng)一。這類需求最重要的是輸入限制和防誤觸一個(gè)按鍵只能觸發(fā)一個(gè)明確的結(jié)果。場(chǎng)景CWeb收銀/點(diǎn)單頁(yè)面。營(yíng)業(yè)員在觸摸屏一體機(jī)上快速錄入會(huì)員手機(jī)號(hào)、折扣碼或者調(diào)用常用短語(yǔ)。這類頁(yè)面通常還需要輸完手機(jī)號(hào)自動(dòng)查詢會(huì)員這種聯(lián)動(dòng)動(dòng)作。此時(shí)自定義鍵盤的價(jià)值不只是好看而是能把業(yè)務(wù)動(dòng)作直接綁定到按鍵上縮短操作路徑。1.3 什么情況別硬上自定義鍵盤反過(guò)來(lái)也說(shuō)說(shuō)。如果需求只是手機(jī)網(wǎng)頁(yè)里想換一套自定義鍵盤我一般會(huì)勸退。原因很簡(jiǎn)單在瀏覽器里只要input聚焦系統(tǒng)鍵盤就有機(jī)會(huì)彈出來(lái)你沒(méi)有可靠手段完全阻止它——所謂的readonly方案、inputmode方案都只是在減少?gòu)棾龅母怕首霾坏?00%屏蔽。強(qiáng)行把輸入框設(shè)成只讀再靠虛擬鍵盤往里填內(nèi)容又會(huì)引入光標(biāo)模擬、選區(qū)管理、中文輸入法沖突一堆新問(wèn)題。所以我的判斷原則是鍵盤需要和系統(tǒng)輸入法長(zhǎng)期共存尤其是手機(jī)瀏覽器場(chǎng)景就別自己做鍵盤是設(shè)備上的唯一輸入入口比如工控屏、一體機(jī)、封閉Webview才值得徹底自研。2. 技術(shù)方案選型不是所有網(wǎng)頁(yè)鍵盤都長(zhǎng)一個(gè)樣2.1 四種主流落地方式對(duì)比我整理了一下自己接觸過(guò)的虛擬鍵盤實(shí)現(xiàn)路徑方案適用場(chǎng)景優(yōu)點(diǎn)缺點(diǎn)DOM CSS 渲染按鍵常規(guī)Web、觸摸屏H5、一體機(jī)Webview開(kāi)發(fā)快、樣式定制靈活、天然支持無(wú)障礙語(yǔ)義動(dòng)畫和特效能力有限性能瓶頸在DOM量級(jí)Canvas / WebGL 繪制對(duì)動(dòng)效、按鍵特效要求極高的展示型界面渲染自由度最大可以實(shí)現(xiàn)非常復(fù)雜的視覺(jué)命中測(cè)試、文字排版、焦點(diǎn)管理都要自己造維護(hù)成本高桌面端方案Electron / Python Qt等桌面應(yīng)用里的模擬鍵盤能直接和原生窗口、硬件交互可做全局熱鍵跨平臺(tái)打包體積大更新節(jié)奏受框架限制系統(tǒng)級(jí)自定義鍵盤如移動(dòng)端輸入法擴(kuò)展需要全局鍵盤替代系統(tǒng)輸入法體驗(yàn)最接近原生開(kāi)發(fā)成本高、審核門檻高、只覆蓋特定平臺(tái)2.2 為什么我的項(xiàng)目最后都回歸DOM方案我做過(guò)好幾個(gè)版本的虛擬鍵盤最早也試過(guò)Canvas方案因?yàn)橄胫凑總€(gè)按鍵都是自己畫的Canvas自由度更高。結(jié)果發(fā)現(xiàn)Canvas方案里最難處理的不是畫按鍵而是點(diǎn)按命中你需要自己維護(hù)每個(gè)按鍵的矩形坐標(biāo)處理像素比適配點(diǎn)擊后還要判斷點(diǎn)到哪個(gè)鍵。最痛苦的其實(shí)是無(wú)障礙——Canvas里的每個(gè)鍵對(duì)屏幕閱讀器來(lái)說(shuō)都是一張無(wú)聲的圖片。DOM方案完全沒(méi)有這些煩惱。每個(gè)按鍵就是一個(gè)真實(shí)的DOM節(jié)點(diǎn)天然支持:active偽類、click事件、aria-label、鍵盤事件模擬。對(duì)虛擬鍵盤這種結(jié)構(gòu)固定、交互相對(duì)簡(jiǎn)單的組件來(lái)說(shuō)DOM的性能完全夠用——我在幾百毫秒的渲染周期內(nèi)渲染幾十個(gè)按鍵沒(méi)有任何壓力。2.3 依賴與框架層面的取舍不要一上來(lái)就引入一個(gè)重型UI框架。虛擬鍵盤本質(zhì)上是一個(gè)組件如果項(xiàng)目里已經(jīng)在用某個(gè)框架那就把它做成對(duì)應(yīng)框架的組件如果是一個(gè)原生頁(yè)面原生JS加少量模板邏輯就夠了。比較推薦的做法是鍵盤核心邏輯輸入映射、焦點(diǎn)管理、布局配置保持與框架無(wú)關(guān)用純函數(shù)和普通對(duì)象實(shí)現(xiàn)UI層只做薄薄一層的綁定。這樣以后從原生遷到Vue或者從Vue遷到React底層完全不用動(dòng)只改渲染層。這個(gè)設(shè)計(jì)我吃過(guò)甜頭——有個(gè)項(xiàng)目最早是原生寫的后來(lái)要嵌入到一個(gè)React應(yīng)用里因?yàn)楹诵倪壿嫑](méi)和DOM寫在一起遷移只花了一天。3. 事件綁定與輸入映射虛擬鍵盤的核心鏈路3.1 把字符送進(jìn)輸入框的三種思路你要敲一個(gè)字符到input里說(shuō)白了就三件事定位光標(biāo)、插入文本、讓框架感知到值變化。查了下我踩過(guò)的三條路直接改input.value。最簡(jiǎn)單把舊值和字符拼起來(lái)再賦回去。但這樣會(huì)破壞瀏覽器的原生撤銷棧輸入框的光標(biāo)位置會(huì)跳到末尾而且如果輸入框是有maxlength校驗(yàn)的直接賦值可能導(dǎo)致字符被截?cái)?。不推薦作為主方案。使用document.execCommand(insertText)。老一代方案里比較靠譜的它走的是瀏覽器的編輯命令通道能保留撤銷棧。但這東西官方明確標(biāo)記過(guò)廢棄狀態(tài)在部分Webview里行為不一致新項(xiàng)目我不會(huì)再用。使用selectionStart/selectionEnd setRangeText。現(xiàn)代瀏覽器里最接近原生輸入的做法。先拿到光標(biāo)位置再用setRangeText把文本插進(jìn)去最后手動(dòng)派發(fā)一個(gè)input事件通知框架。我現(xiàn)在的推薦寫法是function insertTextAtCursor(input, text) { const start input.selectionStart; const end input.selectionEnd; input.focus(); input.setRangeText(text, start, end, end); // 給 Vue / React 等框架一個(gè)信號(hào)值變了 input.dispatchEvent(new Event(input, { bubbles: true })); }setRangeText的第四個(gè)參數(shù)傳end意思是插入后光標(biāo)定位在插入文本的后面非常順手不用自己管光標(biāo)回收。3.2 焦點(diǎn)鎖定鍵盤不能搶走輸入框的焦點(diǎn)這一點(diǎn)是很多第一次做虛擬鍵盤的人翻車的地方。點(diǎn)擊鍵盤按鍵默認(rèn)行為是會(huì)觸發(fā)一次焦點(diǎn)轉(zhuǎn)移——如果鍵盤容器可以被聚焦輸入框就失焦了下一次insertTextAtCursor就找不到目標(biāo)。解法有兩個(gè)層面第一讓鍵盤容器本身不可聚焦避免焦點(diǎn)進(jìn)來(lái)。比如給它設(shè)置tabindex-1并且不要主動(dòng)調(diào)用它的focus()。第二對(duì)pointerdown事件調(diào)用preventDefault()阻止默認(rèn)的焦點(diǎn)改變行為。注意pointerdown上阻止默認(rèn)行為會(huì)連帶阻止后續(xù)兼容性的mouse事件和click事件所以按鍵的點(diǎn)擊邏輯不能依賴click要把邏輯放到pointerup或者自己處理。keyboardElement.addEventListener(pointerdown, (e) { // 阻止焦點(diǎn)從輸入框轉(zhuǎn)移到鍵盤上 e.preventDefault(); });這個(gè)寫法的副作用是鍵盤組件本身無(wú)法通過(guò)鼠標(biāo)觸發(fā)click所以如果你同時(shí)在開(kāi)發(fā)PC端需要額外在keydown里補(bǔ)一份對(duì)回車鍵和空格鍵的支持保證只用鍵盤也能操作虛擬鍵盤。3.3 功能鍵與狀態(tài)鍵Shift、CapsLock、Backspace 的完整處理真正的虛擬鍵盤不可能只有字母和數(shù)字功能鍵的處理才是布局是否好用的關(guān)鍵。最典型的是Shift鍵。它不是一個(gè)輸入字符而是一個(gè)狀態(tài)切換器。我的做法是維護(hù)一個(gè)布局映射關(guān)系按下Shift時(shí)把當(dāng)前布局切換到上層字符同時(shí)給Shift鍵本身加一個(gè)active視覺(jué)狀態(tài)再次按下或者輸入一個(gè)字母后自動(dòng)回到小寫布局。CapsLock則是一個(gè)鎖定狀態(tài)只切換大小寫不切換按鍵位置。const LAYOUT { lower: [ [1,2,3,4,5,6,7,8,9,0], [q,w,e,r,t,y,u,i,o,p], [shift,a,s,d,f,g,h,j,k,l,backspace], [alt,z,x,c,v,b,n,m,enter], [space] ], upper: [ [!,,#,$,%,^,,*,(,)], [Q,W,E,R,T,Y,U,I,O,P], [shift,A,S,D,F,G,H,J,K,L,backspace], [alt,Z,X,C,V,B,N,M,enter], [space] ] };Backspace刪除字符這里有講究。多數(shù)人第一反應(yīng)是把value減一個(gè)字符但遇到中文、Emoji這些由多個(gè)UTF-16編碼單元組成的字符時(shí)直接按編碼單元?jiǎng)h除會(huì)把字符劈成兩半。用Array.from轉(zhuǎn)成真正的字符數(shù)組再算好邊界刪除function deletePrevChar(input) { const start input.selectionStart; const end input.selectionEnd; if (start ! end) { // 存在選區(qū)直接刪選區(qū) input.setRangeText(, start, end, end); } else if (start 0) { // 按碼點(diǎn)取最后一個(gè)字符避免拆散表情或組合字符 const codePoints Array.from(input.value.slice(0, start)); const lastChar codePoints[codePoints.length - 1]; input.setRangeText(, start - lastChar.length, start, end); } input.dispatchEvent(new Event(input, { bubbles: true })); }Enter鍵的邏輯要按場(chǎng)景區(qū)分如果鍵盤使用在表單里應(yīng)該觸發(fā)表單提交如果用在聊天窗口則應(yīng)該是換行或發(fā)送。我習(xí)慣在按鍵分發(fā)層把動(dòng)作類型定義成action不在UI層寫死。3.4 和輸入法合成事件的沖突這里要單拎出來(lái)說(shuō)因?yàn)樗娴睦_了我很久。當(dāng)用戶在真實(shí)中文輸入法狀態(tài)下點(diǎn)擊你的虛擬鍵盤時(shí)輸入法可能正處于拼音候選的合成過(guò)程中。典型癥狀是明明按的是字母鍵結(jié)果輸入法把字母組合成拼音直接蹦出繁體字或者亂碼。標(biāo)準(zhǔn)做法是監(jiān)聽(tīng)compositionstart和compositionendlet isComposing false; input.addEventListener(compositionstart, () { isComposing true; }); input.addEventListener(compositionend, () { isComposing false; }); // 在插入邏輯入口判斷 if (isComposing) { // 合成期間放棄直接插入或者把按鍵內(nèi)容保存到暫存區(qū) return; }再深入一層自定義虛擬鍵盤在設(shè)計(jì)之初就要想清楚你打算支持中文輸入嗎如果支持工作量翻倍不止——需要拼音映射、候選詞面板、多音字處理。如果不支持只是面向數(shù)字、字母、符號(hào)的錄入那就在鍵盤外層明確屏蔽中文輸入法的干擾這通常更符合工控和自助終端的實(shí)際場(chǎng)景。4. 鍵盤布局與UI細(xì)節(jié)決定好用和能用的那20%4.1 用二維數(shù)組驅(qū)動(dòng)布局渲染而不是手寫一堆按鈕我見(jiàn)過(guò)不少項(xiàng)目里鍵盤的每個(gè)按鍵都是手寫的一個(gè)button幾十個(gè)按鈕在HTML里排成一大片。一旦客戶說(shuō)把刪除鍵從第四行挪到第一行整個(gè)布局就崩了。更合理的做法是把布局抽象成數(shù)據(jù)const keyboardData [ { type: key, value: 1, label: 1 }, { type: key, value: q, label: q }, { type: function, action: backspace, label: 刪除 }, { type: function, action: shift, label: Shift } ];再寫一個(gè)純粹的渲染函數(shù)把數(shù)組變成DOM按type分發(fā)不同的樣式和行為?？蛻粢牟季种恍枰臄?shù)據(jù)不需要碰代碼。這個(gè)設(shè)計(jì)對(duì)自定義虛擬鍵盤里的自定義三個(gè)字是決定性支撐——沒(méi)有數(shù)據(jù)驅(qū)動(dòng)你永遠(yuǎn)只能做一款固定的鍵盤。4.2 按鍵尺寸、間距與視覺(jué)密度尺寸這件事用數(shù)據(jù)說(shuō)話。手指觸摸的目標(biāo)最小建議是44px這是移動(dòng)端普遍接受的一個(gè)下限但在工業(yè)觸摸屏上操作者可能戴手套、車間環(huán)境有震動(dòng)我實(shí)際項(xiàng)目里都會(huì)做到至少48px甚至60px。有一個(gè)10寸屏項(xiàng)目客戶堅(jiān)持要把字體做到28px以上、按鍵間距4px實(shí)測(cè)下來(lái)誤觸率明顯下降。間距也不能太緊但也不需要太松。按鍵之間留4到8px的間隙視覺(jué)上既不會(huì)粘連又不會(huì)顯得松散。另外要考慮鍵盤總高度底部固定式鍵盤高度建議控制在屏幕的40%以內(nèi)否則會(huì)擠壓內(nèi)容區(qū)。4.3 按壓反饋虛擬鍵盤體驗(yàn)的靈魂沒(méi)有反饋的虛擬鍵盤會(huì)讓人感覺(jué)按鍵沒(méi)按下去。物理鍵盤有鍵程、有聲音觸摸屏上必須自己造出這些反饋。輕量級(jí)方案是CSS解決.key { transition: transform 0.05s ease, background-color 0.1s ease; } .key:active { transform: translateY(2px); background-color: #e8e8e8; }進(jìn)階一點(diǎn)按下去的時(shí)候用JavaScript給按鍵添加一個(gè)active類在pointerup/pointerleave時(shí)移除這樣即使手指滑出按鍵區(qū)域也不會(huì)有粘住的問(wèn)題。如果設(shè)備自帶震動(dòng)馬達(dá)還可以在pointerdown時(shí)調(diào)用navigator.vibrate(10)一個(gè)10毫秒的短震手感立刻不一樣。4.4 功能鍵的視覺(jué)狀態(tài)管理Shift按下、CapsLock開(kāi)啟按鍵本身必須給出可見(jiàn)的狀態(tài)變化。我習(xí)慣用數(shù)據(jù)傳輸狀態(tài)而不是靠臨時(shí)改樣式const keyboardState { shift: false, caps: false }; function getCurrentLayout() { const upper keyboardState.shift ! keyboardState.caps ? upper : lower; return LAYOUT[upper]; }這里有個(gè)細(xì)節(jié)Shift CapsLock組合時(shí)大小寫應(yīng)該是取反的關(guān)系。如果CapsLock是大寫鎖定再按Shift會(huì)臨時(shí)切換成小寫——和物理鍵盤行為保持一致用戶才不會(huì)有認(rèn)知錯(cuò)亂。5. 觸摸屏與移動(dòng)端從鼠標(biāo)點(diǎn)按到手指操作的距離5.1 為什么推薦用 Pointer Events 而不是 click在PC網(wǎng)頁(yè)里click事件很可靠。但在觸摸屏和移動(dòng)端click存在兩三百毫秒的延遲窗口用戶會(huì)明顯感覺(jué)到按下去沒(méi)反應(yīng)等了一下才觸發(fā)。舊時(shí)代我們靠touchstart處理但touchstart和mouse事件并存時(shí)又會(huì)觸發(fā)多次點(diǎn)擊。統(tǒng)一方案是pointerdown/pointerup。Pointer Events 把鼠標(biāo)、觸摸、筆統(tǒng)一成一種抽象pointerdown在手指觸摸時(shí)立刻觸發(fā)沒(méi)有延遲而且可以用pointerType區(qū)分是手指還是鼠標(biāo)方便做差異邏輯。實(shí)際項(xiàng)目里我把虛擬鍵盤的所有按鍵邏輯都掛在pointerup上pointerdown只負(fù)責(zé)視覺(jué)反饋和焦點(diǎn)鎖定。5.2 防止觸摸引發(fā)的頁(yè)面滾動(dòng)和縮放觸摸屏上點(diǎn)鍵盤時(shí)手指稍微一滑頁(yè)面就跟著滾動(dòng)了這個(gè)體驗(yàn)很糟糕。兩個(gè)層面的處理第一給鍵盤容器設(shè)置touch-action樣式。touch-action: manipulation表示允許平移和縮放但禁止雙擊縮放如果想徹底禁用容器內(nèi)的手勢(shì)可以用touch-action: none。第二在pointermove時(shí)判斷是否發(fā)生了明顯滑動(dòng)如果滑動(dòng)距離超過(guò)一定閾值就視為取消本次點(diǎn)擊防止用戶在按住一個(gè)鍵想滑到另一個(gè)鍵的過(guò)程中誤觸發(fā)。這是一個(gè)很細(xì)節(jié)但很實(shí)用的手感調(diào)優(yōu)點(diǎn)。5.3 系統(tǒng)鍵盤干擾移動(dòng)端最大的頭痛問(wèn)題在手機(jī)瀏覽器里做自定義虛擬鍵盤最尷尬的事情是你自己的鍵盤彈出來(lái)了系統(tǒng)鍵盤也跟著彈出來(lái)。前面說(shuō)過(guò)這塊沒(méi)有完美的方案但我實(shí)際摸索出一個(gè)折中策略在封閉Webview或一體機(jī)設(shè)備上系統(tǒng)鍵盤本來(lái)就不會(huì)出現(xiàn)直接用真實(shí)input加自定義鍵盤體驗(yàn)最好。在手機(jī)瀏覽器上如果一定要隱藏系統(tǒng)鍵盤可以把輸入框設(shè)為只讀由虛擬鍵盤直接操縱它的值。壞處是無(wú)法用selectionStart精準(zhǔn)控制光標(biāo)也無(wú)法支持輸入法合成。實(shí)測(cè)下來(lái)如果要支持光標(biāo)位置精確操作 中文輸入法 選區(qū)操作這三件事只讀方案完全扛不住如果只是數(shù)字加字母的簡(jiǎn)單輸入只讀方案勉強(qiáng)可用。所以這個(gè)難題的根本解法還是移動(dòng)端瀏覽器頁(yè)面盡量別做自定義鍵盤如果要做就接受不能完全屏蔽系統(tǒng)鍵盤的現(xiàn)實(shí)。5.4 鍵盤定位與頁(yè)面resize底部固定式鍵盤最常見(jiàn)的實(shí)現(xiàn)是position: fixed; bottom: 0。但在移動(dòng)端當(dāng)系統(tǒng)鍵盤彈出時(shí)visualViewport高度會(huì)變化鍵盤和輸入框的相對(duì)位置需要?jiǎng)討B(tài)調(diào)整。可以監(jiān)聽(tīng)visualViewport的 resize 事件實(shí)時(shí)計(jì)算鍵盤的top值把鍵盤推高到系統(tǒng)鍵盤上方如果是自己彈出的鍵盤則保持固定在底部即可。6. 焦點(diǎn)丟失、輸入重復(fù)與光標(biāo)漂移實(shí)測(cè)最常遇見(jiàn)的三個(gè)坑6.1 焦點(diǎn)丟失點(diǎn)擊一次輸入框就失焦一次在某個(gè)自助終端項(xiàng)目里用戶每點(diǎn)一個(gè)數(shù)字輸入框的光標(biāo)就消失一次。排查過(guò)程很有意思一開(kāi)始以為是我的鍵盤焦點(diǎn)問(wèn)題后來(lái)發(fā)現(xiàn)在輸入框的全局blur監(jiān)聽(tīng)里有一段來(lái)自外層框架的邏輯任何失焦都會(huì)觸發(fā)一個(gè)隱藏操作把輸入框隱藏了。要復(fù)現(xiàn)這個(gè)問(wèn)題的排查鏈路要點(diǎn)是在輸入框的blur事件里打日志確認(rèn)失焦發(fā)生的時(shí)間點(diǎn)在鍵盤pointerdown里打日志確認(rèn)事件觸發(fā)的先后順序檢查是否有全局的focus/blur代理邏輯在干擾。真正的解法還是前面說(shuō)過(guò)的鍵盤pointerdown阻止默認(rèn)行為 鍵盤容器不可聚焦。如果失焦是外層框架造成的則需要在外層框架的失焦回調(diào)里做一個(gè)焦點(diǎn)即將轉(zhuǎn)移給鍵盤的豁免判斷。6.2 輸入重復(fù)一次按鍵觸發(fā)了兩次插入這個(gè)坑主要出在手動(dòng)派發(fā)input事件 框架自己的v-model同時(shí)生效的配置里。比如Vue的v-model本身就監(jiān)聽(tīng)input事件去更新數(shù)據(jù)你又手動(dòng)派發(fā)了一次input數(shù)據(jù)更新邏輯跑了兩次屏幕上就出現(xiàn)了字符重復(fù)。解法是在派發(fā)input事件前先對(duì)值做一次比對(duì)function updateInputValue(input, newValue) { if (input.value newValue) return; // React 需要走原生 setterVue 直接賦值即可 input.value newValue; input.dispatchEvent(new Event(input, { bubbles: true })); }React 還有一個(gè)額外問(wèn)題它內(nèi)部會(huì)用一個(gè)值跟蹤器記錄輸入框當(dāng)前值直接修改input.value后派發(fā)事件React 可能認(rèn)為值沒(méi)有變化。標(biāo)準(zhǔn)技巧是const valueSetter Object.getOwnPropertyDescriptor( window.HTMLInputElement.prototype, value ).set; valueSetter.call(input, newValue); input.dispatchEvent(new Event(input, { bubbles: true }));6.3 光標(biāo)漂移輸入一個(gè)字符后光標(biāo)跳到了末尾setRangeText在多數(shù)情況下能保持光標(biāo)位置但如果你在插入之后又隨手做了一次input.value input.value text這種操作光標(biāo)必然跳到末尾。另外一個(gè)隱蔽場(chǎng)景是輸入框有maxlength限制setRangeText插入后觸發(fā)了瀏覽器的截?cái)喙鈽?biāo)位置就不在預(yù)期位置了。處理思路是每次插入之前把selectionStart/selectionEnd保存到變量里插入之后如果框架發(fā)生了重渲染再手動(dòng)恢復(fù)一次光標(biāo)位置。這個(gè)方法笨但可靠尤其在遠(yuǎn)程調(diào)試一些老Webview時(shí)特別管用。6.4 隱藏鍵盤的觸發(fā)策略虛擬鍵盤在自助終端上通常常駐但在共享屏幕上用完后要及時(shí)隱藏。我常用的觸發(fā)策略是點(diǎn)擊鍵盤之外的空白區(qū)域隱藏鍵盤輸入框blur且焦點(diǎn)沒(méi)有轉(zhuǎn)移到鍵盤本身隱藏鍵盤按Enter確認(rèn)后如果業(yè)務(wù)允許隱藏鍵盤。注意點(diǎn)擊空白區(qū)域要用pointerdown監(jiān)聽(tīng)并且要排除掉鍵盤容器本身否則每次點(diǎn)擊按鍵都會(huì)先觸發(fā)隱藏邏輯再觸發(fā)插入邏輯出現(xiàn)一種鍵盤閃一下的糟糕體驗(yàn)。7. 值得提前做好的工程化設(shè)計(jì)7.1 按鍵事件統(tǒng)一走分發(fā)器而不是散落在各個(gè)按鈕上虛擬鍵盤的按鍵種類再多歸納起來(lái)無(wú)非三類字符鍵、功能鍵、狀態(tài)鍵。我習(xí)慣把它們統(tǒng)一抽象成一個(gè)動(dòng)作分發(fā)器function dispatchKeyAction(type, payload) { switch (type) { case input: insertTextAtCursor(activeInput, payload); break; case delete: deletePrevChar(activeInput); break; case shift: keyboardState.shift !keyboardState.shift; renderLayout(); break; case enter: handleEnter(); break; default: break; } }所有按鍵在HTML層面只負(fù)責(zé)一個(gè)職責(zé)告訴分發(fā)器我是什么類型的按鍵。業(yè)務(wù)邏輯不散落在幾十個(gè)按鈕的監(jiān)聽(tīng)器里排查問(wèn)題就只需要看這一個(gè)函數(shù)。7.2 布局和按鍵行為配置化自定義虛擬鍵盤如果只是代碼層面改數(shù)組還不算真正的自定義。我后期的實(shí)現(xiàn)里布局通常是一個(gè)JSON配置業(yè)務(wù)人員可以直接改配置文件重新生成鍵盤。{ rows: [ [{label: Q, value: q, type: input}], [{label: 刪除, type: function, action: backspace}] ] }比如有的客戶要放一個(gè)快捷錄入上次訂單的按鍵只需要在配置里增加一個(gè){ type: function, action: repeatLastOrder }核心代碼只需要注冊(cè)一下這個(gè)動(dòng)作。把擴(kuò)展成本從改代碼降到改配置虛擬鍵盤才真正配得上自定義三個(gè)字。7.3 中文輸入的冷思考最后必須潑一盆冷水。如果你以為虛擬鍵盤只是把英文字母做成可以點(diǎn)擊的按鈕然后要求它支持中文輸入那工程量會(huì)瞬間爆炸拼音到漢字的映射庫(kù)、多音字處理、候選詞排序、詞庫(kù)加載隨便一個(gè)都是獨(dú)立項(xiàng)目的規(guī)模。我現(xiàn)在的判斷標(biāo)準(zhǔn)很清楚支持中文輸入的自定義鍵盤優(yōu)先考慮現(xiàn)有中文輸入法SDK或者系統(tǒng)輸入法自定義鍵盤默認(rèn)定位是受限字符集輸入工具也就是數(shù)字、拉丁字母、常用符號(hào)。這個(gè)定位能讓交付質(zhì)量和工期都保持在可控范圍。如果確實(shí)必須中文抱著一整塊工程量去做規(guī)劃和報(bào)價(jià)千萬(wàn)不要在開(kāi)發(fā)中后期臨時(shí)加需求。我的個(gè)人體會(huì)是虛擬鍵盤項(xiàng)目的成敗一半在立項(xiàng)之前的邊界劃分一半在事件鏈路的細(xì)節(jié)處理。前者決定了你是不是在做一個(gè)不可能完成的需求后者決定了做出來(lái)能不能被用戶接受。技術(shù)上高深的部分不多但每一個(gè)看起來(lái)沒(méi)什么的細(xì)節(jié)——焦點(diǎn)、光標(biāo)、事件派發(fā)、觸摸反饋——都足夠讓一個(gè)沒(méi)有經(jīng)驗(yàn)的人卡上兩三天。其實(shí)這也是我寫下這份指南的原因希望有更多人能少踩我當(dāng)年踩過(guò)的那些坑直接把精力放到真正有價(jià)值的功能設(shè)計(jì)上去。