企业官网建设流程全解析

简介：本资源是一套面向本科毕业设计、课程设计及IT实践学习者的完整RFID图书馆人员管理系统实现方案，聚焦于物联网与嵌入式软件开发交叉场景，解决传统图书馆借还书效率低、人工核验易出错、图书追踪难等实际问题。压缩包共39个文件，含12个C++源文件（核心业务逻辑与RFID通信处理）、12个头文件（模块接口定义）、9个Qt UI界面文件（借阅/归还/管理前端）、1个Qt项目配置文件（.pro），另附毕业论文PDF、README说明、LICENSE协议等，整体8.55MB，结构清晰，便于理解系统分层架构与软硬协同流程。已有84人学习下载，读者可直接获取可编译运行的完整工程代码、配套毕业论文文档及模块化UI设计，快速掌握RFID读写器驱动集成、数据库交互、多线程数据处理及图书馆典型业务建模方法。

1. 项目整体思路与选题价值

1.1 为什么是“RFID + 图书馆人员管理”这个组合

每年到毕业设计选题季，软件工程、物联网、信息管理这类专业的学生，总会在“做个什么系统”这件事上反复纠结。我的建议一直是：要找那种技术栈有辨识度、业务场景足够清晰、又能在短时间内做出完整成果的题目。“基于RFID的图书馆人员管理系统”恰好符合这三条。

先拆一下这个题目的关键词：RFID（Radio Frequency Identification，射频识别）、图书馆、人员管理系统。它不是一个纯粹的CRUD管理系统，也不是一个纯硬件项目，而是把物联网感知层和业务管理系统结合起来的典型应用。说得直白一点：传统图书馆管理员用条码枪扫一本书的条码，一次只能扫一本，还得对准角度；RFID方案则是把每一本书和每一张读者卡都贴上射频标签，借书还书的时候，把一摞书往读写器上一放，几秒钟就能全部识别，甚至不用逐本对准。这就是RFID在图书馆场景里最核心的价值——批量识别与远距离读取。

把这个技术思路应用到“人员管理”上，核心就是要搞清楚：系统管理的对象是“人”，而不是“书”。读者的借阅证（或一卡通）内嵌RFID标签，图书馆门口和借阅区的读写器持续采集标签信息，后台系统根据这些信息完成身份识别、出入记录、借还操作关联、滞留时长统计等业务。只要把这个逻辑想透，整个系统的骨架就出来了。

1.2 这套系统解决了什么真实问题

很多人做毕业设计容易犯一个毛病：把系统做成“功能堆砌”，看起来模块很多，但每一个都经不起追问。做图书馆人员管理系统，首先要回答的是“这个系统到底解决了什么痛点”。我去过不少高校图书馆，也调研过一些小型公共图书馆，最典型的痛点有三个：

第一，高峰期排队严重。下课时间图书馆扎堆借还，传统条码扫描方式下管理员手忙脚乱，读者等得烦躁。RFID批量读写能把单次借还操作从“逐本扫描”变成“整摞识别”，速度提升非常明显。

第二，人员进出与安全管控薄弱。图书馆的防盗门、门禁系统和借还系统往往是两套独立设备，数据不互通。利用RFID读写器在门口采集标签数据，可以把人员进出记录和借还状态实时联动——谁进来了、谁还没还书就带着书出去了、谁在闭馆后还滞留在馆内，全都能在后台查到。

第三，管理报表靠手工统计。读者到馆频次、各时段人流量、热门图书借阅排行，这些数据如果靠管理员肉眼统计几乎不可能。RFID系统天然产生大量结构化数据，稍加统计就能生成有价值的运营报表。

所以，这套系统的本质，是把图书馆从“以图书管理为中心”转向“以读者服务为中心”的数字化基础设施。你把这个立意写清楚，毕业答辩时老师最关心的“研究意义”和“应用价值”就能站得住脚。

1.3 适合谁参考，以及从零开始的预期路径

如果你是准备做这个题目的毕业生，或者想拿RFID练手的开发者，这篇博文能帮你节省大量摸索时间。我默认的读者画像有三种：

• 计算机、软件工程、物联网相关专业的学生，正在做或准备做同类毕业设计；
• 有Java Web或类似开发基础，但对RFID硬件不熟悉的开发者；
• 需要在短期之内把Demo跑起来、写进论文、顺利答辩的务实派。

