微信小游戏这一套环境做过的朋友都清楚它跟标准的WebGL发布完全是两码事。Unity里跑得好好的InputField打包成小游戏丢进微信点上去一点反应没有键盘就是不弹——这个问题几乎每个第一次把Unity项目搬到微信小游戏的团队都会撞一次。我自己头一回遇到的时候也以为是InputField的Raycast被挡了折腾了半天UI层最后才发现根本不是那么回事。这篇文章就把Unity微信小游戏无法调起输入框从头到尾拆一遍为什么会调不起来、微信小游戏自己提供了哪些输入接口、Unity的InputField/ TMP_InputField该怎么改造成能用的状态、键盘高度变化怎么让界面避让、真机和开发者工具行为差异怎么排查以及多行输入、仿输入框槽位这类进阶需求该怎么落地。适合正在做Unity微信小游戏、被输入框卡住的开发也适合还没踩坑、想提前避坑的同学参考。1. 先别急着改代码把调不起输入框这件事分层看很多人一上来就去翻InputField的Inspector怀疑是readOnly勾了、interactable被关了、或者有透明Image挡在前面。这些当然要排查但如果你是在微信小游戏里遇到的99%的概率问题不在这些地方。要搞清楚它得先明白点击UI后弹键盘这条链路在Unity原生、标准WebGL、微信小游戏这三种环境里走的是完全不同的路径。1.1 三种典型报错现场我见过的情况大体分三类先对号入座一下能省掉不少瞎试的时间。第一类点击InputFieldUI上有高亮或者选中态但键盘死活不弹。光标可能都不出现或者出现了但一闪就没。这种情况基本可以判定是输入法调起链路断了。第二类键盘弹出来了但输入的内容不进InputField或者输入一个字就断了、光标乱跳。这类通常是事件绑定和回填逻辑的问题键盘本身没问题。第三类键盘弹出来、内容也进去了但是键盘把整个界面顶飞了或者收起键盘后画面错位、黑屏、UI偏移。这属于布局和渲染层的问题是另一个维度。提示在动手改之前先确认你遇到的是哪一类。很多所谓调不起输入框其实是第二类或第三类改错了方向会越改越乱。1.2 WebGL的输入链路为什么在小游戏里断了要理解这个问题得先知道标准WebGL是怎么处理输入的。Unity导出成WebGL之后页面里其实会动态插入一个隐藏的HTMLinput或textarea元素。当你点击InputFieldUnity的运行时会把浏览器焦点切到这个隐藏元素上浏览器检测到焦点变化就弹出系统软键盘用户敲的字符通过这个元素的input事件回传给Unity再由Unity写进InputField的text里。整套流程依赖的是真实DOM和浏览器的焦点管理机制。而微信小游戏不是浏览器页面。它运行在微信客户端内部的JavaScript虚拟环境里没有DOM没有HTML元素没有浏览器焦点这套东西。你导出的小游戏代码里Unity那套插入隐藏input、切换焦点的逻辑自然就完全失效了。点击事件能收到因为触摸事件是小游戏自己模拟的但把焦点交给一个不存在的DOM元素这一步就断在这里了。这就是为什么很多人发现InputField的onValueChanged能触发、点击也响应就是键盘不弹。因为断点根本不在UI层而在Unity的输入模块和浏览器DOM之间的那层桥。微信小游戏官方也清楚这一点所以单独提供了一套自己的键盘调用接口把弹键盘这件事从浏览器手里接管过来。你要做的就是把InputField和这套接口对接上用微信的键盘状态去驱动Unity的文本显示。理解了这个本质后面的方案就顺理成章了不要指望InputField自己弹键盘而是拦截点击事件主动调用微信的键盘接口再把键盘返回的内容手动写回InputField。2. 微信小游戏的输入接口到底怎么用微信小游戏提供了一套键盘相关的接口Unity侧通过官方的小游戏适配SDK也就是常见的WX-WASM-SDK这类转换工具不同版本命名略有差异下面的接口名以主流SDK为准来调用。核心就几个WX.ShowKeyboard、WX.HideKeyboard、WX.UpdateKeyboard以及三个回调WX.OnKeyboardInput、WX.OnKeyboardConfirm、WX.OnKeyboardComplete。另外还有一个高度变化回调WX.OnKeyboardHeightChange做避让必须要用。2.1 ShowKeyboard 系列的参数逐个说清WX.ShowKeyboard的参数不多但每个都影响实际体验必须弄清楚。defaultValue键盘弹起时预填的内容。一般传当前InputField里已有的text用户接着改不然会出现点进去内容空了的诡异现象。maxLength允许输入的最大长度。注意这里传的是整数不是InputField的characterLimit字符串。传小了用户打不进去传大了不生效最好跟InputField的设置保持一致。multiple是否是多行输入。false是单行true是多行。多行的行为在不同基础库版本上有差异后面单独讲。confirmType键盘右下角那个键显示什么。常见值有done、send、search、next、go。做搜索框就传search做聊天输入就传send别小看这个细节它直接影响用户对输入框功能的心智预期。confirmHold点确认键之后键盘是否保持不收起。默认false也就是点一下确认就收键盘。做连续输入或者聊天框一般也希望收起除非做多标签连续输入。举个实际调用长这样先感受一下var option new ShowKeyboardOption { defaultValue inputField.text, maxLength 30, multiple false, confirmType done, confirmHold false }; WX.ShowKeyboard(option);2.2 CreateInput / CreateTextarea 的另一条路除了ShowKeyboard这套部分SDK版本还提供了WX.CreateInput和WX.CreateTextarea也就是在小游戏上层创建一个原生输入组件返回一个对象你可以调用它的show、hide还能监听它的输入事件。这条路的好处是输入框是真实的原生控件输入法行为更接近系统原生中文拼音候选、光标移动、选择文本这些体验都会更好。但它的代价也明显它是一个浮在游戏画面之上的原生层位置、大小、样式都要通过参数或后续调用来控制跟Unity的UI对不齐是常有的事而且它在不同机型上位置偏移、层叠顺序的问题比ShowKeyboard更多。我个人建议简单输入登录、改昵称、搜索关键词优先用ShowKeyboard因为它可控、问题少只有当用户需要长文本、多行、复杂编辑体验时才考虑CreateTextarea这种原生控件的方案。注意这两套接口不要同时用。我见过有项目既在点击时调ShowKeyboard又用CreateInput创建了一个隐藏输入框结果两个输入源打架输入内容重复、光标乱跳排查了半天。选定一条路走到底。3. 手把手改造 InputField从点击到回填的完整链路光知道接口不够关键是怎么把它和Unity的InputField、TMP_InputField接起来。核心思路一句话接管InputField的交互让微信键盘成为唯一的输入来源Unity端只负责显示和存储文本。下面按顺序把整条链路写出来。3.1 组件挂载与SDK初始化时机第一步别再用InputField默认的交互逻辑去处理。最稳妥的做法是给需要输入的地方单独挂一个适配脚本脚本里持有对InputField的引用同时处理SDK的初始化。SDK初始化有个坑要提前说WX.InitSDK是异步的回调没回来之前调用键盘接口可能无效或者报错。所以一定要把键盘回调的注册放在InitSDK的回调里而不是Awake里直接注册。我见过不少回调不触发的问题根源就是注册提前了。using UnityEngine; using UnityEngine.UI; using WeChatWASM; public class WXInputAdapter : MonoBehaviour { [SerializeField] private InputField inputField; private bool _keyboardReady; void Awake() { if (inputField null) inputField GetComponentInputField(); } void Start() { WX.InitSDK((code) { WX.OnKeyboardInput(OnKeyboardInput); WX.OnKeyboardConfirm(OnKeyboardConfirm); WX.OnKeyboardComplete(OnKeyboardComplete); WX.OnKeyboardHeightChange(OnKeyboardHeightChange); _keyboardReady true; Debug.Log(WX SDK 初始化完成, code code); }); } }这里把回调都挂上后续三个回调分别处理输入中、点确认、键盘收起。三个都要处理缺一个都会留下状态残留的隐患。3.2 点击唤起、输入回填、确认收尾点击唤起很简单给InputField加一个点击区域或者直接监听它的onPointerClick。注意不要依赖InputField自己的选中逻辑去弹键盘那个在微信小游戏里是不生效的。你可以用一个透明的Button盖在InputField上点击时调ShowKeyboard。public void OnInputClicked() { if (!_keyboardReady) return; var option new ShowKeyboardOption { defaultValue inputField.text, maxLength 20, multiple false, confirmType done, confirmHold false }; WX.ShowKeyboard(option); }回填逻辑是整个改造里最关键的。用户每敲一个字符微信会通过OnKeyboardInput推给你一个结果对象里面带着当前整个输入框的完整文本注意是完整值不是增量。你把它写回InputField的text就行private void OnKeyboardInput(OnKeyboardInputListenerResult res) { inputField.text res.value; // 主动触发一次校验/联动逻辑 inputField.onValueChanged.Invoke(res.value); } private void OnKeyboardConfirm(OnKeyboardConfirmListenerResult res) { inputField.text res.value; inputField.onEndEdit.Invoke(res.value); WX.HideKeyboard(new HideKeyboardOption()); } private void OnKeyboardComplete(OnKeyboardCompleteListenerResult res) { inputField.text res.value; }有一点要注意回填的时候会触发InputField自身的onValueChanged如果你的业务在onValueChanged里做了文字过滤、字数统计可能会被触发两次一次是手动Invoke一次是赋text触发。稳妥的做法是别手动Invoke改在赋值之后自己调业务方法或者干脆只用一个入口。这个坑很隐蔽表现为统计数字翻倍不仔细看很难发现。3.3 键盘高度变化与界面避让移动端最烦人的就是键盘弹起来把输入框挡住了。微信给了WX.OnKeyboardHeightChange会告诉你键盘高度你可以据此把输入框往上顶。private void OnKeyboardHeightChange(OnKeyboardHeightChangeListenerResult res) { float heightInPixel res.height; // 把像素高度换算成Unity的UI单位 float uiHeight heightInPixel / 2f; // 假设缩放系数为2 inputRootRect.anchoredPosition new Vector2(0, uiHeight); }这里有两个细节。第一微信返回的高度单位是物理像素你换算成Unity的UI单位时要考虑Canvas scaler的缩放系数不能直接拿来用否则顶起的距离会偏大或偏小。第二键盘高度变化是动态的——安卓上键盘可能带候选词条高度会变用户切换输入法高度也会变。所以不要只在弹起时算一次要在回调里每次都更新位置并且做好边界处理别把UI顶出屏幕。如果做的是聊天框这种贴在底部的输入条建议直接根据键盘高度做lerp过渡避免位置突跳。4. 踩坑实录那些工具里好好的、真机上翻车的场景改造完之后本地跑通不代表真机没问题。这个环节几乎是我们踩坑最密集的地方单独拎出来说。4.1 常见问题速查表下面这张表是我陆陆续续记下来的遇到问题先对照着查能省掉很多重复劳动。现象大概率原因处理方式点击无任何反应SDK未初始化完成、键盘接口提前调用把调用放进InitSDK回调后键盘弹出但内容不进没监听OnKeyboardInput或没回填text补上回填逻辑内容进了一半就断回调被多次注册事件重复初始化只做一次做好去重字数统计翻倍赋值触发onValueChanged 手动Invoke只保留一个触发入口键盘遮挡输入框没做高度避让监听高度变化并顶起UI真机无键盘、工具正常开发者工具模拟不了原生键盘一律以真机为准iOS顶部/底部错位安全区未适配结合安全区调整布局多行输入光标错位用了showKeyboard多行模式改用CreateTextarea方案键盘收起画面残留没有监听Complete做清理在Complete里复位状态输入法状态残留频繁Show/Hide冲突加节流避免短时间反复调用这张表里第一行和第六行是最容易耽误时间的。SDK初始化那个坑本质上是个时序问题开发者工具模拟不了键盘是因为工具里根本没有原生的系统键盘它只是模拟了接口调用不能反映真实输入法的行为。所以我的习惯是输入相关的功能一律真机验证开发者工具只用来检查逻辑通不通。4.2 几个容易被忽略的细节除了表里那些还有几个我印象比较深的细节。一个是被动收起键盘的场景。用户按了物理返回键、或者切到后台再回来键盘可能已经收了但你本地还记着键盘是弹起状态导致下次点击调不起键盘。解决方式是在OnKeyboardComplete里统一把状态复位不管是什么原因收的键盘都走同一个清理入口。另一个是多个输入框共用一个键盘。如果你的页面有两个以上输入框一定要注意当前聚焦的是哪个回填的时候别写错对象。我们的做法是维护一个当前活跃输入框的引用点击谁就把谁设成活跃回调统一往这个引用里写。这个模式很干净也避免了多个适配脚本各自注册回调造成的混乱。还有中文输入法的问题。安卓上某些输入法在拼拼音的过程中OnKeyboardInput给的是拼音选字之后才是最终汉字。如果你在InputField的onValueChanged里实时做了敏感词过滤或者搜索联想很可能在拼音阶段就触发了体验会很怪。这种情况建议在confirm之后再做重逻辑输入过程中只做轻量的显示。5. 更进一步自建输入面板与多行输入的处理单行输入用上面这套基本能覆盖。但实际项目里多行输入、自定义样式的输入框需求很常见值得单独聊聊。5.1 单行够用多行怎么办前面提过WX.ShowKeyboard的multiple参数在多行场景下不同基础库版本表现不一致。有的版本多行了但回车换行不生效有的版本光标跑到别处还有的干脆把内容截断。我踩过的坑是在某个版本上多行输入时光标总是在开头用户打字全插在最前面。遇到多行需求我的经验是优先考虑CreateTextarea它本质上是一个原生textarea组件多行编辑、换行、光标移动都接近系统原生稳定性明显好于showKeyboard的多行模式。代价就是它浮在游戏画面之上样式受限你需要接受它不能完全跟着Unity的UI走。如果要做的输入界面本身就不复杂比如一个评论区、一个反馈框其实可以用全屏遮罩原生textarea的方式来掩盖层叠问题用户根本感知不到它在Unity之外。如果坚持要用showKeyboard做多行那至少要准备一个降级逻辑检测输入内容是否包含换行符、渲染时是否正确换行不通过就走原生方案兜底。5.2 仿输入框槽位样式的一些思路有些产品会想要类似那种一个词一个槽位的输入框样式看起来像是分开的格子其实是整体输入。这种在小游戏里做的话有个取巧的思路视觉上用多个格子显示逻辑上还是单个输入。用户点击任意格子都触发同一个ShowKeyboard回填的时候把文本按字符拆开分别塞进对应格子的Text里光标定位在你手动算出来的当前字符位置。好处是实现简单不用真正做多输入框坏处是要自己处理复制粘贴、退格删除这些边界情况字符数超过槽位数量时也要有策略截断或者滚动。做这类样式的时候我一般会把显示层和数据层彻底分开数据层就一个完整的字符串显示层负责把它切成格子渲染。这样无论输入法怎么输入只要保证数据层是对的显示层的渲染逻辑就是纯函数测试起来也方便。做这类自定义输入时字号、字色、行高在微信原生键盘上是不生效的——因为它用的是系统键盘样式你改不了。真正需要自定义键盘样式的场景得等小游戏开放对应的能力或者接受用系统键盘这个前提。我个人在折腾Unity微信小游戏的输入框这件事上最大的体会就是不要用Unity原生的思路去想象它的行为它本质上是一个WebGL被剪掉了输入模块、改由平台接口接管的环境。你只要把心智模型从InputField自己弹键盘切换成我主动调平台接口、手动回填文本剩下的坑就都是有迹可循的工程问题。另外一个建议是输入这类强交互的功能越早真机测越好别等到功能做完了才发现键盘调不起来那时候改动的面就大了。如果项目里输入场景比较多值得在早期就抽一个统一的输入适配层出来把所有输入框都走同一个入口后面对齐和排查都会轻松很多。还有个小技巧给每个输入框在真机上都点一遍特别是模拟弱网和切换输入法的情况能提前发现不少只在特定机型上冒出来的怪问题。