内容摘要：周五下午三点，我盯着登录页面的密码框，光标在里面闪，键盘敲下去却一个字都没出现。换了浏览器，重启电脑，甚至把键盘拔了重插——没用。隔壁工位的同事凑过来看了一眼，说：“你试试按一下 F12，看看 Con

周五下午三点，网页我盯着登录页面的输入密码框，光标在里面闪，框输键盘敲下去却一个字都没出现。不进换了浏览器，字办重启电脑，网页甚至把键盘拔了重插——没用。输入隔壁工位的框输同事凑过来看了一眼，说：“你试试按一下 F12，不进看看 Console 里有没有报错。字办”我照做，网页控制台里一行红字：Uncaught TypeError: Cannot read property 'focus' of null。输入问题就出在这。框输

输入框输不进字，不进九成以上不是字办键盘坏了。真正的原因往往藏在网页代码或浏览器状态里。最常见的场景是 JavaScript 报错导致输入事件被阻断。比如某个脚本在页面加载时试图给一个不存在的元素绑定事件，整个页面的交互逻辑就崩了。这时候你敲键盘，浏览器收到了按键信号，但页面上的输入框没“接住”，自然没反应。

另一个高频原因是 CSS 的 pointer-events: none 被意外加到了输入框或其父容器上。这个属性会让元素完全忽略鼠标和键盘事件，看起来正常，实际是个“死”的。我遇到过一个小型后台系统，因为一个全局的加载遮罩层没正确移除，遮罩覆盖了整个页面，输入框就在下面，点得进去，打不了字。开发者工具里选中输入框，看 Styles 面板，一眼就能发现。

浏览器扩展也是惯犯。广告拦截器、密码管理器、翻译插件，都可能往页面里注入脚本，跟原有代码打架。有一次我帮人排查，发现是某个划词翻译插件把输入框的 keydown 事件给 stopPropagation 了。禁用所有扩展，用无痕窗口打开，问题消失——那就逐个启用，定位到元凶。

还有一种情况比较隐蔽：输入法冲突。中文输入法在某个特定网页上卡住，候选框不出现，直接吞掉按键。切换到英文输入法试试，如果能打字，就是输入法和网页的兼容问题。更新输入法，或者换一个，通常能解决。

如果以上都排除了，检查一下输入框是不是被设置了 readonly 或 disabled 属性。这两个属性会让输入框无法编辑，但外观上可能只有细微差别。右键检查元素，看 HTML 里有没有这两个词。有些表单在提交前会临时加上 disabled，提交失败后忘了移除，用户就卡住了。

我自己的排查顺序是这样的：先看 Console 有没有报错，再看 Elements 里输入框的属性和样式，然后无痕窗口排除扩展，最后换浏览器或设备。大部分问题在前两步就能定位。如果是自己开发的页面，重点查事件监听和异步加载逻辑——输入框可能还没渲染出来，脚本就急着去操作它了。

实在搞不定，还有一个笨办法：在 Console 里手动给输入框赋值。找到输入框元素，执行 document.querySelector('input').value = '测试'，如果能显示，说明输入框本身没坏，只是事件被拦截了。这招能帮你判断问题出在渲染层还是交互层。网页输入框打不了字，本质上是“你敲了键盘，但页面没收到”或者“页面收到了但没处理”。顺着这条线查，比盲目重启有效得多。