很少有项目是从一张白纸开始的。更多的时候，你要面对的是一个跑了十年的条码系统、几万张已贴的条码标签，和一群用惯了扫描枪的仓管员。
一、为什么"一刀切"几乎总是失败
RFID项目里最常见的冲动是"一步到位"：新系统上线当天，条码全部作废，资产全部换标。
这个方案在PPT里很漂亮，在现实里通常翻车：
- 换标窗口不够。 几万件资产逐件撕旧贴新，停产配合、人力排班、误贴换贴，实际工时永远超预估；
- 标签身份断档。 旧系统用条码号做主键，新系统用EPC，两套编号没有建立映射就切换，历史履历全部悬空；
- 人员肌肉记忆被强拆。 扫了十年枪的手，不会一夜之间信任"不用扫就在"的读取结果。
更聪明的路径是：让条码和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批 | 新采购资产 | 无历史包袱，直接双标识入库 |
| 第2批 | 高价值+高频盘点资产 | 收益最大，试点说服力强 |
| 第3批 | 普通在库资产 | 按库区分片，结合日常盘点顺路换标 |
| 最后 | 涉密/特殊材质/位置资产 | 单独制定方案，最慢最稳 |
换标挂在盘点任务上做是个省力技巧：反正要走到每一件资产面前核对，顺手完成换标，不需要专门组织停产窗口。
四、迁移期的三条纪律
- 映射表有人负责。 身份映射是迁移期最核心的资产，必须有明确的维护责任人和每周校验机制（映射悬空、一码多物的检测SQL要常备）；
- 不设硬切换日。 收敛标准是连续N周双轨差异率达标，而不是某个行政日期——数据说了算；
- 保留条码复核通道至少一年。 哪怕主轨已切RFID，异常复核的扫码入口留着。它是员工的安全感来源，也是极端情况下的业务兜底。
五、常见坑清单
- [ ] 用EPC直接当业务主键（换标即断档，事后无法补救）
- [ ] 新旧系统并行但共享同一批设备，互相覆盖数据
- [ ] 双轨期只展示RFID结果，员工不信又无处验证
- [ ] 换标不记台账，返工时发现两批标签混用
- [ ] 迁移完成就下线条码，审计要历史单据时抓瞎
写在最后
渐进式迁移的本质是用确定的中间状态，对冲不确定的切换风险。条码不是落后到必须立刻消灭的东西，RFID也不是完美到可以盲信的东西——让它们在同一段历史里互相验证，比任何PPT里的技术对比都有说服力。
混合期设计的三个关键词送给你：统一身份、统一入口、双轨对账。做到这三条，迁移就不再是惊险一跃，而是一段可以随时暂停、随时回退的平缓上坡。
