扫码成功之后，为什么还会查不到零件

扫码其实包含两次理解

质量追溯页面里的扫码按钮看起来很简单：打开摄像头，对准标签，然后找到零件。实际链路包含两个不同问题。第一步是从画面识别文本，第二步是把文本解释成业务字段。摄像头已经读出了内容，查询仍然可能失败，因为标签使用的格式与系统预期不同。

整理项目源码时，这种分层尤其清楚。相机识别负责兼容浏览器能力，载荷解析负责兼容历史编码，两者需要各自的失败处理。

相机识别需要退路

迁移源码副本中，识别流程先尝试浏览器原生的二维码检测能力，并以 JavaScript 解码器作为补充。当原生检测不可用或调用失败时，流程能够切换到后者。

图像处理也没有每一帧都做同样的全量工作。多数轮次处理中央区域并限制图像尺寸，周期性扩大到全画面，并尝试反色识别。这样既照顾用户通常把标签对准中央的习惯，也保留发现偏离中心标签的机会。

这些安排说明的是实现策略，并不能据此宣称所有手机都同样快速。真实效果仍会受摄像头、光线、对焦、标签尺寸和浏览器实现影响。

编码兼容需要明确规则

识别出的文本可能是结构化对象、带参数的链接，也可能只是物料编码和序列号拼成的一行文字。副本中的解析工具分别处理这些形式，并对常见分隔符提供兼容。短数字序列号会按规则补齐位数。

例如，一个虚构标签把物料与序列号用加号连接，另一个使用逗号。如果业务含义相同，解析层可以把它们规范到同一组字段，而无需让相机模块理解这些业务差异。

兼容仍然需要边界。纯数字是否代表序列号，前导零是否有意义，都应由明确规则决定，不能为了提高匹配率随意猜测。原始文本也值得保留，便于解释一次扫描如何变成查询条件。

验证要沿两段链路进行

解析样例通过，只能证明文本规则；页面能打开摄像头，也不能证明真实标签可用。完整验证需要分别覆盖设备识别与业务解析，再检查最终查询行为。

本文依据迁移副本整理，没有重新进行手机摄像头测试。可复用的经验是：把失败定位到具体环节，兼容措施才会准确，用户看到的扫码流程也会更可靠。