离线扫码与离线查询，表面上只差两个字，技术实现却完全是两个量级。很多企业在评估扫码功能时，把这两者混为一谈，直到项目落地才发现预算和工期都远超预期。搞清楚这条边界，是避免报价陷阱的第一步。
所谓离线扫码，指的是扫描动作本身不依赖网络。摄像头识别条码、解析出数字串，这一过程在本地即可完成，技术门槛并不高。主流做法是集成现成的扫描SDK，iOS自带扫码能力，Android也有开源库可用。如果需求止步于此——扫一下、显示一串数字——开发成本通常能控制在较低区间。问题在于，很多业务场景需要的并不是“扫出数字”，而是“扫出结果”。
离线查询则是另一回事。它要求设备在断网状态下，依然能根据条码返回商品信息、库存状态或价格数据。这意味着条码库必须完整缓存到本地，同时要处理数据更新、冲突合并、断网重连等一系列问题。从架构上看，这不是在在线方案上打一个补丁，而是需要重新设计数据同步机制和本地存储策略。根据行业经验，加入离线能力后，开发周期一般会多出三分之一到二分之一，费用相应水涨船高。
判断一个方案声称的“离线”到底是哪一种，有一个简单的检验方法：问清楚断网时扫码后能看到什么。如果答案是“条码已保存，联网后上传”，那只是离线扫描；如果答案是“能显示商品名称、价格、库存”，才是真正的离线查询。前者代码简单，后者要处理的数据一致性和异常场景复杂得多。部分服务商在报价时刻意模糊这一点，用离线扫描的成本承接离线查询的需求，后期再以变更需求的名义追加费用。
离线查询的技术难点集中在三个层面。其一是数据同步策略，本地缓存与云端数据如何保持一致性，增量更新还是全量替换，这直接决定开发量。其二是冲突处理，同一商品在离线期间被修改，重新联网后以哪份数据为准，需要明确的规则。其三是存储与性能的平衡，条码库规模越大，本地检索速度越慢，对设备性能的要求也越高。这些都不是简单的“调个接口”能解决的问题。
对于仓库盘点、户外巡检、物流中转这类网络不稳定的场景，离线查询是刚需，预算必须按完整方案预留；而对于门店查价、展会登记这类网络条件可控的业务，离线扫描加联网查询往往已经够用。明确自己的业务到底卡在哪条边界上，比反复比价更能避免后续的麻烦。
