★ FEATURED ARTICLE 简介这是一套面向本科毕业设计的Java后台源码基于Spring Boot框架打造RFID驱动的高校与单位固定资产登记追踪系统围绕资产标签绑定、入库登记、领用归还、位置变更、盘点扫描与状态查询等核心流程展开。系统以RESTful接口对接常见RFID读卡器并内置基础权限管理与操作日志可适配高校实验室、行政单位及中小型企业的固定资产管理场景。压缩包共67个文件、约65KB其中55个Java文件承载业务逻辑与接口实现6个XML文件负责Maven构建及映射配置另有YML环境参数、中英文双语文档、测试代码与Git忽略配置按标准Maven目录组织导入IDE即可运行调试。源码结构清晰覆盖完整后端闭环适合作为Java毕设选题参考、二次开发底座或课程综合实践项目。目前已有41人学习下载对准备RFID资产管理方向论文与系统的在校生颇具参考价值。1. RFID驱动的高校/单位固定资产登记与追踪系统翻车点不在Java后台这个标题看起来是典型的 Java 后台项目真正做完一遍的人都知道后台代码三个月能写完现场跑通却要半年。金属柜上贴的标签扫不到、批量盘点时同一张卡被读写器反复上报、资产被领用后从账本里直接消失——这四类问题不解决RFID 驱动的高校/单位固定资产登记与追踪系统演示得再漂亮也是一堆摆设。这个项目要解决的本质是账实不符用超高频读写器扫一遍房间后台自动比对出在账、盘盈、盘亏并按资产的流转记录追踪去向。适合正在做 Java 毕业设计或者单位内部要做资产盘点工具的开发同学。整套系统从数据库到接口都不复杂复杂的是先想清楚 RFID 的数据长什么样、现场有哪些物理限制。2. 选型与设计写固定资产后台前先定频段、表结构和读写器对接方式很多开发者的习惯是上手就建工程写代码写到盘点导入数据时才卡住RFID 标签数据长什么样读上来的字符串是 HEX 还是 ASCII资产表主键用编号还是用标签号这些问题在设计期没定返工成本很高。我一般花半天把下面三件事定清楚再打开 IDE。2.1 先选频段高校资产批量盘点为什么绕不开超高频 UHF市场上主流的 RFID 分两个频段高频 HF 13.56 MHz 和超高频 UHF 860-960 MHz。高校固定资产场景基本只有超高频一个正确选项原因在读取距离和盘点速度。频段频率范围典型读取距离盘点方式适用对象高频 HF13.56 MHz5~10 cm单件贴近读门禁卡、贵重仪器定点签退超高频 UHF860-960 MHz3~10 m批量读、快速扫固定资产整屋盘点、通道门追踪一台超高频手持机站在过道中间可以覆盖左右两排设备的标签高频则需要贴着标签一台一台刷几千件资产会刷到怀疑人生。UHF 的批量识别能力是每秒上百张标签这才是登记与追踪能落地的核心前提。标签类型也要在选型阶段定掉普通纸质标签贴木桌、塑料外壳没问题遇到金属机箱、铁皮柜必须换抗金属标签。超高频信号在金属表面会反射和衰减标签天线直接贴在金属上等于没用。抗金属标签带硬质垫层把天线和金属隔开虽然厚一点、贵一点但贴上去基本一劳永逸。这个细节对应后面第 4 章的第一个坑。读写器的功率参数同样值得提前说发射功率 25~33 dBm 可调。25 dBm 读距近适合桌面级测试33 dBm 读距远适合整屋盘点。但一个房间装多台固定式读写器时别把功率全开满相邻设备互相干扰会产生读空气现象——扫到隔壁房间或楼下的标签盘点差异表瞬间多出一堆不存在的资产。常见做法是手持机盘点时开足功率通道门检测时把固定式读写器功率调低只覆盖门口一米范围。2.2 数据模型标签绑定表和资产主表必须分开建先搞清楚超高频标签上有两段数据EPC 和 TID。EPC 是 96 位十六进制表示就是 24 个字符这一段允许按自己的编码规则写业务信息TID 是出厂写入的每张卡唯一且不可改。做固定资产追踪我用 TID 做唯一性校验防止同一张卡重复绑定用 EPC 做盘点时的业务查询键资产编号则放在数据库里通过绑定关系关联而不是塞进 EPC。这里有一个常见的误设计把 EPC 直接当成资产主键。资产可能换标签第一次绑定的 EPC 是 A标签损坏后换了 EPC B。如果 asset 表里直接存 EPC 当唯一标识换标签就要改主键所有历史流水全部错乱。正确做法是三张表t_asset资产本身的信息资产编号、名称、分类、部门、存放位置、状态。t_rfid_tag标签绑定关系资产 ID、EPC、TID、读写器编号、绑定时间。EPC 和 TID 都加唯一索引。t_movement追踪流水表资产 ID、操作类型、读写器编号、位置、经办人、发生时间。这张表只增不删一次盘点、一次领用、一次出门都落一条流水。追踪两个字就靠 t_movement 这张表实现。后面做盘点差异、出门检测、资产履历查询全是从这张表读数据。资产主表反映的是当前状态流水表反映的是历史轨迹两者职责分开系统才不会越写越乱。2.3 后台技术栈与对接方式用适配层把不同读写器挡在门外后台技术栈我一般用 Spring Boot 2.7 或 3.xMySQL 8MyBatis Plus 做数据访问。Redis 不是必须的如果演示机器内存小窗口去重完全可以用数据库查询实现第 5 章会给出两种写法。真正的设计重点在读写器对接。市面上超高频读写器的接入方式无非三种串口、TCP Socket 自定义协议、HTTP 回调。厂商 SDK 各不相同但底层都在做同一件事把读到的一组标签 EPC 和信号强度上报给后台。因此后台不要直接依赖某一家厂商的 SDK而是定义一个统一的标签上报体{ readerSn: RDR-001, epcList: [300833B2DDD9010000000001, 300833B2DDD9010000000002], rssiList: [-60, -63], readTime: 2025-01-01 10:00:00 }readerSn 是读写器编号epcList 是一批标签 EPCrssiList 是对应信号强度readTime 是读取时间。后台业务只认这个结构厂商 SDK 的差异全部收在一个 ReaderAdapter 接口里。硬件没到货时写一个 mock 实现盘点、追踪、差异比对全流程照样能开发硬件到场后替换适配器实现业务代码一行不用改。这个习惯在最后一章还会再展开。接口一旦定下来所有盘点、追踪逻辑就和具体设备解耦了。3. 后台代码落地RFID标签绑定、登记入库与追踪查询的Java实现设计定完下面是能直接抄进 Spring Boot 项目的最小实现。我按建表、绑定服务、盘点上报、追踪查询四个步骤拆开讲每段代码都带注释和参数说明。3.1 建表三张表把资产、RFID 标签、追踪流水分开存先建这三张核心表字段按最小可用标准设计后续要加扩展字段直接 ALTER TABLE 就行。-- 资产主表 CREATE TABLE t_asset ( id BIGINT AUTO_INCREMENT PRIMARY KEY, asset_code VARCHAR(32) NOT NULL COMMENT 资产编号纸面资产台账同步, asset_name VARCHAR(128) NOT NULL COMMENT 资产名称, category VARCHAR(32) COMMENT 分类仪器/电子设备/家具, dept VARCHAR(64) COMMENT 使用部门, location VARCHAR(128) COMMENT 存放位置描述, status TINYINT DEFAULT 0 COMMENT 0在库 1领用 2维修 3报废, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_asset_code (asset_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT资产登记主表; -- RFID 标签绑定表 CREATE TABLE t_rfid_tag ( id BIGINT AUTO_INCREMENT PRIMARY KEY, asset_id BIGINT NOT NULL COMMENT 关联 t_asset.id, epc VARCHAR(32) NOT NULL COMMENT 超高频 EPC 十六进制字符串统一大写, tid VARCHAR(32) NOT NULL COMMENT 标签 TID出厂唯一, reader_sn VARCHAR(64) COMMENT 绑定操作使用的读写器编号, bind_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_epc (epc), UNIQUE KEY uk_tid (tid), KEY idx_asset_id (asset_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENTRFID标签与资产绑定表; -- 追踪流水表 CREATE TABLE t_movement ( id BIGINT AUTO_INCREMENT PRIMARY KEY, asset_id BIGINT NOT NULL COMMENT 关联 t_asset.id, action_type VARCHAR(16) NOT NULL COMMENT BIND/SCAN/OUT/IN/CHANGE, reader_sn VARCHAR(64) COMMENT 读写器编号, location VARCHAR(128) COMMENT 盘点或操作时的位置, operator VARCHAR(32) COMMENT 操作人或经办人, remark VARCHAR(255) COMMENT 备注, happen_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_asset_time (asset_id, happen_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT资产追踪流水表;逻辑说明t_rfid_tag 里 asset_id 没有加唯一索引因为一张资产允许换绑多个标签但历史绑定会通过流水保留epc 和 tid 的唯一索引是硬约束同一张卡重复绑定直接报错。t_movement 的 action_type 用字符串不用枚举因为盘点、领用、维修、报废这些操作后续还要扩展字符串类型加注释最灵活。参数说明epc 字段设计为 VARCHAR(32)24 个十六进制字符完全放得下留一点余量应对 128 位 EPC 的标签。TID 同样预留 32 位。asset_code 用的 VARCHAR(32)覆盖部门缩写年份流水号这类编码规则。3.2 绑定服务把 EPC、TID、资产编号对应起来绑定是登记环节的核心操作资产信息先进 t_asset然后拿一张物理标签贴到设备上通过读写器读出 EPC 和 TID调用绑定接口建立关联。Service Slf4j public class RfidBindingService { Resource private AssetMapper assetMapper; Resource private TagMapper tagMapper; Resource private MovementMapper movementMapper; /** * 绑定 RFID 标签到指定资产 * return 资产ID */ Transactional(rollbackFor Exception.class) public Long bindTag(BindRequest req) { // EPC 96位转十六进制正好24个字符这里先做格式校验 if (!isValidEpc(req.getEpc())) { throw new BusinessException(EPC格式不正确应为24位十六进制字符串); } // 用TID查重防止同一张物理标签被绑到多个资产上 Tag existTag tagMapper.selectOne( Wrappers.lambdaQuery(Tag.class) .eq(Tag::getTid, req.getTid().toUpperCase())); if (existTag ! null) { if (!existTag.getAssetId().equals(req.getAssetId())) { throw new BusinessException(该标签已绑定到其他资产); } return existTag.getAssetId(); } // 资产必须真实存在避免脏关联 Asset asset assetMapper.selectById(req.getAssetId()); if (asset null) { throw new BusinessException(资产不存在); } // 写入绑定关系EPC统一大写后续所有查询都按大写走 Tag tag new Tag(); tag.setAssetId(asset.getId()); tag.setEpc(req.getEpc().toUpperCase()); tag.setTid(req.getTid().toUpperCase()); tag.setReaderSn(req.getReaderSn()); tagMapper.insert(tag); // 绑定动作本身落一条流水保证资产履历可回溯 Movement mv new Movement(); mv.setAssetId(asset.getId()); mv.setActionType(BIND); mv.setReaderSn(req.getReaderSn()); mv.setLocation(asset.getLocation()); mv.setRemark(绑定标签EPC: tag.getEpc()); movementMapper.insert(mv); return asset.getId(); } private boolean isValidEpc(String epc) { return epc ! null epc.length() 24 epc.toUpperCase().matches(^[0-9A-F]{24}$); } }逻辑说明EPC 校验是必须的读写器返回的数据偶尔会带换行符或空格长度不匹配就直接拒绝避免脏数据进库。TID 查重放在 EPC 校验之后因为 EPC 可以重复但 TID 理论上全球唯一用 TID 做物理卡防重最可靠。事务注解保证标签绑定和流水插入要么同时成功、要么同时回滚。参数说明req 对象里有 assetId、epc、tid、readerSn 四个字段。readerSn 记录是哪台读写器完成的绑定将来排查这批货是谁贴的标签时有用。isValidEpc 里的正则^[0-9A-F]{24}$严格限定 24 位十六进制字符大小写在匹配前已经统一处理。3.3 盘点上报接口标签扫到后自动登记流水盘点场景是读写器持续上报标签后台接口会被高频调用。这个接口要同时处理未绑定标签和重复上报两种异常情况。RestController RequestMapping(/api/rfid) public class RfidScanController { Resource private TagMapper tagMapper; Resource private MovementMapper movementMapper; Resource private ScanLogMapper scanLogMapper; /** * 读写器批量上报入口 */ PostMapping(/scan) public Result handleScan(RequestBody ScanReport report) { // 同一个包内先做字符串去重读写器一次上报可能带重复标签 ListString epcList report.getEpcList().stream() .map(String::trim) .distinct() .collect(Collectors.toList()); for (String epc : epcList) { scanOne(report.getReaderSn(), epc); } return Result.ok(epcList.size()); } private void scanOne(String readerSn, String epc) { // 查标签绑定关系注意EPC统一转大写 Tag tag tagMapper.selectOne( Wrappers.lambdaQuery(Tag.class) .eq(Tag::getEpc, epc.toUpperCase())); if (tag null) { // 未绑定标签单独记异常日志不能写入movement因为movement强关联asset_id scanLogMapper.insert(new ScanLog(epc.toUpperCase(), readerSn, UNBOUND)); return; } // 同一资产30秒窗口内只记第一条SCAN流水避免读写器反复上报刷爆表 LocalDateTime windowStart LocalDateTime.now().minusSeconds(30); Long count movementMapper.selectCount( Wrappers.lambdaQuery(Movement.class) .eq(Movement::getAssetId, tag.getAssetId()) .eq(Movement::getActionType, SCAN) .ge(Movement::getHappenTime, windowStart)); if (count ! null count 0) { return; } Movement mv new Movement(); mv.setAssetId(tag.getAssetId()); mv.setActionType(SCAN); mv.setReaderSn(readerSn); mv.setLocation(tag.getAssetLocation()); // 资产当前登记的位置 movementMapper.insert(mv); } }逻辑说明入口先distinct()去重解决读写器单包重复未绑定标签单独写入 t_scan_log而不是强插 t_movement因为 movement 表外键关联 asset_id未绑定的标签根本没有资产强行插入会破坏数据完整性。30 秒窗口去重是这套代码里最重要的防刷逻辑一台固定式读写器每秒可能上报十几次同一标签没有窗口约束的话盘点一小时能产生几十万条流水。参数说明30 秒窗口值不是拍脑袋定的。手持机扫过一台设备时标签通常会被读到三五次间隔在毫秒级盘点人员移动到下一台设备时上一台设备已经离开读取范围。30 秒足够覆盖单台设备的所有重复上报又不会误伤同一位置重复盘点的合法场景。如果现场有多台固定式读写器同时工作窗口缩到 10 秒更合适。3.4 追踪查询一条资产从到货到报废的全量记录追踪查询是系统演示时最高频的功能输入资产编号页面上能看到这台设备什么时候入账、什么时候盘点过、最后一次出现在哪台读写器附近。SELECT a.asset_code, a.asset_name, m.action_type, m.reader_sn, m.location, m.operator, m.remark, m.happen_time FROM t_movement m JOIN t_asset a ON a.id m.asset_id WHERE m.asset_id #{assetId} ORDER BY m.happen_time DESC;逻辑说明关联查询一次拿全资产信息和流水信息MyBatis 里直接写在 XML 或注解中即可。按 happen_time 倒序排列后列表第一条就是该资产最近一次被读写器读到的记录可以推断它当前大致在哪。BIND 表示入账绑定SCAN 表示盘点时被读到OUT/IN 表示出门和归还这样资产履历一目了然。参数说明#{assetId} 是 t_asset 表的主键。如果前端拿的是资产编号而不是主键可以先查一次 t_asset 拿到 id 再执行这条 SQL。数据量超过十万条流水时idx_asset_time 索引能保证这个查询稳定在几十毫秒内返回。4. 避坑记录固定资产 RFID 系统最容易踩的五个坑这一章全部来自现场反馈和同行交流每一条都按现象、原因、解决三个层次展开。做固定资产 RFID 系统的人基本都会在这五个位置至少翻一次车。4.1 金属柜门上的标签永远扫不到现象统一采购的纸质 RFID 标签贴在金属机柜、实验仪器外壳上手持机怎么扫都只有零星响应贴在同一区域木柜上的标签却能正常读取。原因超高频电磁波遇到金属平面会发生反射和涡流损耗标签天线与金属表面之间无法建立有效的电磁场能量全部被金属吃掉。解决金属表面换抗金属标签这种标签自带硬质垫层把天线垫高几毫米避免直接贴合金属。不要指望垫泡沫双面胶能解决问题现场施工时胶层厚度很难控制垫了也容易脱落。正确流程是批量采购前先买几片样品贴在目标资产上实测读取距离和成功率再决定采多少。实验室金属外壳设备多的话抗金属标签的费用要提前算进预算。4.2 EPC 大小写不一致导致资产查不到现象绑定阶段写入的 EPC 是大写盘点时手持机协议返回小写十六进制后台按大写去查绑定表永远查不到这台资产的盘点结果一直显示未扫码。原因不同厂商读写器的字符串格式不统一有返回大写的有返回小写的个别设备甚至返回带冒号分隔的格式。这些差异在联调阶段发现不了因为 demo 程序都用自己的 SDK。解决所有入口统一转大写并且只在数据入口处转一次。绑定接口、扫盘接口、模拟器接口全部对 EPC 调toUpperCase()数据库里也统一存大写。不要在查询时做转换否则每个 SQL 都要人肉记得转迟早漏一两个地方。我通常还会建一条数据库约束强制 epc 字段只能存大写从存储层面把格式锁死。4.3 批量上报重复入库流水表被刷爆现象一台读写器站在房间里扫一圈t_movement 表里出现同一资产几十条 SCAN 流水盘点差异数完全没法看页面加载也变慢。原因超高频读写器是连续读取模式标签只要在读取范围内每秒可能被上报十几次。如果盘点逻辑是扫到就插流水一个下午就能产生百万条无效数据。解决按 3.3 节的方式做窗口去重同一个资产 30 秒内只保留一条 SCAN 流水。更严谨的做法是加 Redis 幂等键用 SETNX 控制窗口没有 Redis 环境时数据库时间窗口查询也能兜住。如果还有并发推送的极端场景就在 t_movement 上建一个asset_id action_type happen_time 分钟级别的唯一索引从数据库层面拒绝重复。4.4 领用后资产从盘点列表里消失现象设备被某人领用后状态改成领用下次盘点时这台设备不在原房间系统里也查不到它的位置资产在账本里悬空。原因领用登记只改了 t_asset 的 status 字段没有落一条 OUT 流水也没有记录资产被带到了哪里。盘点逻辑只统计状态为在库的资产领用中的设备既不参与盘点也没有位置信息自然就从账本里蒸发了。解决领用动作必须走一个独立接口业务上做两件事更新资产状态为领用、写一条 action_typeOUT 的流水流水里带上领用人和去向部门。盘点差异表要增加缺失但已领用这个分类而不是直接判定盘亏。这样资产从在库变成已被某人领走每一步都有据可查。4.5 盘点结果直接覆盖资产表误操作没有后悔药现象第一次盘点时手持机漏读了某排货架系统把一批正常在账的资产批量标记为盘亏第二天补扫后状态又恢复正常但盘点历史已经被污染审计时说不清为什么会有一次虚假盘亏。原因盘点保存逻辑直接 UPDATE t_asset 的 status 或最后盘点时间字段没有做盘点批次-差异确认的中间层。漏读、标签损坏、设备临时故障都会直接改掉资产主表。解决盘点只负责生成差异明细表和差异汇总盘点人核对确认后系统才允许更新资产状态并且每次更新都落一条 CHANGE 流水。留出确认这一步相当于给误盘留了一条后悔药审计也能看到哪一次盘点在确认前被作废。固定资产盘点最重要的是过程可追溯不是结果一次到位。5. 盘点与追踪的功能设计去重、差异表和出门检测怎么落地登记做完系统最大的价值体现在盘点和追踪两个功能。盘点解决账实是否一致追踪解决资产在哪个环节、去过哪里。这一章把这两个功能的设计思路细化到可以编码。5.1 盘点批次会话 窗口去重 差异对比盘点功能不能做成扫到啥算啥正确做法是分三步走建一个盘点批次关闭批次最后做差异对比。第一步发起盘点时在后台创建一个盘点批次记录盘点范围、盘点人、开始时间。第二步手持机扫码时前面 3.3 节的 scan 接口需要带上 batchId通过 Redis 做窗口去重// 盘点批次内同一标签30秒只处理一次 String dedupKey inv: batchId : epc; Boolean first redisTemplate.opsForValue() .setIfAbsent(dedupKey, 1, 30, TimeUnit.SECONDS); if (Boolean.TRUE.equals(first)) { // 第一次出现的标签才进入盘点统计 handleAssetHit(tag.getAssetId(), batchId, readerSn); }逻辑说明Redis 的 SETNX 语义天然适合做窗口去重key 带 batchId 让每个盘点批次独立计数过期时间 30 秒和 3.3 节保持一致。没有 Redis 环境的项目把这段换成 3.3 节里的数据库时间窗口查询效果相同只是并发量高时多几条 SELECT 而已。第三步盘点结束后把所有扫到过的 assetId 集合与应盘资产清单做差集扫到但清单里没有的是盘盈清单里有但没扫到的是盘亏。差异结果先落一张盘点差异表不做任何状态更新等人工确认后再按 4.5 节的方式处理。5.2 出门检测位置追踪的低成本做法固定资产的追踪不要求实时坐标把每一个关键出入口管住就够了。常见做法是在房间门口或楼道出入口安装固定式读写器资产被抬出门时自动记录经过哪道门、什么时间。方向判断是这里唯一的技术难点。单个固定式读写器只能判断标签出现过无法区分是进门还是出门。常见做法是配合红外对射传感器先遮挡红外再读到标签判定为出门先读到标签再遮挡红外判定为进门。后台收到 OUT 事件先别急着改状态落一条 pending 流水并推送提醒管理员确认是正常领用外出还是未登记出门后再更新资产状态。这个确认步骤能把正常搬运和可能的违规出门区分开避免系统误报警。5.3 和常见误用的差别盘点不是改资产状态追踪不是 GPS做类似系统时最容易产生两个预期偏差。第一盘点结果不能直接覆盖资产主表盘点产出的是一份差异报告资产状态的变更必须由人确认后执行。第二RFID 追踪是节点式追踪不是实时 GPS——你知道的是资产最后一次出现在哪道门、哪个房间而不是它此刻在哪个坐标点。很多刚入门的人做到一半开始补定位算法然后翻车。高校固定资产管理的真实需求是这台仪器在谁手里、最后一次出现在哪里节点式追踪完全够用而且实现成本低一个数量级。6. 没有 RFID 硬件时先把后台跑通模拟读写器与联调技巧硬件没到货是整个开发周期里最容易干等的阶段。很多开发者在这里浪费两三周最后联调时间被压缩到一两天。正确做法是写一个模拟读写器接口把随机生成的 EPC 数据送进后台让绑定、盘点、追踪全链路先跑起来。6.1 用模拟读写器接口替代硬件模拟接口本质就是一个 POST 端口触发时自动向 scan 接口推一批假标签RestController RequestMapping(/mock/reader) public class MockRfidReaderController { Resource private RfidScanController rfidScanController; PostMapping(/scan) public Result mockScan(RequestParam(defaultValue MOCK-001) String readerSn) { ListString epcList List.of( 300833B2DDD9010000000001, 300833B2DDD9010000000002, 300833B2DDD9010000000003 ); ScanReport report new ScanReport(); report.setReaderSn(readerSn); report.setEpcList(epcList); return rfidScanController.handleScan(report); } }逻辑说明模拟接口直接调用真实的 handleScan 方法意味着去重、未绑定标签处理、流水写入全部走正式代码路径。唯一换掉的是数据来源。等真实读写器到场后写一个厂商适配器把 SDK 回调的数据组装成 ScanReport 再交给 handleScan业务层一行不改。6.2 用 curl 一条条验证接口没有前端页面时curl 是最快的验证工具。绑定服务和盘点上报接口都可以用一条命令触发curl -X POST http://localhost:8080/api/rfid/scan \ -H Content-Type: application/json \ -d {readerSn:MOCK-001,epcList:[300833B2DDD9010000000001,300833B2DDD9010000000002]}调通后查 t_movement 表应该能看到对应的 SCAN 流水再查 t_scan_log能看到那些绑定表里不存在的 EPC 被完整记录。整个联调闭环不依赖任何硬件这也是我后来做所有硬件对接项目固定下来的习惯先定接口、再写业务逻辑、最后对接设备。曾经有一次设备到货前一天演示全靠 mock 接口撑住真实读写器接入只用了半个下午核心代码一行没动。希望这份经验也能帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
