扫码枪默认工作在HID Keyboard模式，插上即识别为键盘，将条码模拟为按键事件发送；需用KeyDown捕获完整条码（含自动Enter），避免焦点丢失、误触发等问题。
扫码枪在C#里为什么像键盘一样“打字”
绝大多数USB扫码枪默认工作在HID Keyboard模式，插上就识别为键盘设备——它不走串口或专用驱动，而是把扫出的条码直接模拟成按键事件发给系统。这意味着你不需要写USB通信代码，也不用装额外驱动（Windows自带HID支持），但必须意识到：它和用户手动敲键盘完全没区别。
常见错误现象：TextBox里能显示扫码内容，但焦点一丢就收不到；或者扫码后触发了意外的按钮点击（因为回车被当成Enter键）；又或者多线程UI更新时报InvalidOperationException。
- 扫码枪通常在末尾自动发送
Enter（有些可配置为Tab或无终止符） - 如果目标控件没获得焦点，输入会落到当前激活窗口——比如IDE里正编辑代码，扫码就直接输进.cs文件
- 扫码速度极快（毫秒级），连续扫多个码时，
TextChanged可能被频繁触发，但KeyDown/KeyPress更可靠（能捕获Enter）
用KeyDown事件捕获完整条码（推荐方案）
比起监听TextChanged，用KeyDown或PreviewKeyDown更稳妥：你能明确知道“一串字符+回车”是一次完整扫码动作，还能提前拦截回车防止表单提交。
KeyToChar
- 查说明书用配置码设置终止符（例如扫描“设置回车”条码）
- 若必须无终止符，且需高可靠性，可启用
Raw Input（需P/Invoke注册RegisterRawInputDevices），但开发成本陡增，仅适用于防作弊场景 - 简单替代：加定时器——收到字符后启动100ms倒计时，超时即认为扫码结束（但高速连续扫易误判）
WinForms vs WPF：焦点管理差异很关键
WinForms中TextBox.Focus()调用后未必立即获得焦点（尤其窗体刚Show时），WPF中TextBox.Focus()需配合Keyboard.Focus()才可靠。扫码前务必确认目标控件已真正激活。
容易踩的坑：TextBox.Select()≠Focus()；Loaded事件中调Focus()常失败；后台线程调用Focus()会静默失败。
- WinForms：在
Form.Shown事件中调用textBox.Focus()，并确保textBox.TabStop = true - WPF：用
textBox.Focus(); Keyboard.Focus(textBox);，且绑定到ContentRendered事件 - 通用保险做法：扫码前用
SendKeys.SendWait("{TAB}")（WinForms）或模拟Tab切换（WPF）强制焦点到位
硬件层没有“扫码API”，所有方案都建立在“它假装是键盘”这个事实上——一旦脱离这个前提（比如用RS232串口扫码枪），整套逻辑就得推翻重来。
