1. 键盘事件与键码值的前世今生做前端开发的朋友尤其是经常跟表单、快捷键、游戏交互打交道的大概率都绕不开一个东西——键盘按键的键码值。你可能在某个深夜调一个快捷键功能onkeydown里打印出来的keyCode死活对不上或者用户反馈“我按了回车没反应”结果发现是中文输入法状态下keyCode变成了 229。这些坑我几乎一个不落地全踩过。所谓键码值简单说就是浏览器给键盘上每一个物理按键分配的一个数字身份证。你按下 A 键浏览器告诉你“13 号键被按下了”或者“65 号键被按下了”这个数字就是键码。它最早是伴随 DOM 事件模型一起出现的onkeydown、onkeyup、onkeypress这三个事件构成了键盘交互的基础骨架。其中onkeydown和onkeyup对应“按下”和“抬起”两个动作而onkeypress则是在按下并产生字符输入时触发——注意它不区分大小写也不响应功能键。这套东西看起来简单但真正用起来坑多到能写一本书。不同浏览器对同一个键给出的keyCode可能不一样key、code、keyCode、which这几个属性各有各的脾气再加上输入法、操作系统、外接键盘的差异一个看似简单的“监听回车键”需求背后可能藏着十几条分支逻辑。这篇内容就是把这些年我在实际项目里积累的键码对照经验、事件选型思路、兼容性处理方案系统地整理出来不管你是刚接触键盘事件的新手还是想查漏补缺的老手都能直接拿去用。2. 三个键盘事件到底该用哪个2.1 onkeydown、onkeyup、onkeypress 的本质区别很多人写代码时习惯性地用onkeypress觉得“按键”嘛肯定用 press 最直观。但实际情况是onkeypress正在被现代标准逐步边缘化MDN 上已经明确标注它属于废弃特性。为什么因为它的定位很尴尬——它只在产生可打印字符时触发功能键F1-F12、Shift、Ctrl、方向键等根本不会触发它。你想想用户按了 Shift 想做什么你根本监听不到。onkeydown和onkeyup才是真正覆盖全部按键的事件。onkeydown在按键按下的瞬间触发如果用户按住不放操作系统会以一定的重复速率持续触发这个速率可以在系统设置里调所以它天然适合做“长按加速”这类功能。onkeyup则在松开按键时触发一次适合做“松开停止”的逻辑。我个人的选型原则很简单需要响应所有按键、需要处理组合键、需要做快捷键一律用onkeydown需要精确知道用户什么时候松手用onkeyuponkeypress除非维护老项目新项目里我基本不碰。2.2 事件触发顺序与冒泡机制一次完整的按键操作事件触发顺序是这样的先keydown如果产生了字符输入紧接着keypress最后松手时keyup。如果按住不放keydown和keypress会交替重复触发直到松手才来一次keyup。这里有个容易忽略的点这三个事件都是可以冒泡的。也就是说你在一个输入框上按键盘事件会从输入框一路冒泡到 document甚至 window。很多全局快捷键的实现就是利用这个机制在 document 层面监听keydown然后判断event.target是不是输入框来决定要不要拦截。但反过来如果你不想让某个按键触发全局快捷键就得在输入框的keydown里调用event.stopPropagation()把冒泡掐断。注意keypress在有些浏览器里对退格键、删除键的触发行为不一致这也是我不推荐用它的原因之一。2.3 该监听在哪个元素上监听位置的选择直接影响代码的健壮性。如果你只关心某个输入框的按键直接绑在输入框上最省事。但如果你要做全局快捷键比如“按 CtrlS 保存”绑在 document 上更合适因为用户焦点可能在页面任何位置。不过绑在 document 上有个副作用用户在输入框里正常打字时你的全局快捷键逻辑也会被触发。解决办法是在处理函数开头加一个判断document.addEventListener(keydown, function(e) { const tag e.target.tagName.toLowerCase(); if (tag input || tag textarea || e.target.isContentEditable) { return; // 输入框内的按键不触发全局快捷键 } // 全局快捷键逻辑 });这个判断看起来简单但少了它用户在你页面上的每一次输入都可能触发莫名其妙的快捷键行为体验直接崩掉。3. 键码值核心对照表与属性解析3.1 常用按键 keyCode 速查表下面这张表是我从实际项目中整理出来的高频按键对照涵盖了字母、数字、功能键和常用符号。需要说明的是keyCode的值在不同浏览器和操作系统上可能存在细微差异但下面这些主流值在 Chrome、Edge、Firefox、Safari 上基本一致。按键keyCodekey 值code 值回车 Enter13EnterEnter退格 Backspace8BackspaceBackspace制表 Tab9TabTab空格 Space32空格字符SpaceEsc27EscapeEscape左方向键37ArrowLeftArrowLeft上方向键38ArrowUpArrowUp右方向键39ArrowRightArrowRight下方向键40ArrowDownArrowDownDelete46DeleteDeleteShift16ShiftShiftLeft / ShiftRightCtrl17ControlControlLeft / ControlRightAlt18AltAltLeft / AltRightCaps Lock20CapsLockCapsLockF1112F1F1F2113F2F2F12123F12F12数字 0-948-570-9Digit0-Digit9字母 A-Z65-90a-z 或 A-ZKeyA-KeyZ分号 ;186; 或 :Semicolon等号 187 或 Equal逗号 ,188, 或 Comma减号 -189- 或 _Minus句号 .190. 或 Period斜杠 /191/ 或 ?Slash反引号 192 或 ~Backquote左方括号 [219[ 或 {BracketLeft反斜杠 \220\ 或 |Backslash右方括号 ]221] 或 }BracketRight单引号 222 或 Quote这张表里有个细节值得注意字母键的keyCode是大写字母的 ASCII 码A 是 65Z 是 90跟是否按下 Shift 无关。也就是说你按小写 a 和大写 AkeyCode都是 65。这也是为什么很多老代码用keyCode判断字母时不需要区分大小写。3.2 key、code、keyCode、which 到底有什么区别这是键盘事件里最容易混淆的一组属性我见过不少工作两三年的开发者还在用which然后被兼容性问题折磨得死去活来。逐个说清楚keyCode是历史遗留属性返回一个数字。它的值取决于按下的物理键但不同浏览器对某些键的映射不一致。比如分号键Chrome 返回 186某些旧版 Firefox 可能返回 59。它已经被标记为废弃但出于兼容性考虑目前所有主流浏览器仍然支持。which是更古老的属性本质上就是keyCode或charCode的别名同样废弃。新项目里没有任何理由再用它。key是现代标准属性返回一个字符串。它的值考虑了修饰键的状态——你按 a 返回 a按 Shifta 返回 A按回车返回 Enter。这个属性可读性最好但有个坑它受键盘布局和输入法影响。同一个物理按键在中文输入法激活状态下key可能返回 Process 而不是实际字符。code也是现代标准属性返回一个字符串表示物理按键的位置。它不受键盘布局和修饰键影响KeyA 永远是 KeyA不管你是按的 a 还是 A也不管你用的是 QWERTY 还是 Dvorak 布局。做游戏控制、快捷键这类需要精确识别物理按键的场景code是最可靠的选择。我的建议很明确新项目优先用code做物理按键判断用key做字符输入判断keyCode只在需要兼容极老环境时作为兜底。3.3 修饰键与组合键的键码表现修饰键Shift、Ctrl、Alt、Meta比较特殊它们自己触发keydown时keyCode分别是 16、17、18、91或 93。但更重要的是当它们和其他键组合按下时事件对象上的shiftKey、ctrlKey、altKey、metaKey这几个布尔属性会变成 true。比如你要实现 CtrlS 保存不应该去判断keyCode 83 ctrlKey更稳妥的写法是document.addEventListener(keydown, function(e) { if (e.ctrlKey e.code KeyS) { e.preventDefault(); // 阻止浏览器默认的保存页面行为 // 执行自定义保存逻辑 } });这里e.preventDefault()非常关键。浏览器对很多组合键有默认行为CtrlS 是保存网页CtrlP 是打印F5 是刷新。你不阻止默认行为用户按下去页面就刷新了你的逻辑根本没机会执行。注意Mac 上对应的是 Command 键事件属性是metaKey。做跨平台快捷键时通常写成(e.ctrlKey || e.metaKey)来同时兼容 Windows 和 Mac。4. 实战从零实现一个键码检测工具4.1 页面结构与交互设计光看对照表记不住最好的学习方式是自己动手做一个键码检测页面。这个工具的逻辑很简单监听键盘事件把keyCode、key、code、which以及修饰键状态实时显示出来。页面结构用最朴素的 HTML 就行一个展示区域加一个清空按钮div idoutput p按下任意键查看键码信息/p /div button idclearBtn清空记录/button展示区域用来追加每次按键的信息清空按钮方便重新开始。这个工具虽然简单但调试键盘相关功能时特别有用——你不需要猜某个键的keyCode是多少按一下就知道。4.2 事件监听与数据采集逻辑核心逻辑就是监听keydown事件把事件对象上的关键属性提取出来const output document.getElementById(output); const clearBtn document.getElementById(clearBtn); document.addEventListener(keydown, function(e) { const info { keyCode: e.keyCode, which: e.which, key: e.key, code: e.code, shift: e.shiftKey, ctrl: e.ctrlKey, alt: e.altKey, meta: e.metaKey }; const line document.createElement(p); line.textContent keyCode: ${info.keyCode} | which: ${info.which} | key: ${info.key} | code: ${info.code} | Shift: ${info.shift} | Ctrl: ${info.ctrl} | Alt: ${info.alt} | Meta: ${info.meta}; output.appendChild(line); }); clearBtn.addEventListener(click, function() { output.innerHTML p按下任意键查看键码信息/p; });这段代码跑起来后你按任意键页面上就会实时显示这个键的所有属性值。我建议你拿它去测试几个特殊场景中文输入法激活时按字母键、按住 Shift 再按字母、按 F 系列功能键、按方向键。你会直观地看到keyCode和key在不同场景下的变化规律。4.3 输入法状态下的键码陷阱中文输入法是个大坑。当输入法处于激活状态时你按字母键keydown事件的keyCode会变成 229key会变成 Process。这意味着如果你用keyCode判断用户是否按了某个字母键在中文输入法下会完全失效。这个问题的根源在于输入法需要拦截按键来做候选词处理浏览器收到的是一个“正在处理中”的信号而不是具体的字符。解决办法有两个方向一是用code属性代替keyCode因为code反映的是物理按键位置不受输入法影响。你按 A 键不管输入法是否激活code都是 KeyA。二是监听compositionstart和compositionend事件在输入法组合期间不做按键判断等组合结束后再处理。这个方案适合需要精确处理文本输入的场景。let isComposing false; document.addEventListener(compositionstart, function() { isComposing true; }); document.addEventListener(compositionend, function() { isComposing false; }); document.addEventListener(keydown, function(e) { if (isComposing) return; // 输入法组合期间忽略按键 // 正常按键处理 });我实测下来对于快捷键类需求直接用code最省心对于文本输入类需求配合 composition 事件处理最稳妥。5. 常见兼容性问题与排查实录5.1 不同浏览器键码差异速查虽然现代浏览器在键码上已经高度统一但仍有几个历史遗留的差异点需要留意。下面这张表整理了我实际遇到过的差异情况按键Chrome/EdgeFirefoxSafari建议方案分号 ;186186186用 code: Semicolon等号 187187187用 code: Equal减号 -189173189用 code: Minus逗号 ,188188188用 code: Comma句号 .190190190用 code: Period斜杠 /191191191用 code: SlashMeta 键9122491用 metaKey 属性判断可以看到减号键在 Firefox 上的keyCode是 173和其他浏览器的 189 不一样。这就是为什么我一直强调能用code就用codekeyCode只作为最后的兜底方案。5.2 按键重复触发的处理策略用户按住某个键不放时keydown会以系统设定的重复速率持续触发。这个行为在有些场景下是需要的比如游戏里的方向移动、文本编辑器里的连续删除。但在另一些场景下是灾难比如“按一次 CtrlS 保存一次”如果用户手抖按住不放可能会触发几十次保存请求。处理按键重复有两种思路。第一种是记录按键状态在keydown时检查是否已经按下如果是则忽略const pressedKeys new Set(); document.addEventListener(keydown, function(e) { if (pressedKeys.has(e.code)) return; // 已经按下忽略重复触发 pressedKeys.add(e.code); // 执行按键逻辑 }); document.addEventListener(keyup, function(e) { pressedKeys.delete(e.code); });第二种是直接判断事件对象的repeat属性现代浏览器都支持document.addEventListener(keydown, function(e) { if (e.repeat) return; // 这是重复触发忽略 // 执行按键逻辑 });e.repeat方案更简洁我一般优先用它。但要注意如果你的逻辑需要响应长按比如长按加速就不能忽略重复触发反而要利用它。5.3 快捷键冲突与默认行为拦截浏览器和操作系统层面预定义了大量快捷键你的自定义快捷键很可能和它们撞车。常见的冲突包括CtrlS保存页面、CtrlP打印、CtrlF页内查找、CtrlD收藏、F5刷新、F12开发者工具、CtrlW关闭标签页等。对于可以拦截的快捷键用e.preventDefault()阻止默认行为即可。但有些快捷键是浏览器级别的比如 CtrlW 关闭标签页preventDefault()也拦不住。这种情况下只能换一个不冲突的组合比如用 CtrlShiftS 代替 CtrlS。注意preventDefault()必须在事件处理函数的最前面调用如果前面有异步操作或者条件判断导致它没执行到默认行为就已经发生了。还有一个容易被忽略的点keydown和keypress的preventDefault()效果不同。在keydown里阻止默认行为可以阻止字符输入到输入框在keypress里阻止只能阻止字符输入但按键本身的其他默认行为可能已经执行了。所以拦截默认行为认准keydown。5.4 常见问题速查表问题现象可能原因排查方向解决方案中文输入法下按键无响应keyCode 变成 229打印 e.key 和 e.code改用 code 判断或配合 composition 事件快捷键在输入框内也触发事件冒泡到 document检查 e.target判断 target 是否为输入框是则 return按住键触发多次keydown 重复触发检查 e.repeat用 e.repeat 或 Set 记录按键状态某些键 keyCode 对不上浏览器差异对比不同浏览器改用 code 属性preventDefault 无效调用时机太晚检查函数执行顺序在处理函数最前面调用Mac 上快捷键失效用的是 ctrlKey检查是否按了 Command用 e.metaKey 或 ctrlKey || metaKey功能键不触发 keypresskeypress 不响应功能键确认事件类型改用 keydown这张表里的每一条都是我在实际项目中真实遇到过的尤其是中文输入法那条当年排查了大半天才定位到原因。6. 现代开发中的键码处理最佳实践6.1 优先使用 code 和 key 的组合策略经过这么多年的演进键盘事件处理的最佳实践已经比较清晰了。我的建议是物理按键判断用code字符输入判断用keykeyCode只在需要兼容非常老的环境时作为降级方案。具体来说做游戏控制、快捷键、功能键响应用code。因为code不受键盘布局、输入法、修饰键影响你按的是哪个物理位置它就返回对应的值稳定可靠。做文本输入相关的判断比如“用户是否输入了数字”用key配合正则判断更直观。// 物理按键判断用 code if (e.code KeyS (e.ctrlKey || e.metaKey)) { e.preventDefault(); save(); } // 字符输入判断用 key if (/^[0-9]$/.test(e.key)) { // 用户输入了数字 }这种组合策略既保证了物理按键判断的稳定性又保证了字符判断的可读性。6.2 封装一个可复用的键盘事件工具在实际项目里键盘事件处理逻辑往往会散落在各个组件中维护起来很痛苦。我通常会封装一个轻量的键盘事件工具统一处理兼容性、修饰键判断和默认行为拦截class KeyboardHelper { constructor() { this.pressedKeys new Set(); this.listeners []; this.init(); } init() { document.addEventListener(keydown, (e) { if (e.repeat) return; this.pressedKeys.add(e.code); this.emit(keydown, e); }); document.addEventListener(keyup, (e) { this.pressedKeys.delete(e.code); this.emit(keyup, e); }); } on(event, callback) { this.listeners.push({ event, callback }); } emit(event, e) { this.listeners .filter(l l.event event) .forEach(l l.callback(e, this.pressedKeys)); } isPressed(code) { return this.pressedKeys.has(code); } registerShortcut(code, modifiers, handler) { this.on(keydown, (e) { if (e.code ! code) return; if (modifiers.ctrl !e.ctrlKey) return; if (modifiers.shift !e.shiftKey) return; if (modifiers.alt !e.altKey) return; if (modifiers.meta !e.metaKey) return; e.preventDefault(); handler(e); }); } }这个工具类封装了按键状态追踪、事件分发和快捷键注册三个核心功能。用起来很简单const kb new KeyboardHelper(); kb.registerShortcut(KeyS, { ctrl: true }, () { console.log(保存); }); kb.registerShortcut(KeyZ, { ctrl: true, shift: true }, () { console.log(重做); });封装成工具类的好处是兼容性处理、重复触发过滤、默认行为拦截这些脏活累活都在一个地方搞定业务代码只需要关心“按了什么键要做什么事”。6.3 移动端外接键盘的注意事项移动端外接键盘蓝牙键盘、iPad 妙控键盘等的键码表现和桌面端基本一致但有几个特殊点需要注意。首先移动端浏览器对键盘事件的响应可能受软键盘状态影响外接键盘连接时软键盘通常不会弹出但事件监听逻辑是一样的。其次某些 Android 设备的外接键盘在keyCode上可能有细微差异用code属性可以规避大部分问题。另外iPadOS 上 Command 键的metaKey行为需要特别测试有些版本的系统对 Command 组合键的处理和 macOS 不完全一致。如果你的应用需要支持 iPad 外接键盘建议在真机上实测一遍所有快捷键。7. 我踩过的那些坑与经验总结7.1 一个真实的中文输入法排查案例前两年做一个搜索框的即时联想功能需求是用户输入时实时请求接口返回联想词。我一开始用keydown监听判断keyCode是否在字母数字范围内是则触发搜索。测试环境一切正常上线后收到用户反馈中文输入法下打字没有联想。排查过程很曲折。我先怀疑是接口问题加了日志发现接口根本没被调用。然后怀疑是事件没触发在keydown里打印keyCode发现中文输入法下按字母键keyCode全是 229。原来输入法激活时浏览器把按键事件标记为“正在组合”keyCode统一变成 229key变成 Process。解决方案是改用input事件代替keydown。input事件在输入框内容真正发生变化时触发不受输入法组合状态影响。这个案例让我深刻认识到键盘事件适合做快捷键和物理按键响应文本输入相关的逻辑input事件才是正解。7.2 快捷键设计的三条经验法则做了这么多带快捷键的项目我总结了三条经验。第一不要占用浏览器和操作系统的常用快捷键CtrlS、CtrlP、CtrlF、CtrlW 这些用户已经形成肌肉记忆的组合你占用了只会让用户烦躁。第二快捷键要有视觉提示用户不可能记住所有快捷键在按钮旁边标注快捷键提示在帮助面板里列出完整列表能大幅提升功能发现率。第三提供快捷键自定义功能不同用户的使用习惯差异很大允许自定义是最友好的做法。7.3 键码对照表的正确使用姿势最后说回键码对照表本身。这张表的价值不在于让你背下来而在于给你一个快速查阅的参考。实际开发中我建议你收藏一个在线的键码检测工具需要的时候按一下键就知道所有属性值比翻表快得多。同时把常用的几个键码记在脑子里——回车 13、Esc 27、空格 32、方向键 37-40、字母 A-Z 对应 65-90这几个覆盖了日常开发 80% 的场景。另外键码值这个东西不同浏览器、不同操作系统、不同键盘布局都可能有差异所以永远不要假设某个键的keyCode在所有环境下都一样。用code属性做物理按键判断用key属性做字符判断把keyCode当作兼容老环境的备胎这个策略能帮你避开绝大多数键盘相关的坑。
1. 键盘事件与键码值的前世今生做前端开发的朋友尤其是经常跟表单、快捷键、游戏交互打交道的大概率都绕不开一个东西——键盘按键的键码值。你可能在某个深夜调一个快捷键功能onkeydown里打印出来的keyCode死活对不上或者用户反馈“我按了回车没反应”结果发现是中文输入法状态下keyCode变成了 229。这些坑我几乎一个不落地全踩过。所谓键码值简单说就是浏览器给键盘上每一个物理按键分配的一个数字身份证。你按下 A 键浏览器告诉你“13 号键被按下了”或者“65 号键被按下了”这个数字就是键码。它最早是伴随 DOM 事件模型一起出现的onkeydown、onkeyup、onkeypress这三个事件构成了键盘交互的基础骨架。其中onkeydown和onkeyup对应“按下”和“抬起”两个动作而onkeypress则是在按下并产生字符输入时触发——注意它不区分大小写也不响应功能键。这套东西看起来简单但真正用起来坑多到能写一本书。不同浏览器对同一个键给出的keyCode可能不一样key、code、keyCode、which这几个属性各有各的脾气再加上输入法、操作系统、外接键盘的差异一个看似简单的“监听回车键”需求背后可能藏着十几条分支逻辑。这篇内容就是把这些年我在实际项目里积累的键码对照经验、事件选型思路、兼容性处理方案系统地整理出来不管你是刚接触键盘事件的新手还是想查漏补缺的老手都能直接拿去用。2. 三个键盘事件到底该用哪个2.1 onkeydown、onkeyup、onkeypress 的本质区别很多人写代码时习惯性地用onkeypress觉得“按键”嘛肯定用 press 最直观。但实际情况是onkeypress正在被现代标准逐步边缘化MDN 上已经明确标注它属于废弃特性。为什么因为它的定位很尴尬——它只在产生可打印字符时触发功能键F1-F12、Shift、Ctrl、方向键等根本不会触发它。你想想用户按了 Shift 想做什么你根本监听不到。onkeydown和onkeyup才是真正覆盖全部按键的事件。onkeydown在按键按下的瞬间触发如果用户按住不放操作系统会以一定的重复速率持续触发这个速率可以在系统设置里调所以它天然适合做“长按加速”这类功能。onkeyup则在松开按键时触发一次适合做“松开停止”的逻辑。我个人的选型原则很简单需要响应所有按键、需要处理组合键、需要做快捷键一律用onkeydown需要精确知道用户什么时候松手用onkeyuponkeypress除非维护老项目新项目里我基本不碰。2.2 事件触发顺序与冒泡机制一次完整的按键操作事件触发顺序是这样的先keydown如果产生了字符输入紧接着keypress最后松手时keyup。如果按住不放keydown和keypress会交替重复触发直到松手才来一次keyup。这里有个容易忽略的点这三个事件都是可以冒泡的。也就是说你在一个输入框上按键盘事件会从输入框一路冒泡到 document甚至 window。很多全局快捷键的实现就是利用这个机制在 document 层面监听keydown然后判断event.target是不是输入框来决定要不要拦截。但反过来如果你不想让某个按键触发全局快捷键就得在输入框的keydown里调用event.stopPropagation()把冒泡掐断。注意keypress在有些浏览器里对退格键、删除键的触发行为不一致这也是我不推荐用它的原因之一。2.3 该监听在哪个元素上监听位置的选择直接影响代码的健壮性。如果你只关心某个输入框的按键直接绑在输入框上最省事。但如果你要做全局快捷键比如“按 CtrlS 保存”绑在 document 上更合适因为用户焦点可能在页面任何位置。不过绑在 document 上有个副作用用户在输入框里正常打字时你的全局快捷键逻辑也会被触发。解决办法是在处理函数开头加一个判断document.addEventListener(keydown, function(e) { const tag e.target.tagName.toLowerCase(); if (tag input || tag textarea || e.target.isContentEditable) { return; // 输入框内的按键不触发全局快捷键 } // 全局快捷键逻辑 });这个判断看起来简单但少了它用户在你页面上的每一次输入都可能触发莫名其妙的快捷键行为体验直接崩掉。3. 键码值核心对照表与属性解析3.1 常用按键 keyCode 速查表下面这张表是我从实际项目中整理出来的高频按键对照涵盖了字母、数字、功能键和常用符号。需要说明的是keyCode的值在不同浏览器和操作系统上可能存在细微差异但下面这些主流值在 Chrome、Edge、Firefox、Safari 上基本一致。按键keyCodekey 值code 值回车 Enter13EnterEnter退格 Backspace8BackspaceBackspace制表 Tab9TabTab空格 Space32空格字符SpaceEsc27EscapeEscape左方向键37ArrowLeftArrowLeft上方向键38ArrowUpArrowUp右方向键39ArrowRightArrowRight下方向键40ArrowDownArrowDownDelete46DeleteDeleteShift16ShiftShiftLeft / ShiftRightCtrl17ControlControlLeft / ControlRightAlt18AltAltLeft / AltRightCaps Lock20CapsLockCapsLockF1112F1F1F2113F2F2F12123F12F12数字 0-948-570-9Digit0-Digit9字母 A-Z65-90a-z 或 A-ZKeyA-KeyZ分号 ;186; 或 :Semicolon等号 187 或 Equal逗号 ,188, 或 Comma减号 -189- 或 _Minus句号 .190. 或 Period斜杠 /191/ 或 ?Slash反引号 192 或 ~Backquote左方括号 [219[ 或 {BracketLeft反斜杠 \220\ 或 |Backslash右方括号 ]221] 或 }BracketRight单引号 222 或 Quote这张表里有个细节值得注意字母键的keyCode是大写字母的 ASCII 码A 是 65Z 是 90跟是否按下 Shift 无关。也就是说你按小写 a 和大写 AkeyCode都是 65。这也是为什么很多老代码用keyCode判断字母时不需要区分大小写。3.2 key、code、keyCode、which 到底有什么区别这是键盘事件里最容易混淆的一组属性我见过不少工作两三年的开发者还在用which然后被兼容性问题折磨得死去活来。逐个说清楚keyCode是历史遗留属性返回一个数字。它的值取决于按下的物理键但不同浏览器对某些键的映射不一致。比如分号键Chrome 返回 186某些旧版 Firefox 可能返回 59。它已经被标记为废弃但出于兼容性考虑目前所有主流浏览器仍然支持。which是更古老的属性本质上就是keyCode或charCode的别名同样废弃。新项目里没有任何理由再用它。key是现代标准属性返回一个字符串。它的值考虑了修饰键的状态——你按 a 返回 a按 Shifta 返回 A按回车返回 Enter。这个属性可读性最好但有个坑它受键盘布局和输入法影响。同一个物理按键在中文输入法激活状态下key可能返回 Process 而不是实际字符。code也是现代标准属性返回一个字符串表示物理按键的位置。它不受键盘布局和修饰键影响KeyA 永远是 KeyA不管你是按的 a 还是 A也不管你用的是 QWERTY 还是 Dvorak 布局。做游戏控制、快捷键这类需要精确识别物理按键的场景code是最可靠的选择。我的建议很明确新项目优先用code做物理按键判断用key做字符输入判断keyCode只在需要兼容极老环境时作为兜底。3.3 修饰键与组合键的键码表现修饰键Shift、Ctrl、Alt、Meta比较特殊它们自己触发keydown时keyCode分别是 16、17、18、91或 93。但更重要的是当它们和其他键组合按下时事件对象上的shiftKey、ctrlKey、altKey、metaKey这几个布尔属性会变成 true。比如你要实现 CtrlS 保存不应该去判断keyCode 83 ctrlKey更稳妥的写法是document.addEventListener(keydown, function(e) { if (e.ctrlKey e.code KeyS) { e.preventDefault(); // 阻止浏览器默认的保存页面行为 // 执行自定义保存逻辑 } });这里e.preventDefault()非常关键。浏览器对很多组合键有默认行为CtrlS 是保存网页CtrlP 是打印F5 是刷新。你不阻止默认行为用户按下去页面就刷新了你的逻辑根本没机会执行。注意Mac 上对应的是 Command 键事件属性是metaKey。做跨平台快捷键时通常写成(e.ctrlKey || e.metaKey)来同时兼容 Windows 和 Mac。4. 实战从零实现一个键码检测工具4.1 页面结构与交互设计光看对照表记不住最好的学习方式是自己动手做一个键码检测页面。这个工具的逻辑很简单监听键盘事件把keyCode、key、code、which以及修饰键状态实时显示出来。页面结构用最朴素的 HTML 就行一个展示区域加一个清空按钮div idoutput p按下任意键查看键码信息/p /div button idclearBtn清空记录/button展示区域用来追加每次按键的信息清空按钮方便重新开始。这个工具虽然简单但调试键盘相关功能时特别有用——你不需要猜某个键的keyCode是多少按一下就知道。4.2 事件监听与数据采集逻辑核心逻辑就是监听keydown事件把事件对象上的关键属性提取出来const output document.getElementById(output); const clearBtn document.getElementById(clearBtn); document.addEventListener(keydown, function(e) { const info { keyCode: e.keyCode, which: e.which, key: e.key, code: e.code, shift: e.shiftKey, ctrl: e.ctrlKey, alt: e.altKey, meta: e.metaKey }; const line document.createElement(p); line.textContent keyCode: ${info.keyCode} | which: ${info.which} | key: ${info.key} | code: ${info.code} | Shift: ${info.shift} | Ctrl: ${info.ctrl} | Alt: ${info.alt} | Meta: ${info.meta}; output.appendChild(line); }); clearBtn.addEventListener(click, function() { output.innerHTML p按下任意键查看键码信息/p; });这段代码跑起来后你按任意键页面上就会实时显示这个键的所有属性值。我建议你拿它去测试几个特殊场景中文输入法激活时按字母键、按住 Shift 再按字母、按 F 系列功能键、按方向键。你会直观地看到keyCode和key在不同场景下的变化规律。4.3 输入法状态下的键码陷阱中文输入法是个大坑。当输入法处于激活状态时你按字母键keydown事件的keyCode会变成 229key会变成 Process。这意味着如果你用keyCode判断用户是否按了某个字母键在中文输入法下会完全失效。这个问题的根源在于输入法需要拦截按键来做候选词处理浏览器收到的是一个“正在处理中”的信号而不是具体的字符。解决办法有两个方向一是用code属性代替keyCode因为code反映的是物理按键位置不受输入法影响。你按 A 键不管输入法是否激活code都是 KeyA。二是监听compositionstart和compositionend事件在输入法组合期间不做按键判断等组合结束后再处理。这个方案适合需要精确处理文本输入的场景。let isComposing false; document.addEventListener(compositionstart, function() { isComposing true; }); document.addEventListener(compositionend, function() { isComposing false; }); document.addEventListener(keydown, function(e) { if (isComposing) return; // 输入法组合期间忽略按键 // 正常按键处理 });我实测下来对于快捷键类需求直接用code最省心对于文本输入类需求配合 composition 事件处理最稳妥。5. 常见兼容性问题与排查实录5.1 不同浏览器键码差异速查虽然现代浏览器在键码上已经高度统一但仍有几个历史遗留的差异点需要留意。下面这张表整理了我实际遇到过的差异情况按键Chrome/EdgeFirefoxSafari建议方案分号 ;186186186用 code: Semicolon等号 187187187用 code: Equal减号 -189173189用 code: Minus逗号 ,188188188用 code: Comma句号 .190190190用 code: Period斜杠 /191191191用 code: SlashMeta 键9122491用 metaKey 属性判断可以看到减号键在 Firefox 上的keyCode是 173和其他浏览器的 189 不一样。这就是为什么我一直强调能用code就用codekeyCode只作为最后的兜底方案。5.2 按键重复触发的处理策略用户按住某个键不放时keydown会以系统设定的重复速率持续触发。这个行为在有些场景下是需要的比如游戏里的方向移动、文本编辑器里的连续删除。但在另一些场景下是灾难比如“按一次 CtrlS 保存一次”如果用户手抖按住不放可能会触发几十次保存请求。处理按键重复有两种思路。第一种是记录按键状态在keydown时检查是否已经按下如果是则忽略const pressedKeys new Set(); document.addEventListener(keydown, function(e) { if (pressedKeys.has(e.code)) return; // 已经按下忽略重复触发 pressedKeys.add(e.code); // 执行按键逻辑 }); document.addEventListener(keyup, function(e) { pressedKeys.delete(e.code); });第二种是直接判断事件对象的repeat属性现代浏览器都支持document.addEventListener(keydown, function(e) { if (e.repeat) return; // 这是重复触发忽略 // 执行按键逻辑 });e.repeat方案更简洁我一般优先用它。但要注意如果你的逻辑需要响应长按比如长按加速就不能忽略重复触发反而要利用它。5.3 快捷键冲突与默认行为拦截浏览器和操作系统层面预定义了大量快捷键你的自定义快捷键很可能和它们撞车。常见的冲突包括CtrlS保存页面、CtrlP打印、CtrlF页内查找、CtrlD收藏、F5刷新、F12开发者工具、CtrlW关闭标签页等。对于可以拦截的快捷键用e.preventDefault()阻止默认行为即可。但有些快捷键是浏览器级别的比如 CtrlW 关闭标签页preventDefault()也拦不住。这种情况下只能换一个不冲突的组合比如用 CtrlShiftS 代替 CtrlS。注意preventDefault()必须在事件处理函数的最前面调用如果前面有异步操作或者条件判断导致它没执行到默认行为就已经发生了。还有一个容易被忽略的点keydown和keypress的preventDefault()效果不同。在keydown里阻止默认行为可以阻止字符输入到输入框在keypress里阻止只能阻止字符输入但按键本身的其他默认行为可能已经执行了。所以拦截默认行为认准keydown。5.4 常见问题速查表问题现象可能原因排查方向解决方案中文输入法下按键无响应keyCode 变成 229打印 e.key 和 e.code改用 code 判断或配合 composition 事件快捷键在输入框内也触发事件冒泡到 document检查 e.target判断 target 是否为输入框是则 return按住键触发多次keydown 重复触发检查 e.repeat用 e.repeat 或 Set 记录按键状态某些键 keyCode 对不上浏览器差异对比不同浏览器改用 code 属性preventDefault 无效调用时机太晚检查函数执行顺序在处理函数最前面调用Mac 上快捷键失效用的是 ctrlKey检查是否按了 Command用 e.metaKey 或 ctrlKey || metaKey功能键不触发 keypresskeypress 不响应功能键确认事件类型改用 keydown这张表里的每一条都是我在实际项目中真实遇到过的尤其是中文输入法那条当年排查了大半天才定位到原因。6. 现代开发中的键码处理最佳实践6.1 优先使用 code 和 key 的组合策略经过这么多年的演进键盘事件处理的最佳实践已经比较清晰了。我的建议是物理按键判断用code字符输入判断用keykeyCode只在需要兼容非常老的环境时作为降级方案。具体来说做游戏控制、快捷键、功能键响应用code。因为code不受键盘布局、输入法、修饰键影响你按的是哪个物理位置它就返回对应的值稳定可靠。做文本输入相关的判断比如“用户是否输入了数字”用key配合正则判断更直观。// 物理按键判断用 code if (e.code KeyS (e.ctrlKey || e.metaKey)) { e.preventDefault(); save(); } // 字符输入判断用 key if (/^[0-9]$/.test(e.key)) { // 用户输入了数字 }这种组合策略既保证了物理按键判断的稳定性又保证了字符判断的可读性。6.2 封装一个可复用的键盘事件工具在实际项目里键盘事件处理逻辑往往会散落在各个组件中维护起来很痛苦。我通常会封装一个轻量的键盘事件工具统一处理兼容性、修饰键判断和默认行为拦截class KeyboardHelper { constructor() { this.pressedKeys new Set(); this.listeners []; this.init(); } init() { document.addEventListener(keydown, (e) { if (e.repeat) return; this.pressedKeys.add(e.code); this.emit(keydown, e); }); document.addEventListener(keyup, (e) { this.pressedKeys.delete(e.code); this.emit(keyup, e); }); } on(event, callback) { this.listeners.push({ event, callback }); } emit(event, e) { this.listeners .filter(l l.event event) .forEach(l l.callback(e, this.pressedKeys)); } isPressed(code) { return this.pressedKeys.has(code); } registerShortcut(code, modifiers, handler) { this.on(keydown, (e) { if (e.code ! code) return; if (modifiers.ctrl !e.ctrlKey) return; if (modifiers.shift !e.shiftKey) return; if (modifiers.alt !e.altKey) return; if (modifiers.meta !e.metaKey) return; e.preventDefault(); handler(e); }); } }这个工具类封装了按键状态追踪、事件分发和快捷键注册三个核心功能。用起来很简单const kb new KeyboardHelper(); kb.registerShortcut(KeyS, { ctrl: true }, () { console.log(保存); }); kb.registerShortcut(KeyZ, { ctrl: true, shift: true }, () { console.log(重做); });封装成工具类的好处是兼容性处理、重复触发过滤、默认行为拦截这些脏活累活都在一个地方搞定业务代码只需要关心“按了什么键要做什么事”。6.3 移动端外接键盘的注意事项移动端外接键盘蓝牙键盘、iPad 妙控键盘等的键码表现和桌面端基本一致但有几个特殊点需要注意。首先移动端浏览器对键盘事件的响应可能受软键盘状态影响外接键盘连接时软键盘通常不会弹出但事件监听逻辑是一样的。其次某些 Android 设备的外接键盘在keyCode上可能有细微差异用code属性可以规避大部分问题。另外iPadOS 上 Command 键的metaKey行为需要特别测试有些版本的系统对 Command 组合键的处理和 macOS 不完全一致。如果你的应用需要支持 iPad 外接键盘建议在真机上实测一遍所有快捷键。7. 我踩过的那些坑与经验总结7.1 一个真实的中文输入法排查案例前两年做一个搜索框的即时联想功能需求是用户输入时实时请求接口返回联想词。我一开始用keydown监听判断keyCode是否在字母数字范围内是则触发搜索。测试环境一切正常上线后收到用户反馈中文输入法下打字没有联想。排查过程很曲折。我先怀疑是接口问题加了日志发现接口根本没被调用。然后怀疑是事件没触发在keydown里打印keyCode发现中文输入法下按字母键keyCode全是 229。原来输入法激活时浏览器把按键事件标记为“正在组合”keyCode统一变成 229key变成 Process。解决方案是改用input事件代替keydown。input事件在输入框内容真正发生变化时触发不受输入法组合状态影响。这个案例让我深刻认识到键盘事件适合做快捷键和物理按键响应文本输入相关的逻辑input事件才是正解。7.2 快捷键设计的三条经验法则做了这么多带快捷键的项目我总结了三条经验。第一不要占用浏览器和操作系统的常用快捷键CtrlS、CtrlP、CtrlF、CtrlW 这些用户已经形成肌肉记忆的组合你占用了只会让用户烦躁。第二快捷键要有视觉提示用户不可能记住所有快捷键在按钮旁边标注快捷键提示在帮助面板里列出完整列表能大幅提升功能发现率。第三提供快捷键自定义功能不同用户的使用习惯差异很大允许自定义是最友好的做法。7.3 键码对照表的正确使用姿势最后说回键码对照表本身。这张表的价值不在于让你背下来而在于给你一个快速查阅的参考。实际开发中我建议你收藏一个在线的键码检测工具需要的时候按一下键就知道所有属性值比翻表快得多。同时把常用的几个键码记在脑子里——回车 13、Esc 27、空格 32、方向键 37-40、字母 A-Z 对应 65-90这几个覆盖了日常开发 80% 的场景。另外键码值这个东西不同浏览器、不同操作系统、不同键盘布局都可能有差异所以永远不要假设某个键的keyCode在所有环境下都一样。用code属性做物理按键判断用key属性做字符判断把keyCode当作兼容老环境的备胎这个策略能帮你避开绝大多数键盘相关的坑。
