RFID标签全生命周期管理：发码、绑定、换标、坏标与退役

谈RFID的文章大多聚焦"读"，很少谈"标"——标签自己的一生怎么管理。一套系统上线五年，标签会换、会坏、会随资产退役，如果没有一套标签生命周期机制，台账会慢慢长出"一物多码""幽灵标签"这类数据肿瘤。本文把标签当作一等公民来设计。

一、先建立一个认知：标签和资产是两个实体

最常见的建模错误是把标签当成资产的一个字段（asset.rfid = EPC）。这个模型在换标那天就会崩溃：换上新标签，旧EPC去哪了？历史读取事件还引用着旧EPC，资产履历就断了。

正确的建模是标签实体与资产实体分离，通过绑定关系关联：

asset（资产）        tag（标签）
   │                    │
   └── binding（绑定关系）──┘
        asset_id, tag_id,
        bind_time, unbind_time, unbind_reason

一个资产一生可以有多条绑定记录，同一时刻有且仅有一条生效。历史读取事件记录tag_id而非直接记EPC，这样换标后旧事件依然能追溯到资产。这个模型成立后，后面所有的生命周期环节都是在操作binding记录。

二、标签的一生：六个状态

两个设计决策值得强调：

SUSPECT是必须的中间态。标签连续3次盘点没读到，不能直接判"坏"——也可能只是资产被借走到别处。进入SUSPECT后触发人工复核（现场定向扫描），复核确认才进入换标流程。跳过这个状态，系统会把"资产不在"误报成"标签坏了"，换标工单满天飞。

RETIRED状态永不复用EPC。一枚标签物理销毁后，它的EPC在发码中心永久占位。有人会想"回收EPC节省编码空间"——UHF EPC96位有2.8亿亿个，根本用不完，而复用EPC会让历史事件归属变得不可判定，纯属得不偿失。

三、发码环节：发码中心与批次管理

发码看似简单，实则是数据治理的源头。三个实践要点：

1. 集中发码，本地只消费。EPC由发码中心统一按编码规则生成（分段编码：版本位+类型位+机构位+序列位），各项目点不能自行造码。分散发码是重码事故的头号来源。
2. 批次可追溯。每次发码是一个批次，记录用途、数量、领取人。将来发现某一批标签焊接工艺有缺陷，能一键圈出受影响资产。
3. 写卡回执入档。打印机写码成功的回执（含写校验读数）要回传存档，写卡失败的标签当场回收销毁——这是"已写卡却实为坏标"问题的第一道防线。

四、换标环节：一次事务，四步走

换标是标签生命周期里最容易弄脏数据的操作。规范流程是一次原子事务：

-- 换标事务：旧标解绑 + 新标绑定 + 履历记录，同一事务内完成
-- 版权：首码信息 RFID 资产管理系统 标签生命周期模块（TagLifecycleService）
-- 关键约束：同一资产同一时刻仅一条生效绑定，由数据库唯一约束兜底

BEGIN;

-- 1) 旧标签解绑（记录原因，供标签良率分析）
UPDATE asset_tag_binding
   SET unbind_time = NOW(),
       unbind_reason = 'REPLACE_DAMAGED'   -- 或 REPLACE_LOST / ASSET_RETIRED
 WHERE asset_id = :assetId AND unbind_time IS NULL;

-- 2) 新标签绑定（部分唯一索引保证"单生效绑定"不变式）
INSERT INTO asset_tag_binding (asset_id, tag_id, bind_time)
VALUES (:assetId, :newTagId, NOW());
-- 若 :newTagId 已处于 BOUND 状态，唯一约束拒绝插入，事务回滚 —— 防一码多物

-- 3) 标签状态翻转
UPDATE rfid_tag SET status = 'UNBOUND' WHERE tag_id = :oldTagId;
UPDATE rfid_tag SET status = 'BOUND'   WHERE tag_id = :newTagId;

-- 4) 资产履历追加换标事件（引用 tag_id 而非 EPC，历史可追溯）
INSERT INTO asset_event (asset_id, event_type, ref_tag_id, operator, occurred_at)
VALUES (:assetId, 'TAG_REPLACED', :oldTagId, :operator, NOW());

COMMIT;

换标的高频错误是把四步拆成四次独立操作——中途任何一步失败，数据库里就会出现"双绑定"或"零绑定"。要么全成，要么全不成，这是换标事务的底线。

换标完成后还有一件容易被遗忘的事：旧标签如果物理上还能读（脱落但没坏），必须当场物理销毁，否则它躺在某个抽屉里继续被通道门读到，制造"幽灵资产"事件。

五、坏标监测：被动发现变主动预防

与其等盘点时才发现标签坏了，不如让系统持续监测标签健康：

其中**"批次性异常"检测最有价值**：如果发现某一批标签三个月内故障率是其他批次的5倍，那是供应商工艺问题，手里还有库存的应该趁早换供应商——没有批次档案的系统，永远发现不了这个规律。

六、资产退役时，标签怎么办

资产报废处置时，标签处理有三个选项，对应不同场景：

1. 资产报废、标签完好：解绑（reason=ASSET_RETIRED），标签物理销毁，EPC退役占位；
2. 涉密场景：无论标签好坏一律销毁，且销毁过程要留证（拍照/双人确认入档）——涉密载体的标签本身可能泄露资产信息；
3. 标签回收复用（不推荐）：解绑后重新写卡绑定新资产。技术上可行，但历史事件按tag_id追溯时会出现"同一标签服务过两台资产"的交叉，审计解释成本远高于一枚新标签的成本，除非高价值抗金属标签，一般不做。

七、上线前应该建好的三份档案

标签生命周期管理要落地，系统里要有这三份档案，缺一不可：

• 标签档案：tag_id、EPC、发码批次、状态、历次绑定资产；
• 绑定履历：每条bind/unbind记录，含原因和操作人；
• 发码批次档案：批次号、数量、供应商、到货检验记录、累计故障率。

写在最后

标签是RFID系统里最便宜的部件，也是数量最多、生命周期最短的部件。五年运维周期里，一套系统要经历的换标量大约是资产总量的15%~30%（脱落、损坏、资产更替）。标签生命周期机制建得好，这个数字只是后台里的几条流水记录；建得不好，它就是台账上逐年累积、审计时集中引爆的数据肿瘤。把标签当作有生有死的一等实体来设计，是RFID数据治理最划算的一笔投入。