键盘 keyCode 速查
开关打开后按下任意键实时读 e.key、e.code 与 keyCode，也可按键名或数字查表。
这是一张内置的键盘事件对照表：每个物理键一行，列出键名、未加 Shift 与加 Shift 的 e.key、e.code，以及已废弃的 legacy keyCode/which。表里的每个「坑」都有出处：e.key/e.code 的取值按 W3C UI Events 的 key/code 两份规范表（含 Keyboard events and usability 一节），keyCode/which 一列是 MDN 记录的历史事实值且整个属性已被规范废弃。
媒体/音量/亮度键与日文假名、韩文 Hanja、全半角切换等输入法键标注为「不保证」：那些数字（174/176/229/VK 21/25/240 一带）来自旧 IE 与 Windows VK 表，现代浏览器多半只给 0 或 Process；本页也不保证你手上那台设备/浏览器组合一定按表中值上报——标注「不保证」的行正是分歧区。捕获要你主动开：点「开始捕获」才把 keydown 挂到 window 的捕获阶段。它只把最近一次按键的六个字段覆盖式地显示出来，不是按键历史列表，也不做在线按键测试的计时、连击与统计；输入与按键都只写进本页的文本节点，不出浏览器。本页没有登录、收藏与一键复制。折叠只影响显示：收起的分组行仍在 DOM 里（源码与脚本都拿得到），但不参与渲染，浏览器页内查找 Ctrl+F 搜不到收起分组里的文字，要先展开或点「展开键表分组」。
键盘 keyCode 速查怎么用
- 混合格式查询：查询框一行里可以同时写 Enter、13、KeyA、/、退格，用空格、逗号、顿号或分号（全角半角都行）分隔；数字优先按 keyCode 解释，单个数字字符（如 5）会同时给出「keyCode 5 没有历史值」与「数字 5 键」两种命中。8 会同时命中 Backspace 与数字 8 的字符解释。一个词都没命中时出红色提示条并回显没匹配上的词，部分没命中时出灰色提示条列出未匹配的那几个词（最多五个）。「填入示例」把注册在案的示例查询写进框里，「清空查询」回到整表口径。
- 整表分组与「最多行数」：查询框留空就是整张表 133 行：先按「最多行数」（默认 60、可填 10–300、步长 10）截断，再按 group 折成分组块，默认 60 行列出 4 组、功能键那组的 summary 写着「12 / 24 行」；上限要填到不小于 133（整表行数，10–300 里随便一个够大的值都行）才能一次列全 10 组。summary 上的两段数字是「本次列出 / 该组在整表里的行数」，后者不受上限影响；读数行写明总行数、显示行数、被截掉的行数与当前组数，行首的关键词只回声前 40 个字、超出写作「…（共 N 字）」，所以往查询框里粘一大段文本也不会把这行摘要撑成几屏（下载的 .txt 首行仍是完整关键词）；「展开键表分组」「收起键表分组」两颗按钮负责一键开关（这两颗只管键表的分组，不管组合键写法那一节）。「下载 .txt」导出的是同一份视图，所以这颗上限和查询框里的关键词一起决定文件里有多少行；结果为空时那颗按钮本身是隐藏的。导出正文的首行写明是查询命中多少行还是整表多少行、本次实际导出多少行，所以过滤框里的关键词和「最多行数」都会反映到文件里，列顺序与页面一致（键名、e.key、Shift+e.key、e.code、keyCode/which、分组、说明，Tab 分隔）。
- 开启按键捕获：点「开始捕获」（出厂关着，关着时页面上根本没有 keydown 监听），此后按下的键覆盖式地写进六格读数：e.key、e.code、keyCode、which、location、isComposing，加 Ctrl/Shift/Alt/Meta 四颗修饰键的按下或松开，末行说明这次按键命中表里哪几行——命中行标底色、所在分组自动展开，标题旁写明已记录几次。焦点在输入控件里、e.repeat 的重复事件与 Ctrl/⌘+K、Ctrl/⌘+T/W/N、F11、⌘+字符这类保留组合键都不记录，末行会写明跳过原因；页面不 preventDefault 任何键，也不改变焦点——焦点在 input/textarea/select 或可编辑区域里一律不记录，所以你在这页查询框里敲回车不会被当成「查 Enter」。点「停止捕获」监听器真的被摘掉。表尾「常用组合键写法与坑」那一节现在常驻、默认收起，点开就是跨平台修饰键写法（ctrlKey||metaKey）、用 e.code 绑定物理键、isComposing 挡住输入法合成期的误触发，以及哪些键浏览器根本不让页面拦。
- 表覆盖哪些键：覆盖 a–z（keyCode 就是大写 ASCII 65–90，与 Shift 无关）、0–9 与其 Shift 变体 !@#$%^&*()、美式布局全部标点符号（含 IntlBackslash）、F1–F24（F13 以后没有标准 keyCode，浏览器普遍报 0）、左右修饰键与 AltGraph、Home/End/PgUp/PgDn/方向键、Insert/Delete/Backspace/Enter/Tab/Esc/Space/CapsLock/NumLock/ScrollLock/PrintScreen/Pause、小键盘数字与四则运算键（NumpadEnter 与主 Enter 的 keyCode 相同、只有 code 能区分）。
- 整表分组与每组行数：整张表 133 行按 group 分成 10 组（字母 26、数字 10、符号 12、功能键 24、修饰键 10、导航键 8、编辑键 12、数字小键盘 16、媒体/音量 8、输入法 7），每组一个原生折叠块，默认全部收起。「最多行数」是整表/查询结果级别的截断，先截断再分组。
常见问题
keyCode 为什么是 0、-1，或者干脆不报？
keyCode/which 的取值表来自 IE/Netscape 时代，只覆盖当时常见的键：F13 以上、AltGraph、媒体键、iOS Safari 的部分 Meta 场景都没有历史编码，浏览器按 0 上报，个别旧 Android WebView 给 -1，同一个 16 还区分不了左右 Shift。这正是规范把它废弃的原因——新代码请改用 e.key（要字符）或 e.code（要物理键），本页 keyCode 列只作读旧代码与旧库时的对照。
e.key 和 e.code 到底该用哪个？
判断「用户打出了什么字符」（回车、Esc、方向键、文本处理）用 e.key；做「固定物理键的快捷键」（游戏 WASD、Ctrl+Shift+K）用 e.code，因为它与布局无关——AZERTY 键盘上印 A 的键位 e.code 仍是 KeyQ，用 e.key 会让法语用户的快捷键失灵。注意 Shift 会改变 e.key 而不改变 e.code，所以快捷键判断别拿 e.key 比大写字母。两者都不能可靠表达输入法合成中的文本，那要听 input/composition 事件。
为什么我按键盘得到的是 Process 或 229？
那是输入法（IME）正在处理这次按键的信号：中文拼音候选期间按下的键，e.key 报 Process、legacy keyCode 恒为 229，具体字符要等合成结束才确定。写快捷键回调时开头加 `if (e.isComposing || e.keyCode === 229) return;` 是 MDN 文档给出的经典防御（keyCode 判据仅作兜底，因为它已废弃），根治办法是监听 compositionstart/end 与 input 事件而不是猜按键。
输入法、死键与 iOS Safari 会给出什么读数？
中文输入法下 e.key 常显示 Process、legacy keyCode 恒为 229，重音死键第一下报 Dead，e.code 与键盘布局无关（AZERTY 的 Q 位仍叫 KeyQ），iOS Safari 对部分键不报 keyCode。
「常用组合键写法与坑」那一节讲了什么？
表下面有一节常驻的「常用组合键写法与坑」折叠（默认收起，6 条）：Ctrl+C 在输入法合成期间为何失效（isComposing 与 keyCode 229 的经典判据）、监听 Ctrl+Shift+K 的正确写法（用 e.code 不用 e.key，且它撞上 Chrome 保留快捷键）、preventDefault 对浏览器保留快捷键（Ctrl+T/Ctrl+W 等）无效、Mac 的 Meta 是 ⌘ 而 Windows 是 ⊞——以前那个「附常用组合键写法」开关没有了。
对应功能编号 #91无需安装，手机端同样可用按 Ctrl + K 换工具