浏览器无法区分标准键盘上两个回车键（主键盘区 Enter 与小键盘区 Enter）所触发的事件，二者均统一报告为 key: "Enter" 和 code: "Enter"，无可靠 API 支持辨别。此限制源于操作系统与浏览器对按键事件的标准化抽象。
浏览器无法区分标准键盘上两个回车键（主键盘区 enter 与小键盘区 enter）所触发的事件，二者均统一报告为 `key: "enter"` 和 `code: "enter"`，无可靠 api 支持辨别。此限制源于操作系统与浏览器对按键事件的标准化抽象。
在 Web 开发中，许多场景（如扫码枪输入、表单快速提交）依赖对回车行为的精细化控制。例如，扫码枪通常自动追加一个回车符以模拟人工确认，而用户手动按主键盘 Enter 又需正常触发表单提交——此时若想「仅拦截扫码回车、保留手动回车」，直觉上会尝试通过 e.code、e.location 或 e.key 区分按键物理来源，但现实是：所有主流浏览器（Chrome、Firefox、Safari、Edge）均将两个 Enter 键视为完全等价的输入源。
以下代码验证了该行为：
document.getElementById("test").addEventListener("keydown", (e) => {
if (e.key === "Enter") {
console.log({
key: e.key, // 总是 "Enter"
code: e.code, // 总是 "Enter"
location: e.location, // 可能为 0（standard）或 3（numpad），但不可靠！
which: e.which, // 已废弃，不推荐
keyCode: e.keyCode // 已废弃，且值恒为 13
});
}
});⚠️ 注意：虽然 e.location 在部分浏览器中可能返回 0（标准键盘）、1（左/右 Shift/Ctrl/Alt）、2（数字小键盘）、3（手柄等），但对 Enter 键，e.location 的行为高度不稳定：
- Chrome 120+ 中，无论按哪个 Enter，
e.location均为0； - Firefox 可能返回
2（小键盘）或0（主键盘），但存在兼容性风险与设备差异； - Safari 对
location支持更弱，且该属性已被标记为非标准（MDN 文档 明确提示其不可靠）。
✅ 可行的替代方案（聚焦业务逻辑而非物理按键）：
-
基于输入上下文识别扫码行为：
扫码枪输入通常具有「高速、无间断、固定长度或含特定前缀」特征。可结合input事件 + 时间戳判断是否为“瞬时批量输入”：let lastInputTime = 0; const inputField = document.getElementById("test"); inputField.addEventListener("input", () => { const now = Date.now(); const isScan = (now - lastInputTime) < 50; // 连续输入间隔 < 50ms 视为扫码 lastInputTime = now; if (isScan && inputField.value.endsWith("\n")) { // 拦截扫码后的自动回车：移除末尾换行并阻止默认提交 inputField.value = inputField.value.trimEnd(); // 后续可触发自定义逻辑，如提交表单 } }); 利用扫码枪可配置特性（推荐）：
多数商用扫码枪支持通过扫描配置条码切换「是否发送回车」。可在系统初始化时要求用户扫描一次“禁用回车”配置码，再于关键页面启用「仅手动回车提交」策略——这比前端硬区分更稳定、更符合硬件设计初衷。
? 总结：
不要试图用 keydown 事件区分两个 Enter 键——这是被浏览器规范刻意抹平的底层细节。应转向更高层的语义识别（如输入节奏、内容模式）或协同硬件配置来解决问题。真正的健壮性，来自接受平台限制，并在应用层构建适应性逻辑。
