KeyboardEvent 的 key 属性返回逻辑输入值而非物理按键字符，反映键盘布局与修饰键作用下的语义结果；获取物理按键应使用 code 与 location 组合。
KeyboardEvent 的 key 属性返回的是按键的**逻辑值（语义值）**，不是物理按键位置，也不能直接代表“物理按键字符”。它反映的是当前键盘布局和修饰键（如 Shift、AltGr）作用下的**输入结果**，而非底层扫描码或键位。因此，严格来说，无法通过 key 获取纯粹的物理按键字符——这是设计使然，也是跨平台一致性的需要。
key 属性的实际行为：语义优先，非物理映射
key 表示用户“意图输入的内容”，受以下因素影响：
- 当前激活的键盘布局（如美式 QWERTY、法语 AZERTY、中文拼音输入法）
- 是否按下 Shift、CapsLock、AltGraph 等修饰键
- 是否处于组合键序列中（如按
'后跟e输入 é） - 某些系统级快捷键（如
Ctrl+Tab）会令key为"Tab"，但实际未触发文本输入
例如：在法语 AZERTY 键盘上，左手边第二行第一个字母键（物理位置同 QWERTY 的 A）标的是 A，但默认按它输出 a；按住 Shift 再按，输出 A；而该键在 QWERTY 上对应 Q。但无论哪种布局，只要最终输入的是小写 a，event.key 就是 "a" —— 它不告诉你“你按了哪个物理位置的键”，只告诉你“你得到了什么字符”。
若需接近物理按键信息：用 code + location 组合
真正反映物理按键的是 code 属性（如 "KeyA"、"Digit1"、"Escape"），它与键盘布局无关，只描述按键在设备上的物理位置。配合 location（0=standard, 1=left, 2=right, 3=numpad）可进一步区分左右 Alt/Ctrl 等。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
示例：
document.addEventListener('keydown', e => {
console.log('物理键位:', e.code); // "KeyA", "Backspace", "NumpadAdd"
console.log('按键区域:', e.location); // 0, 1, 2 或 3
console.log('逻辑输入:', e.key); // "a", "Backspace", "+"
});
注意：code 是稳定可靠的物理标识，但它是字符串标识符（非字符），不能直接当作“字符”使用（如 "KeyA" ≠ "A"）。
特殊场景：输入法（IME）期间 key 值不可靠
在中文、日文等输入法激活状态下（如正在选词），多数按键事件的 key 为 "Process" 或 "Unidentified"，且 code 可能仍有效。此时应监听 compositionstart/compositionupdate/compositionend 事件来处理实际输入内容，而不是依赖 key。
总结：别用 key 获取“物理字符”，按需选择属性
根据你的实际目标选择：
- 想获取用户最终输入的字符？→ 用
event.key（但注意 IME 期间为空或特殊值） - 想识别用户按下了哪个物理按键（如游戏控制、快捷键绑定）？→ 用
event.code+event.location - 想兼容旧浏览器或需更底层信息？→ 结合
event.keyCode（已废弃，不推荐）或使用getKeyboardLayoutMap()（实验性，支持有限） - 想捕获真实文本输入（含粘贴、IME）？→ 监听
input事件，读取target.value或event.data
HTML5 规范有意将“物理按键”和“逻辑输入”分离，key 的定位就是语义化输入结果。试图用它反推物理键位，既不符合标准，也难以跨平台可靠实现。
