@testing-library/user-event v14 keyboard方法无法更新输入框问题排查

这个问题的核心是**@testing-library/user-event v14对keyboard和交互事件的模拟逻辑做了重大调整，更贴近真实浏览器的行为，而v13及之前的版本存在“宽松”的模拟逻辑**，具体差异如下：

1. keyboard方法的行为变更 #

• 在v13.5及更早版本中，keyboard方法会直接将按键输入绑定到当前“预期”的元素上，哪怕元素没有真正获得原生DOM焦点，也能触发内容更新，相当于做了一层“兼容”处理。
• v14开始，keyboard严格遵循真实浏览器规则：只有当目标元素处于可编辑状态且获得原生DOM焦点时，按键输入才会被识别并更新元素内容。如果元素没有真正拿到焦点，keyboard的输入就会“无效”，不会触发内容变化。

2. click + keyboard vs event.type的差异 #

• event.type是user-event专门为输入框、文本域这类可编辑元素设计的API，内部会自动完成「聚焦元素 → 逐键输入 → 触发input/change事件」的完整流程，不需要手动处理焦点，所以在v14中依然能稳定工作。
• 而分开调用click和keyboard时，v14的click方法虽然会模拟点击，但如果你的输入框是自定义组件（比如封装了原生input的React/Vue组件），点击可能只触发了组件的外层点击事件，并没有将焦点传递到内部的原生输入节点上；或者组件内部用状态管理控制焦点，导致click后document.activeElement并不是目标输入元素，此时keyboard的输入自然不会生效。

3. 额外的时序与状态校验问题 #

v14对事件模拟的异步时序要求更严格，哪怕用了await，如果组件内部的焦点状态更新需要额外的微任务周期，click后立即调用keyboard可能会出现焦点未同步的情况，导致输入失效。

解决建议 #

• 优先使用event.type模拟输入框的文本输入，这是官方推荐的针对可编辑元素的标准用法，兼容性和稳定性更好。
• 如果必须拆分click和keyboard操作，可以改用await event.focus(nameField)手动触发焦点，确保元素获得原生DOM焦点后再调用keyboard。
• 检查自定义输入组件的焦点逻辑，确保点击时能将原生焦点正确设置到内部的<input>或<textarea>节点上。

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