扫码枪输入本质是模拟键盘，非串口设备；绝大多数usb扫码枪在windows下默认工作于hid keyboard模式，插上即识别为键盘，将解码后的字符串逐字符以按键事件形式发送至当前焦点控件。
扫码枪输入本质是模拟键盘，不是串口设备
绝大多数 USB 接口的条形码扫描枪在 Windows 下默认工作在 HID Keyboard 模式——它不走 SerialPort，也不需要驱动，插上就当“多了一个键盘”用。你看到的扫码结果，其实是它把解码后的字符串（比如 123456789）以按键形式逐个发送到当前焦点控件。所以想“无焦点读取”，核心不是监听串口，而是全局捕获键盘输入流。
用 SetWindowsHookEx 拦截全局键盘事件（WH_KEYBOARD_LL）
这是最稳定、兼容性较好的方案，适用于 WinForms/WPF/控制台程序，无需焦点控件参与。关键点在于：必须在 UI 线程（或至少是 STA 线程）中安装钩子；钩子回调函数需标记为 static 并用 [UnmanagedFunctionPointer] 声明；扫码枪通常以回车结尾（\r 或 \n），要靠缓冲+终止符识别完整条码。
- 使用
SetWindowsHookEx(WH_KEYBOARD_LL, ...)注册低级键盘钩子，捕获所有按键（包括后台） - 维护一个线程安全的
StringBuilder缓冲区，只追加可打印字符（Keys.A到Keys.Z、数字、部分符号） - 遇到
Keys.Enter或Keys.Return时，清空缓冲并触发BarcodeScanned事件 - 务必在程序退出前调用
UnhookWindowsHookEx，否则可能残留钩子导致系统卡顿 - 注意：Windows 10/11 的“设置 > 隐私 > 输入 > 允许应用访问你的输入数据”需开启，否则钩子收不到按键
扫码枪输出格式不一致？先查说明书或用记事本测试
不同品牌/型号扫码枪默认输出格式差异很大：有的带前后缀（如 [START]123456789[END]\r），有的自动加换行，有的甚至发两次（一次数据一次回车）。别急着写逻辑，先用记事本或 Notepad++ 插入扫码，打开“显示所有字符”看真实字节流。
- 常见干扰字符：
\r（回车）、\n（换行）、\t（制表符）、STX/ETX（ASCII 2/3） - 若扫码后出现乱码，大概率是编码问题——扫码枪一般只输出 ASCII，确保你的缓冲区用
Encoding.ASCII处理 - 某些工业扫码枪支持配置模式（扫特定条码进入设置），可关闭前缀、关闭校验位、统一结尾为
\r - 不要依赖“连续按键间隔小”来判断是否为扫码——人工快速敲键盘也可能触发误判，必须靠终止符或明确前缀
WPF 中避免 PreviewKeyDown 失效的坑
如果只是想让某个 TextBox 接收扫码（有焦点），直接用 PreviewKeyDown 即可。但要注意：WPF 默认会吞掉已处理的按键（e.Handled = true），导致后续绑定或命令失效；更隐蔽的问题是，当 TextBox 被禁用（IsEnabled=false）或只读（IsReadOnly=true）时，PreviewKeyDown 根本不会触发——扫码枪输入照样发生，只是没地方接收。
- 解决方案一：保持 TextBox 可编辑 + 设置
Focusable="True"+ 在PreviewKeyDown中检测e.Key == Key.Enter后立即e.Handled = true并提取文本 - 解决方案二：改用
KeyDown事件（非 Preview），它在焦点控件上仍可捕获，且不受IsReadOnly影响（但IsEnabled=false仍会屏蔽） - 终极保险：结合全局钩子 + 局部 TextBox 监听，钩子负责兜底，TextBox 提供快捷交互路径
真正难的不是拦截，而是区分“扫码输入”和“用户手动输入”。没有物理信号能告诉你这次按键来自扫码枪——只能靠行为特征（速度、终止符、固定长度、前缀）做概率判断。上线前务必用三款以上不同型号扫码枪实测，尤其注意低速扫描、重复扫描、扫描损坏条码等边界情况。
