从标签打印到通道门禁：2026年RFID硬件四类设备选型与型号对照

上个月陪一家汽配客户做验收，通道门禁的漏读率一直压不下去。查了两天，问题不在功率也不在标签——他们把门禁装在两扇卷帘门中间，隔壁产线的叉车每次经过，天线旁瓣都会把邻区标签读进来。挪了位置、补上对射，当天就稳了。

RFID 硬件的难点很少长在参数表上。打印、手持、固定式、门禁这四类设备，规格都能写满一页，真正决定成败的往往是三五个能在现场验证的指标。

标签打印机：分辨率决定下限，编码模块决定能不能用

分辨率分 203、300、600 dpi 三档，它直接框住了条码模块宽度的下限。203dpi 一个点约 0.125mm，条码 X 尺寸按两个点算就是 0.25mm；要打 5mm 见方的小标签，或者往里塞高密度二维条码，203 就不够看。打印宽度按标签宽度选，4 英寸（约 104mm）是常用档。

容易被忽略的是标签间距。间隙小于 2mm 的模切标，光学传感器容易误判，得改黑标定位或者走连续纸按长度切。这条在实验室试打时几乎不暴露，批量跑起来才开始丢张。

再有一层是 UHF 编码模块。带 RFID 的机型要在打印的同时写 EPC 并回读校验，写失败自动作废重打；否则打出来的是一批看起来有标签、实际写不进去的废品。

常见误区是把打印机当办公设备买，只看速度和价格。资产标签多是厚卡纸、PET、抗金属柔性基材，走纸路径和碳带（蜡基、混合基、树脂基）配错了，打印头磨损会快很多。

验收前想先确认网络这一层通不通，用几行脚本比爬梯子看面板快：

import socket
import time


def probe(host: str, port: int = 9100, timeout: float = 1.5) -> bool:
    """RAW 打印端口，能建连说明网络与端口都是通的"""
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
        sock.settimeout(timeout)
        return sock.connect_ex((host, port)) == 0


def send_job(host: str, payload: bytes, port: int = 9100, retry: int = 2) -> bool:
    for attempt in range(retry + 1):
        try:
            with socket.create_connection((host, port), timeout=3) as sock:
                sock.sendall(payload)
                sock.shutdown(socket.SHUT_WR)
            return True
        except OSError:
            time.sleep(0.5 * (attempt + 1))
    return False

一次打印失败就重发，在批量场景里会打出重复标签。重试要有上限，且重发前先读一次状态位，确认上一张没有真正出纸。

判断标准给一条能当场做的：拿实际要用的标签纸打 200 张，数废张率；再用条码枪挑印刷质量靠后的那张连扫 10 次，看是否 10 次全过。

手持终端：群读是标称值，续航是体感值

参数表上写"群读 200 标签/秒"，这个数字和实际盘点耗时的关系很弱。真实货架里标签互相遮挡、贴着金属背板、朝向随机，速率会掉一大截。

该看的是天线增益与实际读取距离、电池容量与连续工作时间、防护等级（室内 IP65 起步，冷链或户外要 IP67）、跌落高度，以及有没有开放的二次开发接口。没有接口，后面接自家 WMS 就得靠人工导出再导入，一线的耐心撑不过一个季度。

常见误区是把"读得远"当成优点。盘点恰恰希望读得近、边界清，站在 A 货架读到 B 货架的东西，账就乱了。

判断标准：找 50 件真实资产放在真实货架上，同一台设备盘三遍，记录耗时和漏读件数。三遍之间的波动，比单次成绩更能说明设备与标签的匹配度。

固定式读写器：天线口数量决定覆盖形态

固定式是装死在现场的，"装几个天线"比"读多远"重要。4 口和 8 口不是容量差别，是覆盖形态差别：门口、工位、货架层，每一处都要一个口，还要考虑极化方向。

线极化对标签朝向敏感，旁瓣抑制却更干净；圆极化容错好，代价是读距短一截。通道和门口多用圆极化，货架层用线极化更划算。

功率要能细调。国内 UHF 的 ERP 上限是 2W（33dBm），但多数室内场景 20 到 26dBm 就够用，开大只会让旁瓣更难控。还有一点常被忘掉：多天线是时分复用的，8 口轮询一圈的时间变长，快速通过的物体可能漏读，口数够用就行。

协议侧看 Gen2（ISO 18000-6C）支持情况，以及是否支持 PoE 供电和 GPIO 联动，后者决定了能不能直接驱动声光报警和道闸。

判断标准：把功率从低往高逐档调，记录每档下同一批标签的读取数量，画成曲线。合理的曲线平滑上升然后趋平；某个档位突然掉下去，多半是天线驻波或安装位置有问题。

通道门禁：漏读和串读是一对矛盾

门禁是四类设备里对现场依赖很重的一个。它的两个指标方向相反：想不漏读，就得加功率、拓宽读取区；想不串读，就得收紧边界。工程上是在中间找平衡。

控制手段通常是天线倾角与安装高度、屏蔽板、红外光电对射做通行方向判断，再在软件侧按时间窗做去重和方向配对。只调功率是调不出来的。

常见误区是先装门禁再想流程。通行宽度、要不要做双向判断、人货是否混行，这些在装修阶段就得定下来，装完再改基本等于重做。

判断标准：30 件实物，正常步速往返 20 次，分别统计漏读次数和邻区串读次数。两个数字都得看，只报一个的都不可信。

型号对照与设备台账

设备一多，台账比参数更值得花时间维护。下面这条查询是用来找出"反复掉线 + 耗材见底"的设备，每周跑一次，比等一线来报修省事：

SELECT site_id,
       device_type,
       COUNT(*)                                          AS device_cnt,
       SUM(CASE WHEN offline_cnt >= 3 THEN 1 ELSE 0 END) AS flaky_cnt,
       MIN(ribbon_pct)                                   AS min_ribbon_pct,
       MAX(last_heartbeat)                               AS last_seen
FROM ops_device_health
WHERE stat_date >= CURRENT_DATE - INTERVAL '7 day'
GROUP BY site_id, device_type
HAVING SUM(CASE WHEN offline_cnt >= 3 THEN 1 ELSE 0 END) > 0
ORDER BY flaky_cnt DESC;

掉线次数和耗材余量要放在同一张表里看。单独看哪一个都会漏：只掉线不缺耗材，多半是供电或无线覆盖；不缺电不缺网但耗材见底，才是真正需要换件的。

一天能做完的现场验证

不必等厂家来做演示。找一天，把这四件事走完：用实际标签纸打 200 张，数废张；用真实货架盘 50 件，盘三遍；把读写器功率逐档拉一遍，看曲线形状；30 件实物正常步速走 20 次门禁，记两个数。

四组数据出来，方案能不能落地基本就有答案。参数表可以写得漂亮，现场只认实测出来的数。