扫码枪无法自动监听的根本原因是其作为hid键盘设备不触发标准dom事件流，需用plus.key.addeventlistener监听keydown事件并自实现缓存与结束符识别逻辑。
扫码枪输入无法自动监听，根本原因是它不触发标准 DOM 事件流；必须绕过 @input，改用原生键盘事件或广播机制捕获。
为什么 @input 和 @confirm 经常失效
扫码枪本质是 HID 键盘设备，输入速度远超手动敲击（通常在 10–30ms 内完成一串字符 + 回车），导致：
-
@input频繁触发但无法判断是否“扫完”，v-model值可能只更新一半 -
@confirm依赖扫码枪配置了回车符（\r或\n），而很多工业扫码枪默认关闭该功能，或输出的是\t、无结束符 - H5 环境下
document.addEventListener('keyup')在某些安卓 WebView 中不可靠，尤其在软键盘弹出后 - APP-PLUS 平台中
input失焦时，plus.key监听会中断，造成漏扫
APP-PLUS 下必须用 plus.key.addEventListener
这是目前唯一稳定监听扫码枪原始按键流的方式，适用于无输入框、多输入框切换、后台持续扫码等场景。
- 监听时机：在
onLoad或onShow中注册，onHide或onUnload中removeEventListener，否则内存泄漏或重复触发 - 推荐用
keydown而非keyup：部分扫码枪松键极快，keyup可能丢失末尾键码（如回车） - 缓存逻辑必须自己实现：把连续
keyCode拼成字符串，检测到13（回车）、9（Tab）或10（换行）即视为扫码完成 - 防抖不是靠时间，而是靠“非打印字符”：一旦收到
keyCode === 13，立即清空缓存并提交，不等延时
plus.key.addEventListener('keydown', (e) => {
if (e.keyCode === 13 || e.keyCode === 9 || e.keyCode === 10) {
uni.$emit('scan-complete', inputCache.value)
inputCache.value = ''
} else if (e.keyCode >= 48 && e.keyCode
<h3>如何兼容 H5 + APP-PLUS 两种环境</h3>
<p>不能写两套逻辑，得用条件编译 + 统一事件总线收敛入口。</p>
- H5 用
document.addEventListener('keydown')，但需加event.target.tagName !== 'INPUT'过滤掉真实输入框干扰 - APP-PLUS 用
plus.key.addEventListener，注意它不返回keyValue，只保证keyCode可靠（尤其国产扫码枪常映射异常） - 所有扫码结果统一通过
uni.$emit('scan-complete', code)发出，页面用uni.$on订阅，避免耦合具体监听方式 - 务必在
onUnload中uni.$off('scan-complete')，否则页面销毁后仍接收事件
扫码枪没回车？那就自己加超时兜底
有些扫码枪（如部分东大 PDA 或定制盒子）完全不发结束符，只能靠输入节奏判断。
- 记录每次
keydown的Date.now()，若两次按键间隔 > 80ms，认为前一段是完整条码 - 但不能仅靠间隔：要叠加长度校验（如 EAN-13 必须是 13 位，Code128 通常 ≥6），避免误触发
- 超时设为 120ms 较稳妥——太短易切错（如扫描模糊条码时重试），太长影响连续扫码体验
- 该策略仅作 fallback，优先级低于结束符识别；开启前建议先确认扫码枪是否支持固件升级或设置追加 CR
真正难的不是监听，而是区分“扫码完成”和“用户正在慢速输入”。所有基于时间的方案都只是妥协，最稳的路径永远是让扫码枪输出可预测的结束符，并用原生键盘事件兜底。别信“一个 @input 加个防抖就能搞定”的说法，那是在生产环境埋雷。