不管你是哪种，我的建议路径都是这样的：先花一天时间把RFID的原理和整个业务流程搞清楚（这是后文第2部分的内容），再花一天时间把代码工程跑起来（第3部分），然后针对自己的场景去改业务逻辑和界面（第4部分）。这个节奏比较稳妥。

注意：我这里讲整个系统的构建，并不是让你去网上下载一个源码包然后改个名字交差。而是建议你把系统架构、核心流程、数据表设计这些底层逻辑吃透，这样无论最后是二次开发还是自己从零写，都能真正掌控项目。

2. RFID技术原理与系统核心设计

2.1 射频识别系统的基本组成与工作流程

要把RFID系统做好，得先理解它的硬件组成。一套完整的RFID系统由三部分组成：电子标签（Tag）、读写器（Reader/Antenna）、应用系统（Host/Middleware）。

电子标签是附着在物体上的数据载体。标签内部有一个微型芯片和天线，芯片里存储着唯一的标识符（如EPC码或TID码），这个标识符相当于物体的“电子身份证”。标签分为被动式、半主动式和主动式三类。被动式标签没有内置电池，靠读写器发射的射频能量场来激活芯片并回传信号，优点是成本低、寿命长，缺点是读取距离相对较短；主动式标签自带电池，能主动发射信号，读取距离远，但成本高、体积大。在图书馆场景里，99%用的都是被动式高频或超高频标签，因为量大、要便宜、要耐用。

读写器的任务是发射射频信号、接收标签回传的数据、再把数据转交给后台。当读写器天线覆盖范围内出现标签时，标签被能量激活，开始与读写器进行无线通信，这个过程叫“盘点”或“识别”。读写器可以同时识别多张标签，这也是RFID比条码强的地方。

再看完整的业务流程：读写器识别到标签ID → 把数据通过串口、USB或网络传给中间件/应用层 → 应用层解析标签ID，通过后台数据库（或远程接口）查到这个ID对应的人或书 → 执行相应的业务逻辑（借书、还书、记录进出）→ 把结果显示到界面上。无论系统做得多复杂，这个链路是永远的骨架。

2.2 频段选型：为什么图书馆场景首选高频

很多同学在方案设计阶段会被各种频段名词搞晕：低频（LF）、高频（HF）、超高频（UHF），到底用哪个？这个必须讲清楚，因为选错频段会让整个项目失去“合理性”。

• 低频（125kHz~134kHz）：读取距离短（几厘米），通信速度慢，抗干扰强，常见于动物识别、门禁卡。不适合图书批量扫描。
• 高频（13.56MHz）：读取距离约10厘米到几十厘米，支持中等速度的批量识别，抗液体和金属干扰能力较好。标准是ISO 15693（图书管理常用）和ISO 14443（身份证、银行卡、校园卡）。全球图书馆主流的RFID方案，绝大多数基于高频ISO 15693协议，因为单本书上贴的标签小、读取稳定、批量识别表现不错。
• 超高频（860MHz~960MHz）：读取距离可达3到10米，识别速度极快，适合供应链、仓储、停车场。近年来也有图书馆开始用超高频做自助借还和防盗，优势是识别距离远、盘点效率高，缺点是对金属和液体的误读率偏高，造价也更贵。

对于毕业设计规模的项目，我建议你优先选高频方案。原因很直接：设备成本相对低，开发资料多，13.56MHz的高频读写器通常提供非常友好的串口或USB通信协议，文档齐全，调试起来不折腾。如果你手头有超高频设备，也能做，但很多精力会花在处理误读和环境干扰上，对完成毕业设计来说不划算。

2.3 数据库表结构：从业务出发设计核心表

业务系统开发有个朴素的真理：数据库表设计得好，后面写代码都是体力活；表设计得烂，后面每一个功能都在给你挖坑。我见过不少同学的毕业论文里数据库设计图画得密密麻麻，二三十张表，结果一问三不知。真正务实的做法是：先梳理核心业务动词，再设计表。

这个系统的核心业务有：读者注册、发卡（绑定RFID标签）、进出馆、借书、还书、查询、统计。围绕这些业务，核心表建议如下：

