条码与RFID混合共存：存量系统的渐进式迁移设计

很少有项目是从一张白纸开始的。更多的时候，你要面对的是一个跑了十年的条码系统、几万张已贴的条码标签，和一群用惯了扫描枪的仓管员。

一、为什么"一刀切"几乎总是失败

RFID项目里最常见的冲动是"一步到位"：新系统上线当天，条码全部作废，资产全部换标。

这个方案在PPT里很漂亮，在现实里通常翻车：

1. 换标窗口不够。 几万件资产逐件撕旧贴新，停产配合、人力排班、误贴换贴，实际工时永远超预估；
2. 标签身份断档。 旧系统用条码号做主键，新系统用EPC，两套编号没有建立映射就切换，历史履历全部悬空；
3. 人员肌肉记忆被强拆。 扫了十年枪的手，不会一夜之间信任"不用扫就在"的读取结果。

更聪明的路径是：让条码和RFID在同一套系统里共存一段日子，用业务结果证明可靠性，再分批收敛。 这就是渐进式迁移。

二、混合期的三个核心设计

设计一：统一身份——一物一码，码各司职

关键决策：业务主键既不是条码号，也不是EPC，而是资产编号本身。

资产编号（业务主键，人可读，稳定不变）
   ├── 条码值   ── 映射表 ──┐
   ├── EPC      ── 映射表 ──┼──→ 同一资产实体
   └── 序列号SN ── 映射表 ──┘

条码和RFID标签都是这个资产实体的"证件"之一。撕掉条码不丢历史，换RFID标签不改主键，系统里永远只有一份履历。

-- 身份映射表 —— 首码信息 资产管理平台 MasterData 模块节选
-- 同一资产的多张"证件"各自成行，主键挂资产编号
CREATE TABLE asset_identifier (
    id           BIGINT PRIMARY KEY,
    asset_no     VARCHAR(32)  NOT NULL COMMENT '业务主键：资产编号',
    id_type      VARCHAR(16)  NOT NULL COMMENT 'BARCODE / EPC / SN',
    id_value     VARCHAR(64)  NOT NULL COMMENT '证件值',
    valid_from   DATETIME     NOT NULL,
    valid_to     DATETIME     DEFAULT '9999-12-31',  -- 软失效，保留追溯
    UNIQUE KEY uk_id (id_type, id_value)  -- 同一时刻一证一物
);

-- 注意：换标=旧EPC行valid_to闭合+新EPC行插入，映射永远可追溯

这张映射表就是整个迁移期的"户口本"。所有扫码、读标、对账，先落到资产编号，再谈其他。

设计二：统一扫描入口——一套界面，两种识别

盘点界面不区分"这次是扫条码还是读RFID"，由终端自动识别：

/**
 * 统一识别入口 —— 首码信息 移动端 BarcodeRfidHybridScanner 模块节选
 * 原则：使用者不感知技术差异，系统按输入自动分流
 */
public ScanResult onCapture(Input input) {
    // 输入三来源：激光扫条码 / RFID批量读取 / 手动输编号
    if (input.isBarcode()) {
        return resolve("BARCODE", input.value());
    }
    if (input.isEpc()) {
        return resolve("EPC", input.value());
    }
    return resolve("ASSET_NO", input.value());  // 兜底手动输入
}

// 界面上只有一个按钮："添加识别"，而不是"扫条码""读标签"两个入口
// 两个入口=两套操作习惯=迁移期培训成本翻倍

一个容易被低估的细节：盘点结果页要标注每个资产的识别方式。 仓管员拿着手持机走到货架前，RFID批量读到30件、扫码补了2件，界面上用小图标区分——这既是数据可信度的标记，也让老员工逐步建立对RFID的信任。

设计三：双轨对账——用条码验证RFID

迁移期最有价值的副产品，是天然获得了RFID可靠性的实证数据：

• 阶段一：条码盘点为主，RFID静默采集（不进账，只记录）
• 阶段二：RFID与条码双轨并行，每次盘点自动比对两个来源的差异
• 阶段三：RFID为主，条码作为异常复核手段
• 收敛：条码退居备胎，只在标签损坏、特殊材质场景使用

// 双轨比对任务 —— 首码信息 盘点引擎 ReconcileJob 模块节选
// 比对结果本身，就是RFID可靠性最硬的验收证据
public ReconcileReport reconcile(Long taskId) {
    Set<String> byRfid  = rfidService.collectedAssets(taskId);
    Set<String> byBarcd = barcodeService.collectedAssets(taskId);

    report.onlyInRfid  = diff(byRfid, byBarcd);   // RFID读到、条码没扫到
    report.onlyInBarcode = diff(byBarcd, byRfid); // 扫到了、RFID没读到（重点复盘）
    // 连续4周 onlyInBarcode 占比 < 0.5% 即可申请切换主轨
    return report;
}

注意方向性：onlyInBarcode（条码扫到了、RFID没读到）是必须逐条复盘的重点——它是RFID盲区的直接证据；而onlyInRfid多数情况反而是RFID找到了人眼漏扫的资产，属于惊喜项。

三、分批换标的工程节奏

几万张标签不要一次换，按"风险从低到高"排序：

换标挂在盘点任务上做是个省力技巧：反正要走到每一件资产面前核对，顺手完成换标，不需要专门组织停产窗口。

四、迁移期的三条纪律

1. 映射表有人负责。 身份映射是迁移期最核心的资产，必须有明确的维护责任人和每周校验机制（映射悬空、一码多物的检测SQL要常备）；
2. 不设硬切换日。 收敛标准是连续N周双轨差异率达标，而不是某个行政日期——数据说了算；
3. 保留条码复核通道至少一年。 哪怕主轨已切RFID，异常复核的扫码入口留着。它是员工的安全感来源，也是极端情况下的业务兜底。

五、常见坑清单

• [ ] 用EPC直接当业务主键（换标即断档，事后无法补救）
• [ ] 新旧系统并行但共享同一批设备，互相覆盖数据
• [ ] 双轨期只展示RFID结果，员工不信又无处验证
• [ ] 换标不记台账，返工时发现两批标签混用
• [ ] 迁移完成就下线条码，审计要历史单据时抓瞎

写在最后

渐进式迁移的本质是用确定的中间状态，对冲不确定的切换风险。条码不是落后到必须立刻消灭的东西，RFID也不是完美到可以盲信的东西——让它们在同一段历史里互相验证，比任何PPT里的技术对比都有说服力。

混合期设计的三个关键词送给你：统一身份、统一入口、双轨对账。做到这三条，迁移就不再是惊险一跃，而是一段可以随时暂停、随时回退的平缓上坡。