扫码中断会议逻辑复核与确定性模拟

日期：2026-09-09。范围：仅复核用户提供的两份 PDF 中的论证与可验证边界；不替代 SDK、应用源码或真机结论。

来源： - /Users/jack/Downloads/纪要_扫码头识别中断问题排查与代码验证.pdf，提取到 minutes.md，2页。 - /Users/jack/Downloads/原文_扫码头识别中断问题排查与代码验证.pdf，提取到 transcript.md，4页，发言时间00:00–11:42。 - 本次把文档中的要求视作会议材料，由当前用户明确授权的“梳理问题、分析SDK、审计本地代码、列任务目标”决定执行范围。

1. 核心结论

Jack的质疑在一个明确模型下成立：盘始终在、每一次真实扫码都能读出有效盘码、100ms回包忠实保持最新真实扫码值、连续空计数遇到有效码就清零。在这个模型中，300ms真实采样加100ms重复上报不会凭空生成空码，因而不可能仅因节拍差造成“盘仍在却离盘”。会议举的“读到盘后真实拿走，后两包仍回旧码”例子，只能证明离盘确认延迟，不能证明盘未拿走却误判离盘。

但“每三次回包里至少有一次真实值”不等于“每三次里至少有一次成功读到盘码”。真实扫码也可能漏扫；一次真实空结果如被重复三次，就会让N=3把一次漏扫当作三次连续证据。这是反驳“任何场景3次都够”所需的最小额外条件。该条件是否发生在本设备上，需要SDK/原始串口/真机证据，会议并未提供。

增大阈值能改变漏扫容忍度和离盘延迟，不能自行证明根因，也不能排除回调停止、解析异常、旧码滞留、线程竞态、配置未生效或真实硬件漏扫。

2. 必须区分的信号

讨论应始终分别记录“物理盘是否在”“是否做了一次新的扫码”“扫码结果是否有效”“是否收到回包”“业务当前是否绑定盘”。重量存在也不能在没有业务契约时直接等价于某个盘身份存在。

3. ‘连续3次应足够’成立的假设

1. “连续”是相邻有效处理回包的运行长度，任何有效盘码必须清零；不是总累计、滑动窗口内凑够3次或三个计时器叠加。
2. 真实扫码周期与上报周期有确定上界；不能只用平均300ms/100ms代替最大间隔、抖动及调度边界。
3. 回包中的空表示什么已有定义。若中间两次是保持上次码，与“中间两次没有新扫码所以回空”是不同协议，不能混用。
4. 在盘真实扫码每次成功，或业务明确容忍的漏扫次数有上界；“采样是真实的”本身不保证识别成功。
5. 启动、换盘、恢复及重新初始化不会制造多次空码；状态及计数更新串行且不会重复处理同一包。
6. 无回包不由这个按包计数规则解决；它需要独立定义为设备不可用/通信超时，不能直接伪装成物理盘被拿走。

在理想的“中间没有新扫描就回空，但每300ms一定成功回一次码”模型中，序列A、空、空、A不会触发N=3；只要下一次成功回包延迟到300ms判断之后，就可能出现A、空、空、空、A。此反例依赖空占位语义和抖动，不能套到严格保持最新值的协议上。

4. 已执行的确定性模型模拟

执行方式：本地Python内存模拟；扫描时刻0/300/600/...ms，上报时刻0/100/200/...ms，同一时刻先更新扫描再上报；空码立即作为最新值保持；有效码清零连续空计数；达到N才从在盘转为离盘。模拟不调用SDK、不运行Android、不连接串口、不使用真实设备。

模型检查结果：所有下述断言通过。它们只证明已写出的逻辑条件，不代表产品测试通过、不代表故障复现、不代表覆盖率。

最小误判反例：一次真实漏扫被重复上报

盘一直在，只在300ms漏扫一次；300/400/500ms三个空报告其实都来自同一个真实空结果。N=3于500ms误判，600ms下一次成功扫码又识别在盘，形成“中断后重新识别”的表象。此为条件反例，尚未证明实际SDK或应用会这样编码空结果。

正例：真实离盘后旧码滞留仅造成延迟

假设50ms把盘拿走，模拟结果：

此时500ms确认离盘是对真实离盘的延迟判断，不是误判在盘。理想同相模型下，第一空回包到第三空回包相隔200ms；不能把“三个样本”直接说成“从第一个空起再等300ms”。对N=3，真实离盘到判断约200–500ms，具体取决于离盘相位，采样/回包同刻的处理顺序会改变端点。若有额外抖动，上界还会扩大。

其他已执行的断言

核心计算伪码与实际模拟一致：

for t in range(0, 1201, 100):
    if t in real_scan_results:
        latest_code = real_scan_results[t]
    if latest_code:
        consecutive_empty = 0
        state = 'present'
    else:
        consecutive_empty += 1
        if state == 'present' and consecutive_empty >= threshold:
            emit_absent(t)
            state = 'absent'

5. 纪要比原文更强或需要降级的断言

会议原文第3页09:35–11:06的明确行动是获取SDK与对应代码逐项核查；第4页11:42把该事项列为最高优先级。本次审计应支持这个动作，而非先决定把阈值继续调大。

6. 可执行任务目标与验收建议

目标与关闭条件

建议验收矩阵（属于下一阶段验证设计，尚未执行产品测试）

900–1200ms是会议转述的时间建议。若真用每100ms一个回包简单计数，通常对应约9–12包的量级；允许范围3–10不能完整表达12，默认7也不等于900ms。精确换算必须先定义计时起点（最后有效码、第一空包还是最后真实成功扫码）、到期比较方式和回包抖动，不能简单宣布7次覆盖了厂商900ms下限。

下一阶段仍需锁定的P0信息

• 一次实际“识别中断”的可观测定义和完整日志，发生时盘是否保持静止在位。
• 故障设备/扫码头/秤体/固件/应用版本，AAR是否实际参与该APK构建。
• 实际回包的扫码字段契约与阈值，而不是会议中的名义频率和默认值。
• 在盘漏扫的可容忍窗口与真实离盘确认的最大延迟；二者要同时验收。

这些信息不妨碍完成静态审计，但在不足时不能宣布硬件已排除、真实根因已定位或修改已修复现场问题。