• reader表：读者基本信息。字段至少包括：id、reader_no（学号/工号）、name、gender、dept（院系/部门）、phone、card_rfid（RFID标签ID，与实体卡绑定）、status（正常/挂失/注销）、create_time。
• book表：图书信息。id、isbn、title、author、publisher、category、location（馆藏位置）、book_rfid（这本书上贴的RFID标签ID）、borrow_status（在馆/借出）、borrow_count（累计借阅次数）。
• borrow_record表：借还记录。id、reader_id、book_id、borrow_time、due_time、return_time、status（借出/已还/逾期）。这张表是整个系统的核心，几乎所有的统计报表都从这张表里出。
• entry_record表：进出馆记录。id、reader_id、reader_rfid、entry_time、exit_time、duration_minutes。用于人员到馆统计和滞留分析。
• admin表：系统管理员账号。id、username、password、real_name、role。

补充一个细节：reader.card_rfid和book.book_rfid建议加唯一索引，因为RFID标签ID在系统内必须唯一，这是硬件世界和软件世界对接的“主键桥”。另外，borrow_record表尽量加上borrow_time和return_time的联合索引，因为借阅历史查询和统计都会高频使用这两个字段。

3. 从解压Zip包到跑通系统：完整实操过程

3.1 拿到Zip项目包之后的第一件事

你拿到的毕业设计通常是以Zip压缩包形式发布的，比如“基于RFID的图书馆人员管理系统.zip”，可能是老师给的、学长给的，或者是从各种渠道收集的。不管来源如何，拿到Zip之后先别急着解压，按我的习惯做三件事：

第一，核对压缩包完整性。在Windows下右键看属性里的“压缩包大小”和“包含文件数”，如果觉得不对劲，用压缩软件自带的“测试”功能跑一遍。在Linux服务器上则可以用unzip -t 包名.zip来测试完整性，输出里没有error就算基本完好。这一步能避免解压到一半文件损坏浪费时间的尴尬。

第二，确认压缩包有没有密码。很多分享出来的毕业设计源码包会设置密码，文件名里有时会带提示。如果遇到加密zip包，先别乱试，仔细看分享说明。正规渠道拿到的包，密码一般会写在压缩包注释或附带的说明文档里。

第三，解压到干净的目录。我强烈建议解压路径不要带中文、不要带空格，更不要直接解压到桌面。比如D:\projects\rfid-library-system这种结构就很好。因为很多框架和中间件对中文路径支持不好，后面启动时会有各种莫名其妙的报错，纯粹是自找麻烦。

3.2 解压Zip的实战命令与问题处理

如果你是在Windows图形界面操作，用360压缩、Bandizip、7-Zip等工具都能解压，右键选择“解压到当前文件夹”或“解压到指定目录”即可。这里我主要说一下Linux环境下的命令行操作，因为不少后端服务最终是要部署到Linux服务器上的，而且很多同学习惯在云服务器上先跑一遍后端。

解压一个正常的zip包：

unzip 基于RFID的图书馆人员管理系统.zip

如果要把所有文件解压到指定目录：

unzip 基于RFID的图书馆人员管理系统.zip -d /home/user/rfid-system

解压之后查看目录结构，用ls -la或tree命令。如果系统没装tree，可以执行yum install tree或apt install tree，这个工具能非常直观地展示项目的层次结构。

再讲几个高频问题的处理方式。

问题一：提示“file is not a zip file”。这个报错的意思是：文件头不是ZIP格式应有的PK头（PK开头的十六进制50 4B 03 04）。最常见的原因有两个：一是文件根本没下载完整，只有几十KB，显然不对；二是下载完了但文件被篡改，或者文件扩展名是zip、实际上却是rar格式。排查方法很简单：

file 包名.zip

file命令会告诉你这个文件的真实类型。如果结果显示Zip archive data，说明文件本身是好的；如果显示RAR archive data，那就用unrar x而不是unzip；如果显示data或ASCII text，那大概率是下载页面被存成了HTML，重新下载吧。

问题二：压缩包有密码。有些网盘分享或群文件的zip包会加密。你有密码就用unzip -P 密码 包名.zip直接解压。但注意：这种方式在命令行里输入密码会留在shell历史记录里，有泄密风险。更稳妥的方式是让它交互式输入：先执行unzip 包名.zip，出现提示时再手动输入密码。如果密码忘了，“zip密码恢复”这类工具在纯数字或短密码情况下能暴力跑出来，但我不建议在这上面花太多时间——直接找分享者要密码，比跑字典快得多。

