RFID标签全生命周期管理：发码、绑定、换标、坏标与退役
谈RFID的文章大多聚焦"读"，很少谈"标"——标签自己的一生怎么管理。一套系统上线五年，标签会换、会坏、会随资产退役，如果没有一套标签生命周期机制，台账会慢慢长出"一物多码""幽灵标签"这类数据肿瘤。本文把标签当作一等公民来设计。
一、先建立一个认知：标签和资产是两个实体
最常见的建模错误是把标签当成资产的一个字段（asset.rfid = EPC）。这个模型在换标那天就会崩溃：换上新标签，旧EPC去哪了？历史读取事件还引用着旧EPC，资产履历就断了。
正确的建模是标签实体与资产实体分离，通过绑定关系关联：
asset（资产） tag（标签）
│ │
└── binding（绑定关系）──┘
asset_id, tag_id,
bind_time, unbind_time, unbind_reason
一个资产一生可以有多条绑定记录，同一时刻有且仅有一条生效。历史读取事件记录tag_id而非直接记EPC，这样换标后旧事件依然能追溯到资产。这个模型成立后，后面所有的生命周期环节都是在操作binding记录。
二、标签的一生：六个状态
| 状态 | 含义 | 进入条件 |
|---|---|---|
| ISSUED（已发码） | 编码已分配，未写卡 | 发码中心分配EPC |
| WRITTEN（已写卡） | 标签芯片写入完成 | 打印机写码成功回执 |
| BOUND（已绑定） | 与资产建立生效绑定 | 贴标确认 |
| SUSPECT（疑似故障） | 读取异常但未确认 | 连续N次盘点未读到 |
| UNBOUND（已解绑） | 与资产解除绑定 | 换标/资产退役 |
| RETIRED（已退役） | 标签报废，EPC永久占位 | 物理销毁确认 |
两个设计决策值得强调：
SUSPECT是必须的中间态。标签连续3次盘点没读到，不能直接判"坏"——也可能只是资产被借走到别处。进入SUSPECT后触发人工复核（现场定向扫描），复核确认才进入换标流程。跳过这个状态，系统会把"资产不在"误报成"标签坏了"，换标工单满天飞。
RETIRED状态永不复用EPC。一枚标签物理销毁后，它的EPC在发码中心永久占位。有人会想"回收EPC节省编码空间"——UHF EPC96位有2.8亿亿个，根本用不完，而复用EPC会让历史事件归属变得不可判定，纯属得不偿失。
三、发码环节：发码中心与批次管理
发码看似简单，实则是数据治理的源头。三个实践要点：
- 集中发码，本地只消费。EPC由发码中心统一按编码规则生成（分段编码：版本位+类型位+机构位+序列位），各项目点不能自行造码。分散发码是重码事故的头号来源。
- 批次可追溯。每次发码是一个批次，记录用途、数量、领取人。将来发现某一批标签焊接工艺有缺陷，能一键圈出受影响资产。
- 写卡回执入档。打印机写码成功的回执（含写校验读数）要回传存档，写卡失败的标签当场回收销毁——这是"已写卡却实为坏标"问题的第一道防线。
四、换标环节：一次事务，四步走
换标是标签生命周期里最容易弄脏数据的操作。规范流程是一次原子事务：
-- 换标事务：旧标解绑 + 新标绑定 + 履历记录，同一事务内完成
-- 版权：首码信息 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;
换标的高频错误是把四步拆成四次独立操作——中途任何一步失败，数据库里就会出现"双绑定"或"零绑定"。要么全成，要么全不成，这是换标事务的底线。
换标完成后还有一件容易被遗忘的事：旧标签如果物理上还能读（脱落但没坏），必须当场物理销毁，否则它躺在某个抽屉里继续被通道门读到，制造"幽灵资产"事件。
五、坏标监测：被动发现变主动预防
与其等盘点时才发现标签坏了，不如让系统持续监测标签健康：
| 监测信号 | 判定逻辑 | 响应动作 |
|---|---|---|
| 读取信号强度衰减 | 同一标签RSSI较历史基线持续下降 | 预警：标签/天线劣化 |
| 间歇性失读 | 固定点位读取由稳定变偶发 | 结合周边标签判断：单标坏 or 区域性问题 |
| 长期静默 | 连续N次盘点未读到 | 进入SUSPECT，触发人工复核 |
| 批次性异常 | 同一发码批次故障率超阈值 | 批次追溯，评估是否成批更换 |
其中"批次性异常"检测最有价值：如果发现某一批标签三个月内故障率是其他批次的5倍，那是供应商工艺问题，手里还有库存的应该趁早换供应商——没有批次档案的系统，永远发现不了这个规律。
六、资产退役时，标签怎么办
资产报废处置时，标签处理有三个选项，对应不同场景：
- 资产报废、标签完好：解绑（reason=ASSET_RETIRED），标签物理销毁，EPC退役占位；
- 涉密场景：无论标签好坏一律销毁，且销毁过程要留证（拍照/双人确认入档）——涉密载体的标签本身可能泄露资产信息；
- 标签回收复用（不推荐）：解绑后重新写卡绑定新资产。技术上可行，但历史事件按tag_id追溯时会出现"同一标签服务过两台资产"的交叉，审计解释成本远高于一枚新标签的成本，除非高价值抗金属标签，一般不做。
七、上线前应该建好的三份档案
标签生命周期管理要落地，系统里要有这三份档案，缺一不可：
- 标签档案：tag_id、EPC、发码批次、状态、历次绑定资产；
- 绑定履历：每条bind/unbind记录，含原因和操作人；
- 发码批次档案：批次号、数量、供应商、到货检验记录、累计故障率。
写在最后
标签是RFID系统里最便宜的部件，也是数量最多、生命周期最短的部件。五年运维周期里，一套系统要经历的换标量大约是资产总量的15%~30%（脱落、损坏、资产更替）。标签生命周期机制建得好，这个数字只是后台里的几条流水记录；建得不好，它就是台账上逐年累积、审计时集中引爆的数据肿瘤。把标签当作有生有死的一等实体来设计，是RFID数据治理最划算的一笔投入。
