浏览器无法可靠区分主键盘 Enter 与数字小键盘 Enter 键，所有 keydown/keypress/input 事件均将其统一报告为 e.key === "Enter"，且 e.code、e.location 等属性在主流浏览器中实际不可用或行为不一致。
浏览器无法可靠区分主键盘 enter 与数字小键盘 enter 键，所有 `keydown`/`keypress`/`input` 事件均将其统一报告为 `e.key === "enter"`，且 `e.code`、`e.location` 等属性在主流浏览器中实际不可用或行为不一致。
在 Web 开发中，许多用户（尤其是仓库、零售等场景）使用条码扫描枪向 输入数据。这类设备通常将扫描结果后自动追加一个回车符（即模拟一次 Enter 按键），以触发表单提交或焦点切换。问题在于：标准键盘本身存在两个物理 Enter 键（主键盘区下方的 Enter 和右侧数字小键盘区的 Enter），而开发者常希望「仅拦截扫描枪触发的 Enter，保留用户手动按 Enter 的交互逻辑」——但遗憾的是，浏览器层面无法通过事件属性可靠区分这两个按键的来源。
尽管 KeyboardEvent 规范定义了 e.location（如 DOM_KEY_LOCATION_STANDARD 或 DOM_KEY_LOCATION_NUMPAD）和 e.code（如 "Enter" vs "NumpadEnter"），但现实兼容性极差：
- Chrome、Edge、Firefox 对
e.code的支持不稳定，多数情况下均返回"Enter"； -
e.location在绝大多数 Enter 事件中返回0（DOM_KEY_LOCATION_STANDARD），即使来自小键盘； - 条码扫描枪发出的 Enter 本质上是 HID 层级的键盘事件，其行为完全等同于真实按键，浏览器无从识别“是否来自外设”。
因此，你提供的 JSFiddle 中观察到的现象是符合规范的：无论按下哪个 Enter 键，e.key 始终为 "Enter"，e.code 多数为 "Enter"，e.location 几乎不可靠。
✅ 可行的替代方案（推荐）：
-
基于输入时机与内容特征过滤
条码扫描通常具有明显特征：输入极快（毫秒级完成）、内容为纯数字/固定长度、末尾紧接 Enter。可结合input+keydown实现轻量拦截：
~
- 不要依赖
e.keyCode或e.which（已废弃）； - 避免监听
submit事件做 Enter 过滤，因submit已无法追溯原始按键来源； - 移动端无数字小键盘，该问题不存在，但需额外处理软键盘回车逻辑；
- 若业务允许，优先采用扫码 SDK（如 QuaggaJS、ZXing Browser）接管扫码流程，绕过键盘事件。
综上，这不是代码缺陷，而是浏览器安全模型与输入抽象层级决定的限制。务实解法是转向行为识别（时间+内容）或硬件协同（扫描枪配置），而非尝试区分物理按键。