问题三：分卷压缩包z01/z02。有时候大文件会被压缩成多个分卷，比如项目.zip.001、项目.zip.002，或者xxx.z01、xxx.zip。这种情况需要把所有分卷放在同一个目录，然后用支持分卷解压的工具打开第一个文件。Windows下Bandizip、7-Zip都可以直接操作；Linux下可以先把所有分卷合并：

cat 项目.zip.001 项目.zip.002 > 完整包.zip unzip 完整包.zip

合并之后按普通zip处理。不过要提醒一点：如果分卷文件是从即时通讯工具传输的，建议校验一下文件大小，因为这类工具经常在中途截断大文件。

问题四：目录内出现“锟斤拷”乱码文件名。这个热词相信很多老程序员都懂。zip压缩包里的文件名编码可能是GBK，而Linux默认用UTF-8解压，中文文件名就会变成“锟斤拷”这类经典乱码。解决办法是用unzip -O GBK 包名.zip指定编码。如果unzip版本不支持-O参数，可以用Python脚本解压处理编码问题。Windows下的工具（如Bandizip）一般会自动识别编码，这种问题更少见。

unzip -O GBK 基于RFID的图书馆人员管理系统.zip

这一步看起来不起眼，但要是直接解压导致项目里的中文文件名全部乱码，后续编译和配置时会踩连环坑。

3.3 项目目录结构解析：先看懂再动手

解压完成后，不要急着点开IDE跑代码。先花10分钟看清楚整个项目的目录结构，这会极大降低后续调试的心智负担。

一个典型的“基于RFID的图书馆人员管理系统”项目，常见的目录结构有两种：

第一种是单体Web项目（比如Spring Boot + MyBatis + Vue/Thymeleaf）：

rfid-library-system/ ├── pom.xml # Maven 配置文件 ├── sql/ # 数据库初始化脚本 │ └── library.sql ├── src/ │ ├── main/ │ │ ├── java/ │ │ │ └── com/example/library/ │ │ │ ├── controller/ # 控制层：接口入口 │ │ │ ├── service/ # 业务层：核心业务逻辑 │ │ │ ├── mapper/ # 数据访问层：MyBatis的mapper接口 │ │ │ ├── entity/ # 实体类：对应数据库表 │ │ │ ├── config/ # 配置类：拦截器、跨域等 │ │ │ └── util/ # 工具类 │ │ └── resources/ │ │ ├── application.yml # 项目配置文件 │ │ ├── mapper/ # MyBatis的XML映射文件 │ │ └── static/ # 前端静态资源 │ └── test/ ├── README.md # 项目说明文档，优先看 └── 需求文档.docx # 可选，毕业论文相关内容

第二种是前后端分离项目，多一个frontend目录，里面是Vue或React代码。无论哪种结构，最重要的文件是README.md和sql/下的数据库脚本，前者告诉你启动步骤和依赖环境，后者决定了数据库能不能初始化成功。

3.4 环境搭建与系统启动全流程

现在进入真正动手的阶段。我以最常见的Spring Boot + MySQL方案为例，把从零到跑通的全流程走一遍。

第一步：准备基础环境。需要JDK（建议1.8或11）、Maven（3.6以上）、MySQL（5.7或8.0，推荐8.0）、IDEA（或Eclipse）。先说安装版本：Java项目最容易出问题的就是JDK版本不匹配。如果pom.xml里写的是Java 8，但你装了JDK 17，有些老依赖会直接报错。推荐用项目指定的版本，拿不准就看pom.xml或README.md里的说明。

第二步：初始化数据库。启动MySQL服务，用命令行或Navicat执行sql目录下的library.sql脚本。执行前先看一眼脚本内容，确认数据库名、账号密码的设置。有些项目要求你手动创建数据库：

CREATE DATABASE library_db DEFAULT CHARACTER SET utf8mb4; USE library_db; SOURCE /你的路径/library.sql;

如果脚本里已经包含了CREATE DATABASE，就不需要手动建库了。

第三步：修改配置文件。打开src/main/resources/application.yml（或application.properties），重点看这几项：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/library_db?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver

