EAN-13 追溯：重复与漏读

目的与适用边界

判断重复出现的解码内容，究竟是同一单件被重复采集，还是确实存在内容相同的产品，同时不丢失任何一次读取失败（no-read）事件。

本教程给出的是一套工程评估方法，而不是开箱即用的产品认证。Deyi Vision 目前公开的 PC 示例，涵盖在已确认的样本图像上运行的 EAN-13 流程。工程代码中涉及原生 OCR 与检测的部分，使用前必须对照已安装的运行环境、已绑定的模型和作业逐项核对。浏览器模板并不能证明已在浏览器中实际运行：规划中的 OpenCV.js 后端需要单独验证。云端识别必须事先明确批准图像范围、服务提供方、模型和费用。评审存档不是可执行的发布包。相机、固件和驱动的兼容性需要各自单独核查。下列示例表中的所有数值均为假设数据，不是 Deyi Vision 的测量结果，也不是客户结果。

准备证据

准备多件连续的、带有相同贸易项目代码的单件，以及一份保存下来的帧回放。独立于条码的解码内容，来定义实物单件事件。写出的失败记录，要让另一位工程师无需猜测用的是哪张图像或哪个版本，就能回放。记录中包括原始来源、受影响区域、实际输出、预期处置，以及第一个出现分歧的中间结果。记录该现象是出现在回放中、实时采集中，还是两者都有。修正之后，重新运行最初的失败案例，以及先前成功的相邻条件。靠排除报警区域，或接受缺失的结果来消除一条报警，这样的修复改变的是需求，并没有解决原因。如果失败仍未解决，应让受影响的操作保持在 Review 或禁止状态并写明原因；不要把未经测试的变通办法标成已验证的解决方案。解码、标识验证、印刷质量验证和单件跟踪应分别记录。EAN-13 值标识的是一种贸易项目，通常由多个实物单件共用；它既不是逐帧序号，也不是唯一序列号。解码成功，并不能证明印刷质量合规、商品主数据正确，也不能证明下游剔除成功。本系列以 EAN-13 作为限定范围的示例，因为这是已确认的公开 PC 评估范围。其他码制、QR 码、直接零件标记和读码器硬件，都需要各自经确认的集成。原始源图像必须保留条、空和静区；仅有裁剪后的显示图或清理过的二值图，不足以作为失败证据。要在追溯数据库中明确规定缺失的帧与无法读取的条码有何区别。从最早可观察到的分歧点开始排查。把同一份保存的源图像分别回放给未做改动的基线版本和候选版本，并比较中间图像、区域、数值和结果状态。如果源图像本身就不同，这一对比就无法再把算法单独隔离出来。每次只改变一个怀疑的原因，运行前先写下预期效果，假设不成立时也要保留这个否定结果。要把证据无法读取、规则不匹配、依赖项缺失和执行故障区分开来，它们需要不同的补救办法。回放可以复现软件故障，但无法验证实时触发、照明时序或实物剔除路径。这些采集和产线方面的检查，应作为单独的后续实验另行进行。

步骤

1. 在对重复的字符串去重之前，先比较采集 ID 和单件事件。
2. 要把 no-read、缺失帧和无效解码内容区分开；每个事件都要检查其原图。
3. 先回放一次保存的采集，以测试幂等接收，再送入多次内容相同的独立真实采集。
4. 用事件标识检查重启和队列顺序；绝不能仅因为 EAN-13 文本相同，就把所有单件去重。

解读试验结果

在这份假设记录中，具有相同 EAN-13 的 4 个不同单件事件，需要 4 条单件记录。1 次采集的重复送达只需要 1 条单件记录，并保留接收历史。EAN-13 指代一种贸易项目，其本身并不是唯一的实物单件序列号。

记录表

两个工程视角

故障排查

• 按解码内容是否唯一来计数，会掩盖合法存在的重复产品。
• 用前一次读取成功的结果顶替缺失的帧，会制造出证据从未建立过的追溯关系。

验收与交接

当每个应出现的单件各有一条终态记录，且回放不会凭空多出一个单件时，可验收事件核算。要把预期触发、收到的图像、no-read 和终态记录逐项对账，期间不得删去失败的事件。

把源图像、预期判定、确切版本和完整的结果记录放在一起保存。在选定最终参数之前，先冻结评估集。如果之后用这些答案来调整工作流，就应把该集合标记为开发数据，并重新取得一个独立的验收集。Review、NoResult、执行错误和采集缺失都要保留在分母中，不得通过筛选行把它们变成合格。除成功样本外，还要保存一个可复现的失败样本。交接时应写明：谁可以更改配方，如何恢复先前已批准的版本，以及在验收之前哪些设备输出仍保持禁止。仅凭软件结果，不能证明移动中的实物工件已到达正确的目的地。