1. 先把问题定死小游戏里缺的不是输入框 UI是宿主键盘先说一个我见过太多次的场景项目在 Unity 编辑器里跑得好好的导出到微信小游戏登录界面的账号输入框点下去——光标出来了或者连光标都没有软键盘死活不弹。然后开始怀疑人生是不是 TMP 的问题、是不是字体图集的问题、是不是 Raycast Target 被挡住了、是不是 EventSystem 掉了。折腾两三个小时之后发现UI 一点毛病都没有那个输入框画得好好的它的 RectTransform、Text 组件、Caret 全都在正常工作。真正缺的东西不在 Unity 这边而在运行环境那边——宿主根本没有把软键盘的能力交给你。Unity 微信小游戏里输入框调不起来这个现象本质上是一个平台能力缺失问题不是组件配置问题。搞清楚这一点后面所有的方案选择都会变得非常清晰。1.1 浏览器版 WebGL 输入框是怎么把键盘叫出来的要理解小游戏为什么不行得先知道浏览器版 WebGL 为什么行。Unity 的 WebGL 构建把整个游戏渲染到一张 canvas 上。canvas 本身是画布它不接收文字输入也不参与输入法的焦点管理。所以 uGUI 的 InputField 和 TMP_InputField 在 WebGL 平台上实际上依赖平台层额外创建的一个隐藏 DOM 元素——通常是一个position: fixed、opacity: 0、尺寸极小的input或者textarea。当输入框被激活时点击、调用ActivateInputField平台层会对这个隐藏元素调用focus()。浏览器收到焦点之后才会把移动端的软键盘弹出来。用户敲的字符通过input事件和composition事件回传再被塞进 Unity 的Input.inputString和Input.compositionString这两个通道InputField 从这两个通道里取字符来更新显示。所以能不能弹键盘这件事在浏览器上取决于三个条件同时成立有 DOM 元素、能 focus 成功、浏览器愿意为它弹出软键盘。桌面浏览器天然不需要软键盘所以你在编辑器或者 PC 浏览器里测永远测不出这个问题——这也是很多人白白浪费一天的原因。1.2 小游戏运行时把这一层整个抽掉了微信小游戏的 JS 运行环境是一个被大幅裁剪过的运行时Android 上基于 V8iOS 上基于 JavaScriptCore。它给你的东西是一张 canvas、一套wx.*接口、一套定时器和事件机制。它不给你的是document、window.document、HTMLInputElement、selectionStart、execCommand、focus()触发输入法这一整套浏览器行为。链条的第一环就断了。你没法创建 DOM 输入元素就算你在 jslib 里硬造一个 JS 对象出来focus()也只是一个普通方法的调用不会有任何原生行为跟在后面。结论非常直接任何依赖 DOM 聚焦来唤起软键盘的方案在小游戏环境里都不可能工作。这不是 Unity 的 bug也不是适配插件打包没打对是运行环境本身就不提供这个能力。宿主把键盘能力收回去之后换了一种形式重新暴露给开发者wx.showKeyboard/wx.hideKeyboard负责开关wx.onKeyboardInput/wx.onKeyboardConfirm/wx.onKeyboardComplete负责把结果抛回来。它给你的是整串文本加上几个开关——最大长度、是否多行、完成键文案、是否保持键盘。光标位置、选区范围、输入法候选词这些统统不归你管。这一点决定了后面所有实现细节的形态。1.3 两分钟确认根因的三个验证动作不要凭感觉判断用三个动作把结论钉死在小游戏开发者工具的 Console 里依次执行typeof document、typeof wx、typeof wx.showKeyboard。第一个是undefined后两个是function定性完成。在 Unity 侧打一行Debug.Log(TouchScreenKeyboard.isSupported)。在 WebGL 和小游戏平台上这个值基本是false。也就是说你可能想到的TouchScreenKeyboard.Open这条路调用之后什么都不会发生连报错都不会有——这是新手最常见的第一个死胡同。如果项目同时有网页版把同一个包用浏览器打开输入框正常。这就直接反证了UI 有问题这个假设。提示确认根因之后就不要再往输入框的配置项上花时间了。shouldHideMobileInput、Character Limit、Rich Text、Content Type、Line Type 这些参数在小游戏里对能不能弹出键盘没有任何影响。它们的意义只在浏览器端。2. 三条技术路线的取舍为什么最后都收敛到宿主键盘桥接根因明确之后摆在面前的路其实只有三条。我把它们的收益和代价摊开讲你可以直接对着自己的项目做判断。2.1 路线 A给运行环境塞一个假 DOM这条路的思路是既然缺 DOM那我就在 jslib 里补一个document补一个HTMLInputElement然后在需要的时候focus()它。听起来很聪明实际走不通。小游戏运行时没有浏览器内核也没有输入法管线更不会去渲染一个 DOM 元素。你造出来的对象在宿主眼里就是一个普通的 JavaScript 对象focus()是个自定义方法调用它不会触发任何原生行为。宿主不认识这个输入框自然也不会为它弹出键盘。这条路唯一有一点点空间的场景是在小程序的web-view组件里加载一个真正的网页——那里面有完整浏览器环境Unity WebGL 的输入逻辑反而能跑。但那是另一个产品形态不是小游戏。2.2 路线 B把 Unity 输入框降级成显示层键盘交给宿主这是真正可行的方案核心思路一句话TMP_InputField 只负责画文字和画光标不再负责采集输入。具体流程是用户点击输入框我们不指望 Unity 自己弹键盘而是直接调用宿主键盘接口宿主键盘的每一次输入回调里我们把整串文本写回 InputField 并同步光标用户点完成键时触发提交逻辑。好处很明显改造量小视觉和交互跟原来基本一致多语言、自定义字体、对齐方式、Placeholder 这些原有的东西全都还能用。代价也清楚受宿主键盘能力限制——拿不到选区、拿不到真实光标位置、中文输入法预编辑阶段可能拿到的是拼音串、同一时刻整个游戏只能有一个键盘。2.3 路线 C连键盘一起自绘自己画一个九宫格或者全键盘 UI。除了极少数需要严格控制输入内容的场景比如只允许输入数字的房间号、只允许选字母的兑换码这条路基本不划算。中文输入怎么办长按连击怎么办复制粘贴怎么办系统级联想词怎么办这些用户已经形成肌肉记忆的东西你自己做一遍体验只会更差。玩家不会因为你的键盘长得好看就原谅它打不出中文。2.4 三条路线的横向对比方案能否唤起系统键盘改造量光标与选区中文输入法结论A 伪造 DOM否大名义上有实际无效无放弃B 宿主键盘桥接是中等需要自己维护近似行为完整可用推荐C 自绘键盘否不是系统键盘大全部自己实现需要自建词库仅特殊场景选 B 还有一个容易被忽略的理由它把输入能力这件事从 Unity 侧彻底解耦了。以后宿主升级接口、增加新参数比如新增一种 confirmType你只需要改桥接层业务层的输入框组件完全不用动。反过来如果选了 C宿主任何一次能力升级你都吃不到还得自己维护一套输入法。3. 桥接层的完整实现从一次点击到文字落进 InputField这一节是实操主体我会把一个可用的组件完整写出来并把每一段的意图讲清楚而不是丢一堆代码让你自己猜。3.1 前置检查清单动手之前先确认四件事少一件都可能在真机上翻车插件版本小游戏需要官方那套 WebGL 小游戏适配插件。确认版本早期版本并没有把键盘接口封装成 C# 对象你需要自己写 jslib。判断方法很简单在 C# 里打WX.看能不能自动补全出ShowKeyboard出不来就是版本不够。宏定义适配插件在打包时会加上自己的宏。业务代码里要用#if UNITY_WEBGL !UNITY_EDITOR或者插件宏包一层保证编辑器里还能正常跑编辑器里我们走 Unity 自己的输入方便调试。Input SystemPlayer Settings 里的 Active Input Handling 建议保持 Input Manager (Old) 或者 Both。切到纯 New Input System 之后WebGL 平台的键盘事件通道容易出各种奇怪问题。而我们的输入本来就不走 Unity 的输入事件没必要冒这个险。字体图集输入内容里如果可能出现生僻字字体图集要留够。否则会出现文字确实写进去了但显示成一个方块然后你又得花半天排查是回写逻辑的问题还是字体的问题。3.2 插件已暴露接口时的 C# 实现下面这个组件可以直接用我把关键点用注释标出来using System; using TMPro; using UnityEngine; #if UNITY_WEBGL !UNITY_EDITOR using WeChatWASM; #endif [RequireComponent(typeof(TMP_InputField))] public class MiniGameInputField : MonoBehaviour { [SerializeField] private TMP_InputField field; [SerializeField] private int maxLength 20; [SerializeField] private bool multiple false; [SerializeField] private string confirmType done; [SerializeField] private bool confirmHold false; public event Actionstring Submitted; private bool _bound; // 监听是否已经注册 private bool _showing; // 键盘是否处于弹出状态 private void Reset() field GetComponentTMP_InputField(); private void Awake() { if (!field) field GetComponentTMP_InputField(); field.shouldHideMobileInput true; field.onSelect.AddListener(_ Show()); field.onDeselect.AddListener(_ Hide()); } private void OnDestroy() Unbind(); private void Bind() { if (_bound) return; _bound true; #if UNITY_WEBGL !UNITY_EDITOR WX.OnKeyboardInput(OnKeyboardInput); WX.OnKeyboardConfirm(OnKeyboardConfirm); WX.OnKeyboardComplete(OnKeyboardComplete); WX.OnKeyboardHeightChange(OnKeyboardHeightChange); #endif } private void Unbind() { if (!_bound) return; _bound false; #if UNITY_WEBGL !UNITY_EDITOR WX.OffKeyboardInput(OnKeyboardInput); WX.OffKeyboardConfirm(OnKeyboardConfirm); WX.OffKeyboardComplete(OnKeyboardComplete); WX.OffKeyboardHeightChange(OnKeyboardHeightChange); #endif } }这里有几个设计决定值得解释。为什么在onSelect里触发弹出因为这样能复用 Unity 原有的交互逻辑点击输入框、Tab 切换、代码里调ActivateInputField都会走到同一个入口行为一致。为什么用_bound标志位而不是直接靠OnEnable/OnDisable因为节点可能被反复 SetActive或者 UI 面板被对象池复用注册累积之后一次输入会触发多次回调表现为打一个字出现两个。标志位是最省事也最可靠的挡板。弹出和收起的实现public void Show() { #if UNITY_WEBGL !UNITY_EDITOR Bind(); // 关键先收干净再弹。宿主同一时刻只允许一个键盘 // 上一次没收到位的话show 会直接 fail。 if (_showing) { WX.HideKeyboard(new HideKeyboardOption()); } _showing true; WX.ShowKeyboard(new ShowKeyboardOption { defaultValue field.text ?? string.Empty, maxLength maxLength, // 必须显式给且和 Character Limit 对齐 multiple multiple, confirmType confirmType, // done / next / search / go / send confirmHold confirmHold, success _ { }, fail res { _showing false; Debug.LogWarning([MiniGameInputField] showKeyboard fail: res.errMsg); } }); #else field.ActivateInputField(); #endif } public void Hide() { #if UNITY_WEBGL !UNITY_EDITOR if (!_showing) return; _showing false; WX.HideKeyboard(new HideKeyboardOption()); #else field.DeactivateInputField(); #endif }一定要注意fail回调里的那行日志。真机上出问题的时候showKeyboard绝大多数情况下是有返回失败的只不过你没接fail所以看起来像什么都没发生。把errMsg打出来排查效率能提升一个数量级。回写逻辑#if UNITY_WEBGL !UNITY_EDITOR private void OnKeyboardInput(OnKeyboardInputListenerResult res) { WriteBack(res.value, false); } private void OnKeyboardConfirm(OnKeyboardConfirmListenerResult res) { WriteBack(res.value, true); // confirmHold 为 false 时确认后键盘会自行收起 // complete 回调会随后到达在这里先把状态位放开。 _showing false; Submitted?.Invoke(field.text); field.onSubmit?.Invoke(field.text); } private void OnKeyboardComplete(OnKeyboardCompleteListenerResult res) { _showing false; } private void OnKeyboardHeightChange(OnKeyboardHeightChangeListenerResult res) { // 这里只缓存高度不要在回调里直接做重布局 MiniGameKeyboardLayout.SetHeight(res.height); } #endif private void WriteBack(string value, bool force) { value ?? string.Empty; if (!force field.text value) return; field.SetTextWithoutNotify(value); field.caretPosition value.Length; field.stringPosition value.Length; field.ForceLabelUpdate(); }如果你的插件版本里回调结果类的字段名不是value别猜直接Debug.Log(JsonUtility.ToJson(res))打一次就能看到真实结构。不同版本的字段命名确实有过变化。3.3 插件版本太旧时自己写 jslib 桥有些项目因为 Unity 版本或者历史原因用的插件比较老没有暴露键盘接口。这时候可以自己补一层代码量比想象中小得多// Assets/Plugins/WebGL/WXMiniGameKeyboard.jslib mergeInto(LibraryManager.library, { WXMG_RegisterKeyboard: function (goPtr, inputMethodPtr, confirmMethodPtr, completeMethodPtr) { var go UTF8ToString(goPtr); var mInput UTF8ToString(inputMethodPtr); var mConfirm UTF8ToString(confirmMethodPtr); var mComplete UTF8ToString(completeMethodPtr); wx.onKeyboardInput(function (res) { SendMessage(go, mInput, res.value || ); }); wx.onKeyboardConfirm(function (res) { SendMessage(go, mConfirm, res.value || ); }); wx.onKeyboardComplete(function (res) { SendMessage(go, mComplete, res.value || ); }); }, WXMG_ShowKeyboard: function (defaultValuePtr, maxLength, multiple, confirmTypePtr, confirmHold) { wx.showKeyboard({ defaultValue: UTF8ToString(defaultValuePtr), maxLength: maxLength, multiple: !!multiple, confirmType: UTF8ToString(confirmTypePtr), confirmHold: !!confirmHold }); }, WXMG_HideKeyboard: function () { wx.hideKeyboard({}); } });C# 侧声明#if UNITY_WEBGL !UNITY_EDITOR using System.Runtime.InteropServices; [DllImport(__Internal)] private static extern void WXMG_ShowKeyboard(string defaultValue, int maxLength, bool multiple, string confirmType, bool confirmHold); [DllImport(__Internal)] private static extern void WXMG_HideKeyboard(); [DllImport(__Internal)] private static extern void WXMG_RegisterKeyboard(string go, string onInput, string onConfirm, string onComplete); #endifSendMessage在这个 jslib 环境里是可用的适配插件自己也是靠它和 JS 层通信。接收消息的脚本必须挂在场景里一个常驻的 GameObject 上名字和字符串参数要对得上否则消息发出去就静默丢失了——这类问题没有报错只能靠日志确认。还有两个必须遵守的硬性约定jslib 文件必须放在Assets/Plugins/WebGL/目录下扩展名必须是.jslib文件换过位置或者改过名字之后回到 Unity 里右键 Reimport 一次再打包。3.4 回写文本的三种写法以及各自的副作用回写这个动作看起来最简单实际上最容易埋雷。三种写法我都用过field.text value;—— 最省事但它会触发onValueChanged。如果你在这个回调里做了实时校验转大写、过滤非法字符、限制字符类型就会形成回环你改文本 → 回调又改文本 → 你又改回去。表现出来就是打字的时候光标乱跳、字被吃掉、删不掉。要么加一个_ignoreNext布尔挡一下要么直接换下一种写法。field.SetTextWithoutNotify(value);—— TMP 专有不触发onValueChanged。这是我默认的选择。代价是你得在外部手动调用自己的校验逻辑不能再指望组件回调帮你触发。自己算差值只插入新增字符 —— 适合需要精细控制光标和防注入的场景。思路是先算公共前缀定位这次插入或删除的位置private int DiffInsertIndex(string oldText, string newText) { int i 0; int min Mathf.Min(oldText.Length, newText.Length); while (i min oldText[i] newText[i]) i; return i; }但要提醒一句这个方法只能推测插入点。中文输入法预编辑阶段会不断给出中间状态差分会误判所以只在onKeyboardConfirm之后用比较稳。另外注意 API 差异TMP_InputField 用caretPosition和stringPosition老的 uGUI InputField 用的是caretPosition配合selectionAnchorPosition、selectionFocusPosition。写混了不会报错只是光标不听话。4. 键盘弹起之后的麻烦光标、多行、高度与平台差异键盘能弹出来只是第一步真正消耗时间的是弹出之后的细节。4.1 光标为什么永远停在末尾因为宿主只给你整串文本不给你光标位置。你在onKeyboardInput里每次重设文本光标就只能落到末尾。单行输入毫无影响用户根本感知不到。但多行输入就明显了用户想点中间某处插入一个字结果发现自己插不了。两个可以接受的应对方式一是多行输入时不要在onKeyboardInput里重置光标只在确认时回写一次二是用上面的差分方法推算插入位置把光标定到插入点。后者在中文输入法下会有抖动所以只在确认阶段用中间阶段不碰光标。还有一个很隐蔽的现象如果用户删到空串而你的WriteBack里写了if (!force field.text value) return;这种短路判断空串和空串相等会直接跳过看起来没问题但如果此时 Placeholder 的显示逻辑和text状态不同步就会出现占位符和光标同时显示的怪样子。稳妥做法是回写之后显式调一次field.ForceLabelUpdate()。4.2 多行、confirmType 与 confirmHold 的组合这三个参数经常被随便填结果体验很差。按场景对齐会好很多场景multipleconfirmTypeconfirmHold说明昵称 / 账号falsedonefalse单行一般限制 12 到 16 个字符注意中英文混排的显示宽度差异聊天输入falsesendtrueconfirmHold 保持键盘方便连续发送此时需要自己调 Hide搜索框falsesearchfalse完成键文案直接影响用户理解别全用 done个性签名truedonefalse多行时换行来自键盘的换行键注意 Unity 侧 Line Type 要设为 Multi Line Newline关于maxLength有一个特别容易踩的坑它是必填参数不给的话宿主会用默认值通常是 140。如果它和 InputField 的 Character Limit 不一致就会出现两种诡异现象——键盘允许打但 Unity 截断或者明明还能输入但键盘不给打了。两边必须对齐我一般是把同一个字段暴露给两个地方而不是各写各的。4.3 键盘高度变化与 UI 上移的换算WX.OnKeyboardHeightChange给你的是键盘高度单位是屏幕像素。要拿它推动 Unity 的 UI中间需要换算一次// keyboardHeightPx: 宿主回调给的高度 // pixelRatio: WX.GetSystemInfoSync().pixelRatio // canvas.scaleFactor: Canvas Scaler 的缩放系数 float uiOffset keyboardHeightPx / pixelRatio / canvas.scaleFactor;pixelRatio从系统信息里拿一次缓存起来不要每帧取。scaleFactor从 Canvas 组件上读。换算完之后用插值把它应用到输入框所在面板的 RectTransform 上别硬设否则键盘弹出的瞬间整个面板会啪地跳一下。更重要的是不要在OnKeyboardHeightChange回调里直接做重布局这个回调触发频率不低在里面做布局会直接掉帧。正确做法是回调里只缓存目标高度在Update里做 lerp。还有一个坑值说iOS 上键盘是覆盖在 canvas 之上的浮层游戏画面本身不会改变尺寸所以必须自己移。Android 上部分机型会压缩可见区域如果你既移了 UI、又赶上系统触发了一次 resize视觉上就会移两次。用一个标志位记录这次键盘弹出是否已经响应过 resize能解决大部分双倍位移。4.4 iOS 与 Android 的实测差异下面这张表是我在几个项目里反复验证过的差异但请把它当参考而不是结论——机型、输入法、基础库版本、微信版本任何一个变了行为都可能不一样。真机验证永远优先。行为iOSAndroid键盘呈现方式覆盖在 canvas 之上的浮层部分机型压缩可见区域键盘高度回调触发稳定部分机型不触发或者只在首次触发输入法上屏时机onKeyboardInput 给的基本是上屏后的中文部分输入法会把拼音预编辑阶段也推过来confirmHold 支持支持良好部分机型点完成键仍会收起键盘对调用时机的敏感度更敏感跨帧调用容易失败相对宽松这些差异直接影响你的实现策略。比如因为第三行的那条差异你的实时校验逻辑就必须写得足够宽容不能假定拿到的永远是最终文本。因为最后一行那条差异如果你的Show()是在一个异步回调或者协程里被调用的最好准备一个提前到触摸同一条调用链里触发的备选版本。5. 五个真实排错现场从工具里好好的到真机没反应前面讲的是正常路径这一节讲的是事故现场。我把踩过的都列出来你可以直接对着症状找。5.1 开发者工具里一切正常真机不弹这是最经典的一个。开发者工具跑在 PC 上wx.showKeyboard落到的是电脑键盘行为跟真机完全不同。工具里测通不代表任何事。排查顺序我固定按这个来第一步真机调试并打开日志面板把showKeyboard的fail回调里的errMsg打出来。九成的答案是这里有内容而不是没有回调。第二步如果errMsg里出现 keyboard is showing 之类的字样说明上一次没收干净——每次 show 之前先 hide并且维护状态位。第三步如果连 fail 都没有检查调用是不是落在了跨帧的异步回调里试着把调用挪回到用户触摸的同一条调用链上再测一次。第四步确认小游戏后台设置的基础库版本不至于太旧接口不完整的情况下表现就是没有任何反应。5.2 键盘弹出来了字却进不去三种典型原因。第一种是回写成功了但显示没刷新TMP 一般不会老的 uGUI InputField 有时候需要显式调ForceLabelUpdate()。第二种是onValueChanged里的校验逻辑把字吃掉了特别是用char.IsLetterOrDigit做白名单的时候——中文属于 Letter 能过关但 emoji、部分标点、特殊符号会被静默丢弃排查时先加日志打印被丢掉的字符。第三种是场景里有两个输入框抢焦点onSelect里先调了一次ActivateInputField又触发了Show()两路回写互相覆盖表现是字进去又没了。5.3 第二次点击没反应或者一口气弹两次这个问题的根源基本都在监听注册上。Awake或者OnEnable里注册监听但节点被反复 SetActive、或者场景重载监听就累积了。累积之后一次onKeyboardInput会触发 N 次表现是最后一个字符变成两个或者文本看起来在闪烁。另一种情况是状态位没复位。iOS 上点完成键收起键盘时如果你没有注册onKeyboardComplete_showing会一直保持true。下一次点击时因为状态位是 true会先 Hide 再 Show中间产生一次肉眼可见的闪动网络慢的时候甚至真的弹不出来。还有一种输入框本身是个可点击区域外面还包了一层 Button 也绑了onClick调Show()一次点击触发两遍第二遍必然收到 fail。这种问题查起来很快但前提是你想到了去看fail的日志。5.4 打包之后才坏代码剥离与宏定义这类问题在编辑器里怎么测都测不出来一打包就废。首先是 Managed Stripping Level。调高之后某些监听结果类只有字段没有方法的 POCO的字段可能被剥掉表现为回调能进但res.value永远是 null或者整个回调静默不触发。对策是在Assets/link.xml里保留相关程序集linker assembly fullnameWeChatWASM preserveall/ assembly fullnameAssembly-CSharp preserveall/ /linker其次是宏定义分支。用#if UNITY_EDITOR包起来的代码在编辑器里跑得很好真机走的是另一条分支如果那条分支忘了写或者写错了就会出现编辑器好好的真机什么都没发生。这个错误没有编译警告只能靠真机测试发现。最后是 jslib 的放置。必须在Assets/Plugins/WebGL/下扩展名必须是.jslib文件改动之后要 Reimport 一次再打包。放在 Plugins 根目录下某些情况下会被当成普通文本资源处理链接阶段直接找不到符号。5.5 中文候选词阶段拿到的是拼音串这条单独拎出来说因为它会以一种看起来逻辑没错但结果就是不对的方式坑人。如果你在onKeyboardInput里做实时搜索、敏感词过滤、或者字数限制会在 iOS 上观察到一种现象用户还在输拼音你的搜索结果已经在跟着拼音字母变了或者字数统计把拼音字母也算进去了用户还没选词提示就已经红了。稳妥的做法是把处理分层onKeyboardInput只负责把文字显示出来不做任何业务判断所有校验、搜索、提交逻辑全部放到onKeyboardConfirm和onKeyboardComplete里。这会让实时搜索这类需求在小游戏上打点折扣但比起错误结果用户更能接受稍微慢半拍的反馈。6. 可以直接抄走的检查清单以及几条我踩出来的经验每次上线前我会把下面这张清单过一遍。它不含任何高深的东西但每一条都对应过一次真实的线上问题。编号检查项判断方式1环境确认Console 里typeof document为 undefined2方案确认走的是宿主键盘接口不是等 Unity 自己弹3键盘状态show 之前 hide 干净状态位正确复位4长度对齐maxLength 与 Character Limit 数值一致5监听唯一只注册一次节点销毁时注销6回写方式使用 SetTextWithoutNotify避免 onValueChanged 回环7光标同步回写后同步 caretPosition 与 stringPosition8高度适配键盘高度做了 pixelRatio 与 scaleFactor 换算且是插值移动9真机验收真机、体验版、正式版各跑一次不只看开发者工具10剥离配置link.xml 保留了回调相关程序集除了清单还有几条经验我认为比技术细节更重要。把输入框封装成一个统一组件全局只允许存在一个键盘。用一个静态引用记录当前聚焦的输入框切换页面、切换输入框的时候先把上一个收干净。这样第二次点击没反应两个输入框互相抢字这类问题会从源头消失而不是靠一个个补丁去堵。不要在onSelect里无脑触发弹出。onSelect也可能被代码调用比如进入页面自动聚焦、或者列表滚动时的误触。如果你的业务里有自动聚焦的需求最好用一个显式的点击事件来触发弹出把被选中和要弹键盘这两件事分开。有些需求根本不值得做桥接。如果只是想收集一句话输入——比如举报理由、修改昵称、填写一句留言——宿主提供的showModal带可编辑模式可以直接弹出一个原生输入框拿到结果省掉整套桥接代码。代价是样式完全不可控、和游戏 UI 融不到一起。要不要用取决于这个输入入口对你的产品有多重要。用之前记得先在真机上验证一次别在开发后期才发现不适用。记一份版本矩阵。Unity 版本、适配插件版本、小游戏基础库版本、微信客户端版本这四个里任何一个变了输入相关的行为都可能跟着变。出问题的时候先对一遍版本往往能省掉大量调试时间。我现在的做法是在项目里放一个小文档每次升级任何一个就在真机上跑一遍输入框的七个用例单行输入、多行输入、中文输入、粘贴、超长截断、连续弹出两次、输入后立刻切页面。最后分享一个我自己吃过亏的细节输入完成后的收尾动作比弹出更重要。很多项目只关注能不能弹出来但真正影响体验的是收得干不干净——键盘收起后输入框的焦点有没有释放、光标有没有停在闪烁状态、下一次点击能不能立刻响应、键盘高度有没有复位到 0。这四个状态如果有一个没复位用户就会觉得这个输入框有点卡卡的、怪怪的说不出具体哪里不对但就是不舒服。我现在会在OnKeyboardComplete里统一做一次清理复位高度、清除焦点标记、把输入框的选中状态同步一次。多写这几行比事后查十个玄学 bug 划算得多。
1. 先把问题定死小游戏里缺的不是输入框 UI是宿主键盘先说一个我见过太多次的场景项目在 Unity 编辑器里跑得好好的导出到微信小游戏登录界面的账号输入框点下去——光标出来了或者连光标都没有软键盘死活不弹。然后开始怀疑人生是不是 TMP 的问题、是不是字体图集的问题、是不是 Raycast Target 被挡住了、是不是 EventSystem 掉了。折腾两三个小时之后发现UI 一点毛病都没有那个输入框画得好好的它的 RectTransform、Text 组件、Caret 全都在正常工作。真正缺的东西不在 Unity 这边而在运行环境那边——宿主根本没有把软键盘的能力交给你。Unity 微信小游戏里输入框调不起来这个现象本质上是一个平台能力缺失问题不是组件配置问题。搞清楚这一点后面所有的方案选择都会变得非常清晰。1.1 浏览器版 WebGL 输入框是怎么把键盘叫出来的要理解小游戏为什么不行得先知道浏览器版 WebGL 为什么行。Unity 的 WebGL 构建把整个游戏渲染到一张 canvas 上。canvas 本身是画布它不接收文字输入也不参与输入法的焦点管理。所以 uGUI 的 InputField 和 TMP_InputField 在 WebGL 平台上实际上依赖平台层额外创建的一个隐藏 DOM 元素——通常是一个position: fixed、opacity: 0、尺寸极小的input或者textarea。当输入框被激活时点击、调用ActivateInputField平台层会对这个隐藏元素调用focus()。浏览器收到焦点之后才会把移动端的软键盘弹出来。用户敲的字符通过input事件和composition事件回传再被塞进 Unity 的Input.inputString和Input.compositionString这两个通道InputField 从这两个通道里取字符来更新显示。所以能不能弹键盘这件事在浏览器上取决于三个条件同时成立有 DOM 元素、能 focus 成功、浏览器愿意为它弹出软键盘。桌面浏览器天然不需要软键盘所以你在编辑器或者 PC 浏览器里测永远测不出这个问题——这也是很多人白白浪费一天的原因。1.2 小游戏运行时把这一层整个抽掉了微信小游戏的 JS 运行环境是一个被大幅裁剪过的运行时Android 上基于 V8iOS 上基于 JavaScriptCore。它给你的东西是一张 canvas、一套wx.*接口、一套定时器和事件机制。它不给你的是document、window.document、HTMLInputElement、selectionStart、execCommand、focus()触发输入法这一整套浏览器行为。链条的第一环就断了。你没法创建 DOM 输入元素就算你在 jslib 里硬造一个 JS 对象出来focus()也只是一个普通方法的调用不会有任何原生行为跟在后面。结论非常直接任何依赖 DOM 聚焦来唤起软键盘的方案在小游戏环境里都不可能工作。这不是 Unity 的 bug也不是适配插件打包没打对是运行环境本身就不提供这个能力。宿主把键盘能力收回去之后换了一种形式重新暴露给开发者wx.showKeyboard/wx.hideKeyboard负责开关wx.onKeyboardInput/wx.onKeyboardConfirm/wx.onKeyboardComplete负责把结果抛回来。它给你的是整串文本加上几个开关——最大长度、是否多行、完成键文案、是否保持键盘。光标位置、选区范围、输入法候选词这些统统不归你管。这一点决定了后面所有实现细节的形态。1.3 两分钟确认根因的三个验证动作不要凭感觉判断用三个动作把结论钉死在小游戏开发者工具的 Console 里依次执行typeof document、typeof wx、typeof wx.showKeyboard。第一个是undefined后两个是function定性完成。在 Unity 侧打一行Debug.Log(TouchScreenKeyboard.isSupported)。在 WebGL 和小游戏平台上这个值基本是false。也就是说你可能想到的TouchScreenKeyboard.Open这条路调用之后什么都不会发生连报错都不会有——这是新手最常见的第一个死胡同。如果项目同时有网页版把同一个包用浏览器打开输入框正常。这就直接反证了UI 有问题这个假设。提示确认根因之后就不要再往输入框的配置项上花时间了。shouldHideMobileInput、Character Limit、Rich Text、Content Type、Line Type 这些参数在小游戏里对能不能弹出键盘没有任何影响。它们的意义只在浏览器端。2. 三条技术路线的取舍为什么最后都收敛到宿主键盘桥接根因明确之后摆在面前的路其实只有三条。我把它们的收益和代价摊开讲你可以直接对着自己的项目做判断。2.1 路线 A给运行环境塞一个假 DOM这条路的思路是既然缺 DOM那我就在 jslib 里补一个document补一个HTMLInputElement然后在需要的时候focus()它。听起来很聪明实际走不通。小游戏运行时没有浏览器内核也没有输入法管线更不会去渲染一个 DOM 元素。你造出来的对象在宿主眼里就是一个普通的 JavaScript 对象focus()是个自定义方法调用它不会触发任何原生行为。宿主不认识这个输入框自然也不会为它弹出键盘。这条路唯一有一点点空间的场景是在小程序的web-view组件里加载一个真正的网页——那里面有完整浏览器环境Unity WebGL 的输入逻辑反而能跑。但那是另一个产品形态不是小游戏。2.2 路线 B把 Unity 输入框降级成显示层键盘交给宿主这是真正可行的方案核心思路一句话TMP_InputField 只负责画文字和画光标不再负责采集输入。具体流程是用户点击输入框我们不指望 Unity 自己弹键盘而是直接调用宿主键盘接口宿主键盘的每一次输入回调里我们把整串文本写回 InputField 并同步光标用户点完成键时触发提交逻辑。好处很明显改造量小视觉和交互跟原来基本一致多语言、自定义字体、对齐方式、Placeholder 这些原有的东西全都还能用。代价也清楚受宿主键盘能力限制——拿不到选区、拿不到真实光标位置、中文输入法预编辑阶段可能拿到的是拼音串、同一时刻整个游戏只能有一个键盘。2.3 路线 C连键盘一起自绘自己画一个九宫格或者全键盘 UI。除了极少数需要严格控制输入内容的场景比如只允许输入数字的房间号、只允许选字母的兑换码这条路基本不划算。中文输入怎么办长按连击怎么办复制粘贴怎么办系统级联想词怎么办这些用户已经形成肌肉记忆的东西你自己做一遍体验只会更差。玩家不会因为你的键盘长得好看就原谅它打不出中文。2.4 三条路线的横向对比方案能否唤起系统键盘改造量光标与选区中文输入法结论A 伪造 DOM否大名义上有实际无效无放弃B 宿主键盘桥接是中等需要自己维护近似行为完整可用推荐C 自绘键盘否不是系统键盘大全部自己实现需要自建词库仅特殊场景选 B 还有一个容易被忽略的理由它把输入能力这件事从 Unity 侧彻底解耦了。以后宿主升级接口、增加新参数比如新增一种 confirmType你只需要改桥接层业务层的输入框组件完全不用动。反过来如果选了 C宿主任何一次能力升级你都吃不到还得自己维护一套输入法。3. 桥接层的完整实现从一次点击到文字落进 InputField这一节是实操主体我会把一个可用的组件完整写出来并把每一段的意图讲清楚而不是丢一堆代码让你自己猜。3.1 前置检查清单动手之前先确认四件事少一件都可能在真机上翻车插件版本小游戏需要官方那套 WebGL 小游戏适配插件。确认版本早期版本并没有把键盘接口封装成 C# 对象你需要自己写 jslib。判断方法很简单在 C# 里打WX.看能不能自动补全出ShowKeyboard出不来就是版本不够。宏定义适配插件在打包时会加上自己的宏。业务代码里要用#if UNITY_WEBGL !UNITY_EDITOR或者插件宏包一层保证编辑器里还能正常跑编辑器里我们走 Unity 自己的输入方便调试。Input SystemPlayer Settings 里的 Active Input Handling 建议保持 Input Manager (Old) 或者 Both。切到纯 New Input System 之后WebGL 平台的键盘事件通道容易出各种奇怪问题。而我们的输入本来就不走 Unity 的输入事件没必要冒这个险。字体图集输入内容里如果可能出现生僻字字体图集要留够。否则会出现文字确实写进去了但显示成一个方块然后你又得花半天排查是回写逻辑的问题还是字体的问题。3.2 插件已暴露接口时的 C# 实现下面这个组件可以直接用我把关键点用注释标出来using System; using TMPro; using UnityEngine; #if UNITY_WEBGL !UNITY_EDITOR using WeChatWASM; #endif [RequireComponent(typeof(TMP_InputField))] public class MiniGameInputField : MonoBehaviour { [SerializeField] private TMP_InputField field; [SerializeField] private int maxLength 20; [SerializeField] private bool multiple false; [SerializeField] private string confirmType done; [SerializeField] private bool confirmHold false; public event Actionstring Submitted; private bool _bound; // 监听是否已经注册 private bool _showing; // 键盘是否处于弹出状态 private void Reset() field GetComponentTMP_InputField(); private void Awake() { if (!field) field GetComponentTMP_InputField(); field.shouldHideMobileInput true; field.onSelect.AddListener(_ Show()); field.onDeselect.AddListener(_ Hide()); } private void OnDestroy() Unbind(); private void Bind() { if (_bound) return; _bound true; #if UNITY_WEBGL !UNITY_EDITOR WX.OnKeyboardInput(OnKeyboardInput); WX.OnKeyboardConfirm(OnKeyboardConfirm); WX.OnKeyboardComplete(OnKeyboardComplete); WX.OnKeyboardHeightChange(OnKeyboardHeightChange); #endif } private void Unbind() { if (!_bound) return; _bound false; #if UNITY_WEBGL !UNITY_EDITOR WX.OffKeyboardInput(OnKeyboardInput); WX.OffKeyboardConfirm(OnKeyboardConfirm); WX.OffKeyboardComplete(OnKeyboardComplete); WX.OffKeyboardHeightChange(OnKeyboardHeightChange); #endif } }这里有几个设计决定值得解释。为什么在onSelect里触发弹出因为这样能复用 Unity 原有的交互逻辑点击输入框、Tab 切换、代码里调ActivateInputField都会走到同一个入口行为一致。为什么用_bound标志位而不是直接靠OnEnable/OnDisable因为节点可能被反复 SetActive或者 UI 面板被对象池复用注册累积之后一次输入会触发多次回调表现为打一个字出现两个。标志位是最省事也最可靠的挡板。弹出和收起的实现public void Show() { #if UNITY_WEBGL !UNITY_EDITOR Bind(); // 关键先收干净再弹。宿主同一时刻只允许一个键盘 // 上一次没收到位的话show 会直接 fail。 if (_showing) { WX.HideKeyboard(new HideKeyboardOption()); } _showing true; WX.ShowKeyboard(new ShowKeyboardOption { defaultValue field.text ?? string.Empty, maxLength maxLength, // 必须显式给且和 Character Limit 对齐 multiple multiple, confirmType confirmType, // done / next / search / go / send confirmHold confirmHold, success _ { }, fail res { _showing false; Debug.LogWarning([MiniGameInputField] showKeyboard fail: res.errMsg); } }); #else field.ActivateInputField(); #endif } public void Hide() { #if UNITY_WEBGL !UNITY_EDITOR if (!_showing) return; _showing false; WX.HideKeyboard(new HideKeyboardOption()); #else field.DeactivateInputField(); #endif }一定要注意fail回调里的那行日志。真机上出问题的时候showKeyboard绝大多数情况下是有返回失败的只不过你没接fail所以看起来像什么都没发生。把errMsg打出来排查效率能提升一个数量级。回写逻辑#if UNITY_WEBGL !UNITY_EDITOR private void OnKeyboardInput(OnKeyboardInputListenerResult res) { WriteBack(res.value, false); } private void OnKeyboardConfirm(OnKeyboardConfirmListenerResult res) { WriteBack(res.value, true); // confirmHold 为 false 时确认后键盘会自行收起 // complete 回调会随后到达在这里先把状态位放开。 _showing false; Submitted?.Invoke(field.text); field.onSubmit?.Invoke(field.text); } private void OnKeyboardComplete(OnKeyboardCompleteListenerResult res) { _showing false; } private void OnKeyboardHeightChange(OnKeyboardHeightChangeListenerResult res) { // 这里只缓存高度不要在回调里直接做重布局 MiniGameKeyboardLayout.SetHeight(res.height); } #endif private void WriteBack(string value, bool force) { value ?? string.Empty; if (!force field.text value) return; field.SetTextWithoutNotify(value); field.caretPosition value.Length; field.stringPosition value.Length; field.ForceLabelUpdate(); }如果你的插件版本里回调结果类的字段名不是value别猜直接Debug.Log(JsonUtility.ToJson(res))打一次就能看到真实结构。不同版本的字段命名确实有过变化。3.3 插件版本太旧时自己写 jslib 桥有些项目因为 Unity 版本或者历史原因用的插件比较老没有暴露键盘接口。这时候可以自己补一层代码量比想象中小得多// Assets/Plugins/WebGL/WXMiniGameKeyboard.jslib mergeInto(LibraryManager.library, { WXMG_RegisterKeyboard: function (goPtr, inputMethodPtr, confirmMethodPtr, completeMethodPtr) { var go UTF8ToString(goPtr); var mInput UTF8ToString(inputMethodPtr); var mConfirm UTF8ToString(confirmMethodPtr); var mComplete UTF8ToString(completeMethodPtr); wx.onKeyboardInput(function (res) { SendMessage(go, mInput, res.value || ); }); wx.onKeyboardConfirm(function (res) { SendMessage(go, mConfirm, res.value || ); }); wx.onKeyboardComplete(function (res) { SendMessage(go, mComplete, res.value || ); }); }, WXMG_ShowKeyboard: function (defaultValuePtr, maxLength, multiple, confirmTypePtr, confirmHold) { wx.showKeyboard({ defaultValue: UTF8ToString(defaultValuePtr), maxLength: maxLength, multiple: !!multiple, confirmType: UTF8ToString(confirmTypePtr), confirmHold: !!confirmHold }); }, WXMG_HideKeyboard: function () { wx.hideKeyboard({}); } });C# 侧声明#if UNITY_WEBGL !UNITY_EDITOR using System.Runtime.InteropServices; [DllImport(__Internal)] private static extern void WXMG_ShowKeyboard(string defaultValue, int maxLength, bool multiple, string confirmType, bool confirmHold); [DllImport(__Internal)] private static extern void WXMG_HideKeyboard(); [DllImport(__Internal)] private static extern void WXMG_RegisterKeyboard(string go, string onInput, string onConfirm, string onComplete); #endifSendMessage在这个 jslib 环境里是可用的适配插件自己也是靠它和 JS 层通信。接收消息的脚本必须挂在场景里一个常驻的 GameObject 上名字和字符串参数要对得上否则消息发出去就静默丢失了——这类问题没有报错只能靠日志确认。还有两个必须遵守的硬性约定jslib 文件必须放在Assets/Plugins/WebGL/目录下扩展名必须是.jslib文件换过位置或者改过名字之后回到 Unity 里右键 Reimport 一次再打包。3.4 回写文本的三种写法以及各自的副作用回写这个动作看起来最简单实际上最容易埋雷。三种写法我都用过field.text value;—— 最省事但它会触发onValueChanged。如果你在这个回调里做了实时校验转大写、过滤非法字符、限制字符类型就会形成回环你改文本 → 回调又改文本 → 你又改回去。表现出来就是打字的时候光标乱跳、字被吃掉、删不掉。要么加一个_ignoreNext布尔挡一下要么直接换下一种写法。field.SetTextWithoutNotify(value);—— TMP 专有不触发onValueChanged。这是我默认的选择。代价是你得在外部手动调用自己的校验逻辑不能再指望组件回调帮你触发。自己算差值只插入新增字符 —— 适合需要精细控制光标和防注入的场景。思路是先算公共前缀定位这次插入或删除的位置private int DiffInsertIndex(string oldText, string newText) { int i 0; int min Mathf.Min(oldText.Length, newText.Length); while (i min oldText[i] newText[i]) i; return i; }但要提醒一句这个方法只能推测插入点。中文输入法预编辑阶段会不断给出中间状态差分会误判所以只在onKeyboardConfirm之后用比较稳。另外注意 API 差异TMP_InputField 用caretPosition和stringPosition老的 uGUI InputField 用的是caretPosition配合selectionAnchorPosition、selectionFocusPosition。写混了不会报错只是光标不听话。4. 键盘弹起之后的麻烦光标、多行、高度与平台差异键盘能弹出来只是第一步真正消耗时间的是弹出之后的细节。4.1 光标为什么永远停在末尾因为宿主只给你整串文本不给你光标位置。你在onKeyboardInput里每次重设文本光标就只能落到末尾。单行输入毫无影响用户根本感知不到。但多行输入就明显了用户想点中间某处插入一个字结果发现自己插不了。两个可以接受的应对方式一是多行输入时不要在onKeyboardInput里重置光标只在确认时回写一次二是用上面的差分方法推算插入位置把光标定到插入点。后者在中文输入法下会有抖动所以只在确认阶段用中间阶段不碰光标。还有一个很隐蔽的现象如果用户删到空串而你的WriteBack里写了if (!force field.text value) return;这种短路判断空串和空串相等会直接跳过看起来没问题但如果此时 Placeholder 的显示逻辑和text状态不同步就会出现占位符和光标同时显示的怪样子。稳妥做法是回写之后显式调一次field.ForceLabelUpdate()。4.2 多行、confirmType 与 confirmHold 的组合这三个参数经常被随便填结果体验很差。按场景对齐会好很多场景multipleconfirmTypeconfirmHold说明昵称 / 账号falsedonefalse单行一般限制 12 到 16 个字符注意中英文混排的显示宽度差异聊天输入falsesendtrueconfirmHold 保持键盘方便连续发送此时需要自己调 Hide搜索框falsesearchfalse完成键文案直接影响用户理解别全用 done个性签名truedonefalse多行时换行来自键盘的换行键注意 Unity 侧 Line Type 要设为 Multi Line Newline关于maxLength有一个特别容易踩的坑它是必填参数不给的话宿主会用默认值通常是 140。如果它和 InputField 的 Character Limit 不一致就会出现两种诡异现象——键盘允许打但 Unity 截断或者明明还能输入但键盘不给打了。两边必须对齐我一般是把同一个字段暴露给两个地方而不是各写各的。4.3 键盘高度变化与 UI 上移的换算WX.OnKeyboardHeightChange给你的是键盘高度单位是屏幕像素。要拿它推动 Unity 的 UI中间需要换算一次// keyboardHeightPx: 宿主回调给的高度 // pixelRatio: WX.GetSystemInfoSync().pixelRatio // canvas.scaleFactor: Canvas Scaler 的缩放系数 float uiOffset keyboardHeightPx / pixelRatio / canvas.scaleFactor;pixelRatio从系统信息里拿一次缓存起来不要每帧取。scaleFactor从 Canvas 组件上读。换算完之后用插值把它应用到输入框所在面板的 RectTransform 上别硬设否则键盘弹出的瞬间整个面板会啪地跳一下。更重要的是不要在OnKeyboardHeightChange回调里直接做重布局这个回调触发频率不低在里面做布局会直接掉帧。正确做法是回调里只缓存目标高度在Update里做 lerp。还有一个坑值说iOS 上键盘是覆盖在 canvas 之上的浮层游戏画面本身不会改变尺寸所以必须自己移。Android 上部分机型会压缩可见区域如果你既移了 UI、又赶上系统触发了一次 resize视觉上就会移两次。用一个标志位记录这次键盘弹出是否已经响应过 resize能解决大部分双倍位移。4.4 iOS 与 Android 的实测差异下面这张表是我在几个项目里反复验证过的差异但请把它当参考而不是结论——机型、输入法、基础库版本、微信版本任何一个变了行为都可能不一样。真机验证永远优先。行为iOSAndroid键盘呈现方式覆盖在 canvas 之上的浮层部分机型压缩可见区域键盘高度回调触发稳定部分机型不触发或者只在首次触发输入法上屏时机onKeyboardInput 给的基本是上屏后的中文部分输入法会把拼音预编辑阶段也推过来confirmHold 支持支持良好部分机型点完成键仍会收起键盘对调用时机的敏感度更敏感跨帧调用容易失败相对宽松这些差异直接影响你的实现策略。比如因为第三行的那条差异你的实时校验逻辑就必须写得足够宽容不能假定拿到的永远是最终文本。因为最后一行那条差异如果你的Show()是在一个异步回调或者协程里被调用的最好准备一个提前到触摸同一条调用链里触发的备选版本。5. 五个真实排错现场从工具里好好的到真机没反应前面讲的是正常路径这一节讲的是事故现场。我把踩过的都列出来你可以直接对着症状找。5.1 开发者工具里一切正常真机不弹这是最经典的一个。开发者工具跑在 PC 上wx.showKeyboard落到的是电脑键盘行为跟真机完全不同。工具里测通不代表任何事。排查顺序我固定按这个来第一步真机调试并打开日志面板把showKeyboard的fail回调里的errMsg打出来。九成的答案是这里有内容而不是没有回调。第二步如果errMsg里出现 keyboard is showing 之类的字样说明上一次没收干净——每次 show 之前先 hide并且维护状态位。第三步如果连 fail 都没有检查调用是不是落在了跨帧的异步回调里试着把调用挪回到用户触摸的同一条调用链上再测一次。第四步确认小游戏后台设置的基础库版本不至于太旧接口不完整的情况下表现就是没有任何反应。5.2 键盘弹出来了字却进不去三种典型原因。第一种是回写成功了但显示没刷新TMP 一般不会老的 uGUI InputField 有时候需要显式调ForceLabelUpdate()。第二种是onValueChanged里的校验逻辑把字吃掉了特别是用char.IsLetterOrDigit做白名单的时候——中文属于 Letter 能过关但 emoji、部分标点、特殊符号会被静默丢弃排查时先加日志打印被丢掉的字符。第三种是场景里有两个输入框抢焦点onSelect里先调了一次ActivateInputField又触发了Show()两路回写互相覆盖表现是字进去又没了。5.3 第二次点击没反应或者一口气弹两次这个问题的根源基本都在监听注册上。Awake或者OnEnable里注册监听但节点被反复 SetActive、或者场景重载监听就累积了。累积之后一次onKeyboardInput会触发 N 次表现是最后一个字符变成两个或者文本看起来在闪烁。另一种情况是状态位没复位。iOS 上点完成键收起键盘时如果你没有注册onKeyboardComplete_showing会一直保持true。下一次点击时因为状态位是 true会先 Hide 再 Show中间产生一次肉眼可见的闪动网络慢的时候甚至真的弹不出来。还有一种输入框本身是个可点击区域外面还包了一层 Button 也绑了onClick调Show()一次点击触发两遍第二遍必然收到 fail。这种问题查起来很快但前提是你想到了去看fail的日志。5.4 打包之后才坏代码剥离与宏定义这类问题在编辑器里怎么测都测不出来一打包就废。首先是 Managed Stripping Level。调高之后某些监听结果类只有字段没有方法的 POCO的字段可能被剥掉表现为回调能进但res.value永远是 null或者整个回调静默不触发。对策是在Assets/link.xml里保留相关程序集linker assembly fullnameWeChatWASM preserveall/ assembly fullnameAssembly-CSharp preserveall/ /linker其次是宏定义分支。用#if UNITY_EDITOR包起来的代码在编辑器里跑得很好真机走的是另一条分支如果那条分支忘了写或者写错了就会出现编辑器好好的真机什么都没发生。这个错误没有编译警告只能靠真机测试发现。最后是 jslib 的放置。必须在Assets/Plugins/WebGL/下扩展名必须是.jslib文件改动之后要 Reimport 一次再打包。放在 Plugins 根目录下某些情况下会被当成普通文本资源处理链接阶段直接找不到符号。5.5 中文候选词阶段拿到的是拼音串这条单独拎出来说因为它会以一种看起来逻辑没错但结果就是不对的方式坑人。如果你在onKeyboardInput里做实时搜索、敏感词过滤、或者字数限制会在 iOS 上观察到一种现象用户还在输拼音你的搜索结果已经在跟着拼音字母变了或者字数统计把拼音字母也算进去了用户还没选词提示就已经红了。稳妥的做法是把处理分层onKeyboardInput只负责把文字显示出来不做任何业务判断所有校验、搜索、提交逻辑全部放到onKeyboardConfirm和onKeyboardComplete里。这会让实时搜索这类需求在小游戏上打点折扣但比起错误结果用户更能接受稍微慢半拍的反馈。6. 可以直接抄走的检查清单以及几条我踩出来的经验每次上线前我会把下面这张清单过一遍。它不含任何高深的东西但每一条都对应过一次真实的线上问题。编号检查项判断方式1环境确认Console 里typeof document为 undefined2方案确认走的是宿主键盘接口不是等 Unity 自己弹3键盘状态show 之前 hide 干净状态位正确复位4长度对齐maxLength 与 Character Limit 数值一致5监听唯一只注册一次节点销毁时注销6回写方式使用 SetTextWithoutNotify避免 onValueChanged 回环7光标同步回写后同步 caretPosition 与 stringPosition8高度适配键盘高度做了 pixelRatio 与 scaleFactor 换算且是插值移动9真机验收真机、体验版、正式版各跑一次不只看开发者工具10剥离配置link.xml 保留了回调相关程序集除了清单还有几条经验我认为比技术细节更重要。把输入框封装成一个统一组件全局只允许存在一个键盘。用一个静态引用记录当前聚焦的输入框切换页面、切换输入框的时候先把上一个收干净。这样第二次点击没反应两个输入框互相抢字这类问题会从源头消失而不是靠一个个补丁去堵。不要在onSelect里无脑触发弹出。onSelect也可能被代码调用比如进入页面自动聚焦、或者列表滚动时的误触。如果你的业务里有自动聚焦的需求最好用一个显式的点击事件来触发弹出把被选中和要弹键盘这两件事分开。有些需求根本不值得做桥接。如果只是想收集一句话输入——比如举报理由、修改昵称、填写一句留言——宿主提供的showModal带可编辑模式可以直接弹出一个原生输入框拿到结果省掉整套桥接代码。代价是样式完全不可控、和游戏 UI 融不到一起。要不要用取决于这个输入入口对你的产品有多重要。用之前记得先在真机上验证一次别在开发后期才发现不适用。记一份版本矩阵。Unity 版本、适配插件版本、小游戏基础库版本、微信客户端版本这四个里任何一个变了输入相关的行为都可能跟着变。出问题的时候先对一遍版本往往能省掉大量调试时间。我现在的做法是在项目里放一个小文档每次升级任何一个就在真机上跑一遍输入框的七个用例单行输入、多行输入、中文输入、粘贴、超长截断、连续弹出两次、输入后立刻切页面。最后分享一个我自己吃过亏的细节输入完成后的收尾动作比弹出更重要。很多项目只关注能不能弹出来但真正影响体验的是收得干不干净——键盘收起后输入框的焦点有没有释放、光标有没有停在闪烁状态、下一次点击能不能立刻响应、键盘高度有没有复位到 0。这四个状态如果有一个没复位用户就会觉得这个输入框有点卡卡的、怪怪的说不出具体哪里不对但就是不舒服。我现在会在OnKeyboardComplete里统一做一次清理复位高度、清除焦点标记、把输入框的选中状态同步一次。多写这几行比事后查十个玄学 bug 划算得多。