把用户名和密码改成你自己MySQL的。注意连接串里characterEncoding一定要有，否则后面读写中文数据全变问号。还有一个细节：MySQL 8.0的驱动类名是com.mysql.cj.jdbc.Driver，旧项目的驱动类名是com.mysql.jdbc.Driver，如果版本对不上会启动失败。

第四步：启动项目。在IDEA里导入Maven项目，等待依赖下载完成，然后运行Application主类。看到控制台输出Started Application in xx seconds，并出现Spring Boot的Banner，说明后端启动成功。如果启动时报“invalid zip archive: could not find eocd”这类错误，十有八九是Maven本地仓库里某个jar包下载损坏了，处理方式见第4部分的排查表。

第五步：访问测试。浏览器打开http://localhost:8080，如果看到登录页或首页，说明系统已经能访问了。先用项目默认的管理员账号登进去，例如admin/admin123，然后逐一测试读者注册、RFID卡绑定、借还书功能。这里提醒一句：如果你没有RFID读写器和实体标签，项目一般会提供“模拟模式”或“手动输入标签ID”的入口，你至少要把这条链路跑通。

3.5 数据库初始化与关键配置的常见坑

我见过太多毕业生栽在数据库配置上。有几个高频坑提前说，能帮你省几个小时：

第一个坑：MySQL 8.0的密码加密方式。如果项目用的老版本JDBC驱动，连接MySQL 8.0会报Public Key Retrieval is not allowed，解决方案是在连接串后面加上allowPublicKeyRetrieval=true。

第二个坑：时区问题。报错The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，这是时区设置导致的，在连接串加serverTimezone=Asia/Shanghai即可。

第三个坑：library.sql里的SQL语句语法和MySQL版本不兼容。比如老项目里用了ENGINE=MyISAM、TYPE=InnoDB这类老写法，在MySQL 8.0下可能直接报错。遇到这种情况，手动打开SQL文件，把表结构逐段复制到Navicat的执行窗口，哪段错了就改哪段，比埋头搜报错快多了。

第四个坑：初始化脚本执行一半报错。由于SQL脚本默认不启用事务，如果执行到一半报错，表可能建了一半。此时可以DROP DATABASE library_db;然后重建，再重新执行脚本，不要想着追加执行，环境干净才不容易出幺蛾子。

4. 常见问题与排查技巧实录

4.1 “导入资源包失败 caused by: invalid zip archive: could not find eocd”解法

这个报错在Maven项目里非常经典，热词里反复出现。EOCD是End of Central Directory的缩写，它是zip文件末尾的一个关键结构，损坏或缺了，解压工具或Java的ZipInputStream就认为这个文件无效。在Maven场景下，这个报错基本可以确定是：本地仓库里的某个jar包下载损坏了。

排查方法分两步。先看报错信息，确认具体是哪个jar包出了问题。在IDEA的Settings → Build Tools → Maven里找到Local repository路径，默认是C:\Users\你的用户名\.m2\repository。然后到对应目录下找到那个jar包，看文件大小是否为0KB，或者用压缩软件测试它是否能打开。确认损坏后，删掉这个jar包所在的整个目录，让Maven重新下载：

rm -rf ~/.m2/repository/org/example/example-lib mvn clean install

如果Maven重新下载还是损坏，很可能是网络问题导致的，建议换成国内镜像源（比如阿里云Maven镜像），然后在IDEA里执行reload all maven projects，基本能解决。

注意：千万不要尝试自己手工修改jar包或硬解这个问题，那样会把依赖搞得一团糟。删掉损坏的包让Maven重下，是效率最高的做法。

4.2 启动失败：端口占用、数据库连接失败

项目起不来，最常见的是两类报错。

第一类是Port 8080 was already in use。说明8080端口被占用了，可能是已经有一个实例在运行。如果你确认没有别的项目在跑，就找出占用端口的进程并处理。Windows下：

netstat -ano | findstr 8080 taskkill /PID 进程号 /F

Linux下：

lsof -i:8080 kill -9 进程号

当然，改端口也行，把application.yml里的server.port改成8081。但建议统一用8080，免得后面前端联调还要改跨域配置。

第二类是Communications link failure或Access denied for user 'root'@'localhost'。前者说明数据库连接不上，先确认MySQL服务有没有启动，再确认连接串里的IP、端口、库名是否对得上。后者说明账号密码错误，去检查application.yml里的用户名密码。这里有个细节：MySQL和Redis这类服务的密码如果包含特殊字符（如@、&），在YAML文件里要加引号，否则解析会出问题。

4.3 RFID读写器调试中的“玄学”问题

如果你手头有RFID硬件，调试时遇到的情况会更复杂一些。以下问题是RFID项目里最有代表性的，我按排查优先级给你列一下。

第一，串口被占用。读写器一般通过USB转串口或RJ45网口连接电脑。如果读写器初始化失败，先检查COM口号是否被其他程序占用（比如调试助手没关），或者换一个USB口后重新安装驱动。Windows下在“设备管理器 → 端口(COM和LPT)”里能看到设备对应的COM号，要和项目配置文件里的串口号一致。

第二，读取距离不稳定。高频设备的读写距离很容易受环境影响：旁边有金属物体、电源适配器、同频段的其他设备，都会让识别率下降。调试时尽量让标签和读写器天线的相对位置保持稳定，不要拿着书晃动做测试。

第三，标签ID读到了但数据库里查不到。这是业务逻辑问题，要检查标签ID有没有正确写入卡表。很多项目的流程是：先给读者发卡（把RFID标签ID写入reader表），之后才能用卡做借还操作。如果你随手拿个标签就刷，后台查不到这个人，当然会报“无效卡”。

第四，多标签误读。高频读写器虽然支持批量识别，但如果你把两张卡叠在一起刷，偶尔会出现只读其中一张，或者读错的情况。这是RFID的物理特性，产品设计上要有容错逻辑，比如要求用户每次刷一张卡，或者通过算法做去重和轮询。

4.4 从“跑起来”到“讲清楚”——答辩前的自检清单

系统跑通了，项目还没有结束。毕业设计最终要过答辩这一关，而答辩老师最常问的问题其实就那么几类。我建议你在答辩前用下面的清单自检一遍，每一条都要能用自己的话讲清楚：

• 为什么选RFID而不是二维码和条形码？（RFID能批量识别、穿透性读取、抗污损，这是核心优势）
• 你的系统架构是什么？前后端如何通信？（画一张部署图和一张时序图，你能现场画出来就行）
• 数据库表之间是什么关系？借书流程涉及哪些表？（从borrow_record表出发讲清楚外键关系）
• RFID读写器是如何集成到系统中的？数据格式是怎样的？（讲清楚串口/网口通信协议、数据帧的解析过程）
• 如果同一时间大量读者刷证，系统会不会卡？怎么优化？（这是加分题，可以从数据库索引、连接池、异步处理三个方向答）
• 系统的安全性怎么保证？（管理员密码加密、RFID标签复制风险、越权访问控制）

这些问题在论文里不一定全写，但你心里要有数。我在辅导学生答辩时说过一句话：毕业设计做得好不好，不完全看你功能多不多，而看你对自己做的东西理解有多深。一个能跑通的简单系统，比一个跑不起来的高大上系统，拿到的分数高得多。

5. 写在最后的一点经验

如果你现在手里正拿着“基于RFID的图书馆人员管理系统.zip”这个包，我的建议很简单：先把它当成一个“可以运行的学习资料”，而不是“可以直接交差的作业”。认真走一遍解压、配置、启动、调试的过程，把每一层报错都搞明白，你就会发现，RFID系统其实并不神秘，它就是把一个物理世界的信息采集问题，转换成数据库里的一条条记录而已。

我个人在实际操作中的体会是：这类项目最容易卡住人的地方，真的不是RFID原理，而是最基础的环境问题——解压之后文件乱码、数据库版本不匹配、Maven依赖下载失败。这些问题看起来琐碎，但恰恰是未来从事任何开发工作都躲不掉的基本功。所以别嫌麻烦，把这一关过了，你收获的不只是一份毕业设计，还有一套面对陌生项目时“从零到一”的拆解能力。

最后再分享一个小技巧：调试的时候，一直开着后台日志窗口，不要等到报错弹出来才去看。很多RFID相关的问题在界面上看不出来，但日志里会写得清清楚楚。养成看日志的习惯，比记住任何一条报错的解法都更有用。

本文还有配套的精品资源，点击获取