尧图网站建设 
简介这是一份基于RFID技术的公司管理系统完整源码适合计算机、电子信息等专业学生用于课程设计、期末大作业或毕业设计参考。项目围绕员工身份识别与公司日常管理展开包含登录认证、注册、人员管理、岗位调整、员工列表等核心功能模块可作为学习PHP原生开发与RFID应用整合的实战样例。压缩包共42个文件以15个PHP业务脚本为主辅以CSS、JavaScript和HTML前端页面另有数据库配置、图标字体及说明文档包体约688KB结构清晰、便于本地部署和二次修改。已有364人学习下载适合具备一定PHP基础、希望快速搭建公司管理原型并深入理解RFID业务流程的开发者。资源提供了完整可直接运行的全部源码下载后可对照代码学习前后端交互、会话管理和基础增删改查实现也能在此基础上扩展考勤、门禁或物资管理等进阶功能是兼顾课程答辩与工程实践的实用参考资料。1. 基于RFID的公司管理系统源码.zip解压后先别急着看代码“源码无坑”是假象。这种压缩包常见组合是一个带 UI 的 Demo、串口读取示例、几个增删改查页面真正解压后能直接跑起来的并不多。第一次尝试会撞上串口被占用、卡号格式不统一、数据库脚本和实体类对不上这串老问题。下面按能跑的顺序来拆先把读卡器到数据库的链路说清再看源码里哪些模块真正可用然后用 Spring Boot 和 Vue3 搭出最小可运行的刷卡事件流最后补上防重、防复制和流水对账。适合正在做二次开发或者要拿一个压缩包快速交付的工程师。2. 拆解RFID公司管理系统的数据链路与源码结构2.1 读卡器把卡号交给上位机之前发生了什么先把硬件侧的套路弄清楚。RFID 读卡器通过射频场给卡片供电卡片响应防碰撞指令读卡器拿到卡片的 UID。桌面级读卡器通常把这一串动作封装成三种对外接口串口输出字符串、USB HID 模拟键盘输出数字、或者通过网络模块回传 HTTP 数据。公司管理系统中最常见的卡片是 13.56MHz 的 M1 卡也就是“RFID门禁采用什么芯片卡”这个问题里最常出现的答案。安全要求更高的地方会用 CPU 卡但离线源码包里极少原生支持。需要把 UID 理解成“卡上的只读序列号”而不是业务工号。普通读卡器只负责把 UID 翻译成字符判断“这张卡是不是本公司的卡”是后台程序的事。有些读卡器会把扇区数据跟在 UID 后面一起输出如果源码只截取前 8 个十六进制字符后面多出来的扇区字节就会混进卡号里刷卡记录因此出现一长串脏字符。2.2 管理系统的三个核心对象人员、卡、记录一个能长期维护的 RFID 公司管理系统数据库里至少要有三组东西人员组织表、卡表、刷卡事件表。卡表不能简单在员工表上加一个 card_no 字段否则临时访客、换卡、补卡、多门禁共用读卡器时逻辑会混乱。独立的卡表可以保留历史绑定关系同一张卡换人绑定时原来的事件流水不会被删除。CREATE TABLE rfid_card ( id INT PRIMARY KEY AUTO_INCREMENT, card_uid VARCHAR(32) NOT NULL, employee_id INT DEFAULT NULL, card_type TINYINT DEFAULT 1 COMMENT 1固定 2临时, card_status TINYINT DEFAULT 1 COMMENT 1正常 0挂失 2注销, bind_time DATETIME DEFAULT NULL, UNIQUE KEY uk_uid (card_uid) ) COMMENTRFID卡基本信息; CREATE TABLE rfid_event ( id BIGINT PRIMARY KEY AUTO_INCREMENT, card_uid VARCHAR(32) NOT NULL, reader_code VARCHAR(16) NOT NULL, event_type TINYINT NOT NULL DEFAULT 1, scan_time DATETIME NOT NULL, handle_status TINYINT DEFAULT 0 ) COMMENTRFID刷卡流水;card_uid 用 VARCHAR(32) 是为了兼容十六进制和十进制两种输出格式服务层统一做去空格、大小写归一化。event_type 用来区分进门、出门、巡更点、仓库领料比只看一张考勤记录表更灵活。唯一索引只保证卡号不重复但“同一个人有没有重复领卡”要在业务代码里查这是唯一索引管不住的。2.3 从 zip 源码里识别可用模块拿到压缩包第一件事不是打开 README而是看项目结构。常见技术栈是 Java Spring Boot Vue 3也有一部分是 C# WinForm 或 PHP。前端依赖在 package.json 里后端在 pom.xml 里。真正有硬件接入痕迹的后端会引入串口库比如 jSerialComm、RXTX、.NET 的 SerialPort 类若只有一句“读卡器厂商 SDK 地址”的注释却没有任何依赖多半是半成品。模块常见实现判断标准硬件接入串口监听、USB-HID 回调、HTTP POST是否有 serial 包或读卡回调类事件处理防抖、黑白名单、落库是否有 RfidScanService 并调用 mapper页面展示Vue3 Element Plus 表格是否有 /api/rfid/event/latest 接口报表ECharts、Excel 导出是否有按日/按月统计 SQL要特别警惕那些用 Python 读测试文件的“教程源码”数据来自本地 CSV而不是读卡器。如果你要交付给公司用至少确认后端有对串口事件源的监听逻辑而不是一个手动调用的控制器。把 event_type 扩展成仓库领料、停车进出也可以对接 WMS 仓储物流管理系统或停车场管理系统数据链路完全一样。3. 用Spring Boot把RFID刷卡事件接进公司管理系统3.1 先选对接方式串口还是HTTP大多数桌面读卡器在操作系统里表现为一个虚拟串口Spring Boot 里最稳妥的接入方式是监听串口并解析一帧数据。帧格式以厂商文档为准常见的是“头码 0x02 卡号 ASCII 尾码 0x03”也有直接回车换行结尾的字符串。不要凭经验写解析建议先用串口工具观察原始输出。对接方式适用场景优点风险串口监听桌面读卡器、门禁一体机实时、可控串口占用、线缆限制USB HID 模拟键盘免驱读卡器即插即用焦点冲突、无回调事件HTTP 回调网络读卡器跨平台需要内网地址和接口鉴权// 以 jSerialComm 为例监听串口并逐字节拼卡号 SerialPort port SerialPort.getCommPorts()[0]; port.setBaudRate(9600); port.setNumDataBits(8); port.setNumStopBits(1); port.setParity(SerialPort.NO_PARITY); port.openPort(); port.addDataListener(new SerialPortDataListener() { Override public int getListeningEvents() { return SerialPort.LISTENING_EVENT_DATA_AVAILABLE; } Override public void serialEvent(SerialPortEvent event) { if (event.getEventType() ! SerialPort.LISTENING_EVENT_DATA_AVAILABLE) return; byte[] buf new byte[port.bytesAvailable()]; port.readBytes(buf, buf.length); // 拼帧、提取卡号、提交业务事件 } });jSerialComm 的常用参数是波特率 9600 或 115200具体看读卡器说明书。8 数据位、1 停止位、无校验比较通用。最容易踩的坑是bytesAvailable()不等于一帧长度一个读卡器可能把一帧拆成两段到达因此要维护一个 StringBuffer碰到头码 0x02 后开始缓存遇到尾码 0x03 才整体提交。若按单次回调直接解析高频刷卡时必然漏单。3.2 设计一个防重且不丢数据的刷卡接口后台不一定要在串口线程里直接写库可以把事件封装成 JSON再 POST 给一个内部接口这样硬件层、业务层、页面层完全解耦。内部接口至少要做三件事判断卡是否存在判断卡状态记录流水。最后再加 2 秒防重。RestController public class RfidScanController { PostMapping(/api/rfid/scan) public Result? scan(RequestBody RfidScanRequest req) { String cardUid normalizeCardUid(req.getCardUid()); RfidCard card cardMapper.findByUid(cardUid); if (card null || card.getStatus() ! 1) { eventMapper.insert(Event.of(cardUid, req.getReaderCode(), 2, new Date())); return Result.error(未登记的卡); } // 防重同一卡、同一读卡头 2 秒内只产生一条有效记录 if (!rfidEventService.isDuplicate(cardUid, req.getReaderCode(), 2)) { eventMapper.insert(Event.of(cardUid, req.getReaderCode(), 1, new Date())); return Result.ok(ok); } return Result.ok(duplicate); } }normalizeCardUid 负责处理大小写和空格十进制卡号补零成 8 位十六进制也在这里做。isDuplicate 的 2 秒是配置化的参数名建议叫rfid.duplicate-window2000不要用数据库唯一索引做防重因为不同读卡器、不同门点在线程里可以同时提交业务上允许同一张卡在多个读卡器同时刷但要挡住同一台读卡器上的连续重复帧。3.3 页面上的实时记录先别上 WebSocketVue3 后台里先不用 WebSocketsetInterval 配合 lastId 拉增量记录就够用。WebSocket 在这里反而是负担要多处理断线重连、心跳、鉴权公司管理系统里的实时记录只需要在办公网络里展示最新几十条轮询足够了。let lastId 0; setInterval(async () { const { data } await http.get(/api/rfid/event/latest, { params: { afterId: lastId, limit: 30 } }); if (data.list.length) { records.unshift(...data.list); lastId data.list[0].id; } }, 3000);这段代码避免每次把整张表查一遍只请求新产生的记录。lastId 存在前端内存里适合单页面操作如果要求刷新后还能看到完整历史服务端需要先返回首次快照再叠加增量。这个方案比每 3 秒刷新整个表格对数据库压力小得多也足够支撑一个 30 人左右的办公场景。如果后期点位多了再升级成 Server-Sent Events前端代码不用大改。4. 跑通RFID管理系统源码前要处理的四个边界问题4.1 数据库脚本和实体类对不上离线源码包的建表脚本经常是旧版本实体类却是新版本启动时直接报 Unknown column。先把 schema.sql 里的列名和实体类属性列出来对比缺字段就先补齐不要急着启动。grep -n class RfidCard -A 40 src/main/java/com/company/rfid/entity/RfidCard.java mysql -uroot -p rfid_db docs/sql/schema.sqlgrep 只做快速定位真正要确认的是 MyBatis XML 或 JPA 注解里的字段映射。很多 “Unknown column card_uid in field list” 不是 SQL 写错而是导入的 schema.sql 是 v1实体类已经升到 v2。4.2 读卡器串口被占或驱动没装“RFID数据连接错误什么问题”是源码帖下最常见的问题九成出在端口上。Windows 里程序写死 COM3插上却是 COM8Linux 下没有读写权限。先看系统侧ls -l /dev/ttyUSB* /dev/ttyACM* dmesg | grep -i usb sudo chmod 666 /dev/ttyUSB0chmod 666解决当前用户打不开串口的问题。如果 dmesg 能看到设备但程序port.openPort()返回 false再用lsof | grep ttyUSB查占用。还有一个隐蔽的坑厂商 SDK 后台常驻进程会锁住 COM 口应用层再打开就会失败这时候结束厂商自带的那个工具进程。现象检查点常用处理打开串口失败端口号是否存在设备管理器 / ls /dev/ttyUSB*能打开但无数据波特率不匹配先试 9600再试 115200有数据但乱码数据位或校验位不对8N1 是缺省改 7E1刷卡后无反应串口被其他进程占用lsof / tasklist 查进程4.3 卡号格式和扇区数据被混在一起读卡器返回的长字符串里往往既有 UID 又有扇区数据。处理办法是定一个 CardMessage 解析器只截取帧中对应位置的字节。这个解析器要同时处理帧头、长度和校验位不能只做 substring否则设备差异会直接打穿后续所有逻辑。// 假定原始帧格式: AA BB CC DD EE FF GG HH 后跟扇区字节 String payload raw.substring(raw.indexOf(02) 1); String uid payload.substring(0, 8).toUpperCase();更麻烦的是 UID 的正序反序问题。同样一张卡A 读卡器输出 A1B2C3D4B 读卡器输出 D4C3B2A1。解决方案不是在代码里做全排列而是在设备接入表里维护一台读卡器一个解析策略。这个解析策略要写进文档否则换人维护时会反复出现“卡号变了”的假 bug。4.4 依赖加载失败和前端跨域旧源码用 Maven 或 npm 拉历史版本依赖经常失败优先换成国内镜像再不行锁定源码里原来的版本号。前端跑不起来时检查 Node 版本Vue3 项目通常用 Node 16 以上。前后端分离项目最常见的联调问题是跨域很多源码把跨域写死在过滤器里改起来麻烦直接在 WebMvcConfigurer 里统一配置更清晰Spring Boot 加一个配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:5173) .allowedMethods(GET, POST, PUT, DELETE); } }allowedOrigins 写具体地址不要用*否则带凭证访问时会被浏览器拦截。5173 是 Vite 默认端口后端 8080 在同一个内网时这样配置就能解决登录和接口请求的跨域问题。5. 别把UID当成唯一凭证RFID系统加固与对账5.1 给卡加一层扇区校验普通 M1 卡 UID 出厂写死但市面上已出现可写 UID 的兼容卡这就是“RFID怎么复制”能成立的原因。如果系统只读 UID复制卡能顶替原卡进出。正确做法是发卡时向指定扇区写入卡片内部编号和随机因子刷卡时不仅读 UID还要读扇区数据做校验。代码中可以用CardCredentialService封装这个逻辑让业务层只接收CardCredentialResult不直接暴露原始扇区内容。提示如果读卡器 SDK 只能读 UID没有读数据块指令这种读卡器就不适合做有安全要求的门禁考勤。短期不想换 CPU 卡也要做到不同地点的系统不要共用同一个 UID 作为主键前台页面不展示完整扇区明文。这样即使卡被复制内部校验码也不会被轻易拿到RFID 信号的屏蔽卡套可以作为员工主动防护手段但它替代不了系统校验。5.2 用对账 SQL 查超发和重复绑定最后一个实用技巧是给每日刷卡流水做对账。先查同一 UID 是否绑定了多个员工SELECT c.card_uid, COUNT(DISTINCT c.employee_id) AS emp_count FROM rfid_card c GROUP BY c.card_uid HAVING emp_count 1;emp_count 大于 1 说明换卡没解绑或者库里存在脏数据。再用另一句找出 30 天没刷卡但状态仍为正常的卡做回收或注销SELECT c.id, c.card_uid, MAX(e.scan_time) AS last_time FROM rfid_card c LEFT JOIN rfid_event e ON c.card_uid e.card_uid WHERE c.card_status 1 GROUP BY c.id, c.card_uid HAVING last_time IS NULL OR last_time DATE_SUB(NOW(), INTERVAL 30 DAY);把这两条 SQL 写进每日巡检脚本就能在卡片状态真正影响门禁和考勤之前发现问题。实际运行时先在测试库里确认card_uid在事件表中存在且两种设备表现一致再把这套对账逻辑接到自动化告警上。本文还有配套的精品资源点击获取 RFID公司管理系统源码实战：从串口读卡到Spring Boot集成
简介这是一份基于RFID技术的公司管理系统完整源码适合计算机、电子信息等专业学生用于课程设计、期末大作业或毕业设计参考。项目围绕员工身份识别与公司日常管理展开包含登录认证、注册、人员管理、岗位调整、员工列表等核心功能模块可作为学习PHP原生开发与RFID应用整合的实战样例。压缩包共42个文件以15个PHP业务脚本为主辅以CSS、JavaScript和HTML前端页面另有数据库配置、图标字体及说明文档包体约688KB结构清晰、便于本地部署和二次修改。已有364人学习下载适合具备一定PHP基础、希望快速搭建公司管理原型并深入理解RFID业务流程的开发者。资源提供了完整可直接运行的全部源码下载后可对照代码学习前后端交互、会话管理和基础增删改查实现也能在此基础上扩展考勤、门禁或物资管理等进阶功能是兼顾课程答辩与工程实践的实用参考资料。1. 基于RFID的公司管理系统源码.zip解压后先别急着看代码“源码无坑”是假象。这种压缩包常见组合是一个带 UI 的 Demo、串口读取示例、几个增删改查页面真正解压后能直接跑起来的并不多。第一次尝试会撞上串口被占用、卡号格式不统一、数据库脚本和实体类对不上这串老问题。下面按能跑的顺序来拆先把读卡器到数据库的链路说清再看源码里哪些模块真正可用然后用 Spring Boot 和 Vue3 搭出最小可运行的刷卡事件流最后补上防重、防复制和流水对账。适合正在做二次开发或者要拿一个压缩包快速交付的工程师。2. 拆解RFID公司管理系统的数据链路与源码结构2.1 读卡器把卡号交给上位机之前发生了什么先把硬件侧的套路弄清楚。RFID 读卡器通过射频场给卡片供电卡片响应防碰撞指令读卡器拿到卡片的 UID。桌面级读卡器通常把这一串动作封装成三种对外接口串口输出字符串、USB HID 模拟键盘输出数字、或者通过网络模块回传 HTTP 数据。公司管理系统中最常见的卡片是 13.56MHz 的 M1 卡也就是“RFID门禁采用什么芯片卡”这个问题里最常出现的答案。安全要求更高的地方会用 CPU 卡但离线源码包里极少原生支持。需要把 UID 理解成“卡上的只读序列号”而不是业务工号。普通读卡器只负责把 UID 翻译成字符判断“这张卡是不是本公司的卡”是后台程序的事。有些读卡器会把扇区数据跟在 UID 后面一起输出如果源码只截取前 8 个十六进制字符后面多出来的扇区字节就会混进卡号里刷卡记录因此出现一长串脏字符。2.2 管理系统的三个核心对象人员、卡、记录一个能长期维护的 RFID 公司管理系统数据库里至少要有三组东西人员组织表、卡表、刷卡事件表。卡表不能简单在员工表上加一个 card_no 字段否则临时访客、换卡、补卡、多门禁共用读卡器时逻辑会混乱。独立的卡表可以保留历史绑定关系同一张卡换人绑定时原来的事件流水不会被删除。CREATE TABLE rfid_card ( id INT PRIMARY KEY AUTO_INCREMENT, card_uid VARCHAR(32) NOT NULL, employee_id INT DEFAULT NULL, card_type TINYINT DEFAULT 1 COMMENT 1固定 2临时, card_status TINYINT DEFAULT 1 COMMENT 1正常 0挂失 2注销, bind_time DATETIME DEFAULT NULL, UNIQUE KEY uk_uid (card_uid) ) COMMENTRFID卡基本信息; CREATE TABLE rfid_event ( id BIGINT PRIMARY KEY AUTO_INCREMENT, card_uid VARCHAR(32) NOT NULL, reader_code VARCHAR(16) NOT NULL, event_type TINYINT NOT NULL DEFAULT 1, scan_time DATETIME NOT NULL, handle_status TINYINT DEFAULT 0 ) COMMENTRFID刷卡流水;card_uid 用 VARCHAR(32) 是为了兼容十六进制和十进制两种输出格式服务层统一做去空格、大小写归一化。event_type 用来区分进门、出门、巡更点、仓库领料比只看一张考勤记录表更灵活。唯一索引只保证卡号不重复但“同一个人有没有重复领卡”要在业务代码里查这是唯一索引管不住的。2.3 从 zip 源码里识别可用模块拿到压缩包第一件事不是打开 README而是看项目结构。常见技术栈是 Java Spring Boot Vue 3也有一部分是 C# WinForm 或 PHP。前端依赖在 package.json 里后端在 pom.xml 里。真正有硬件接入痕迹的后端会引入串口库比如 jSerialComm、RXTX、.NET 的 SerialPort 类若只有一句“读卡器厂商 SDK 地址”的注释却没有任何依赖多半是半成品。模块常见实现判断标准硬件接入串口监听、USB-HID 回调、HTTP POST是否有 serial 包或读卡回调类事件处理防抖、黑白名单、落库是否有 RfidScanService 并调用 mapper页面展示Vue3 Element Plus 表格是否有 /api/rfid/event/latest 接口报表ECharts、Excel 导出是否有按日/按月统计 SQL要特别警惕那些用 Python 读测试文件的“教程源码”数据来自本地 CSV而不是读卡器。如果你要交付给公司用至少确认后端有对串口事件源的监听逻辑而不是一个手动调用的控制器。把 event_type 扩展成仓库领料、停车进出也可以对接 WMS 仓储物流管理系统或停车场管理系统数据链路完全一样。3. 用Spring Boot把RFID刷卡事件接进公司管理系统3.1 先选对接方式串口还是HTTP大多数桌面读卡器在操作系统里表现为一个虚拟串口Spring Boot 里最稳妥的接入方式是监听串口并解析一帧数据。帧格式以厂商文档为准常见的是“头码 0x02 卡号 ASCII 尾码 0x03”也有直接回车换行结尾的字符串。不要凭经验写解析建议先用串口工具观察原始输出。对接方式适用场景优点风险串口监听桌面读卡器、门禁一体机实时、可控串口占用、线缆限制USB HID 模拟键盘免驱读卡器即插即用焦点冲突、无回调事件HTTP 回调网络读卡器跨平台需要内网地址和接口鉴权// 以 jSerialComm 为例监听串口并逐字节拼卡号 SerialPort port SerialPort.getCommPorts()[0]; port.setBaudRate(9600); port.setNumDataBits(8); port.setNumStopBits(1); port.setParity(SerialPort.NO_PARITY); port.openPort(); port.addDataListener(new SerialPortDataListener() { Override public int getListeningEvents() { return SerialPort.LISTENING_EVENT_DATA_AVAILABLE; } Override public void serialEvent(SerialPortEvent event) { if (event.getEventType() ! SerialPort.LISTENING_EVENT_DATA_AVAILABLE) return; byte[] buf new byte[port.bytesAvailable()]; port.readBytes(buf, buf.length); // 拼帧、提取卡号、提交业务事件 } });jSerialComm 的常用参数是波特率 9600 或 115200具体看读卡器说明书。8 数据位、1 停止位、无校验比较通用。最容易踩的坑是bytesAvailable()不等于一帧长度一个读卡器可能把一帧拆成两段到达因此要维护一个 StringBuffer碰到头码 0x02 后开始缓存遇到尾码 0x03 才整体提交。若按单次回调直接解析高频刷卡时必然漏单。3.2 设计一个防重且不丢数据的刷卡接口后台不一定要在串口线程里直接写库可以把事件封装成 JSON再 POST 给一个内部接口这样硬件层、业务层、页面层完全解耦。内部接口至少要做三件事判断卡是否存在判断卡状态记录流水。最后再加 2 秒防重。RestController public class RfidScanController { PostMapping(/api/rfid/scan) public Result? scan(RequestBody RfidScanRequest req) { String cardUid normalizeCardUid(req.getCardUid()); RfidCard card cardMapper.findByUid(cardUid); if (card null || card.getStatus() ! 1) { eventMapper.insert(Event.of(cardUid, req.getReaderCode(), 2, new Date())); return Result.error(未登记的卡); } // 防重同一卡、同一读卡头 2 秒内只产生一条有效记录 if (!rfidEventService.isDuplicate(cardUid, req.getReaderCode(), 2)) { eventMapper.insert(Event.of(cardUid, req.getReaderCode(), 1, new Date())); return Result.ok(ok); } return Result.ok(duplicate); } }normalizeCardUid 负责处理大小写和空格十进制卡号补零成 8 位十六进制也在这里做。isDuplicate 的 2 秒是配置化的参数名建议叫rfid.duplicate-window2000不要用数据库唯一索引做防重因为不同读卡器、不同门点在线程里可以同时提交业务上允许同一张卡在多个读卡器同时刷但要挡住同一台读卡器上的连续重复帧。3.3 页面上的实时记录先别上 WebSocketVue3 后台里先不用 WebSocketsetInterval 配合 lastId 拉增量记录就够用。WebSocket 在这里反而是负担要多处理断线重连、心跳、鉴权公司管理系统里的实时记录只需要在办公网络里展示最新几十条轮询足够了。let lastId 0; setInterval(async () { const { data } await http.get(/api/rfid/event/latest, { params: { afterId: lastId, limit: 30 } }); if (data.list.length) { records.unshift(...data.list); lastId data.list[0].id; } }, 3000);这段代码避免每次把整张表查一遍只请求新产生的记录。lastId 存在前端内存里适合单页面操作如果要求刷新后还能看到完整历史服务端需要先返回首次快照再叠加增量。这个方案比每 3 秒刷新整个表格对数据库压力小得多也足够支撑一个 30 人左右的办公场景。如果后期点位多了再升级成 Server-Sent Events前端代码不用大改。4. 跑通RFID管理系统源码前要处理的四个边界问题4.1 数据库脚本和实体类对不上离线源码包的建表脚本经常是旧版本实体类却是新版本启动时直接报 Unknown column。先把 schema.sql 里的列名和实体类属性列出来对比缺字段就先补齐不要急着启动。grep -n class RfidCard -A 40 src/main/java/com/company/rfid/entity/RfidCard.java mysql -uroot -p rfid_db docs/sql/schema.sqlgrep 只做快速定位真正要确认的是 MyBatis XML 或 JPA 注解里的字段映射。很多 “Unknown column card_uid in field list” 不是 SQL 写错而是导入的 schema.sql 是 v1实体类已经升到 v2。4.2 读卡器串口被占或驱动没装“RFID数据连接错误什么问题”是源码帖下最常见的问题九成出在端口上。Windows 里程序写死 COM3插上却是 COM8Linux 下没有读写权限。先看系统侧ls -l /dev/ttyUSB* /dev/ttyACM* dmesg | grep -i usb sudo chmod 666 /dev/ttyUSB0chmod 666解决当前用户打不开串口的问题。如果 dmesg 能看到设备但程序port.openPort()返回 false再用lsof | grep ttyUSB查占用。还有一个隐蔽的坑厂商 SDK 后台常驻进程会锁住 COM 口应用层再打开就会失败这时候结束厂商自带的那个工具进程。现象检查点常用处理打开串口失败端口号是否存在设备管理器 / ls /dev/ttyUSB*能打开但无数据波特率不匹配先试 9600再试 115200有数据但乱码数据位或校验位不对8N1 是缺省改 7E1刷卡后无反应串口被其他进程占用lsof / tasklist 查进程4.3 卡号格式和扇区数据被混在一起读卡器返回的长字符串里往往既有 UID 又有扇区数据。处理办法是定一个 CardMessage 解析器只截取帧中对应位置的字节。这个解析器要同时处理帧头、长度和校验位不能只做 substring否则设备差异会直接打穿后续所有逻辑。// 假定原始帧格式: AA BB CC DD EE FF GG HH 后跟扇区字节 String payload raw.substring(raw.indexOf(02) 1); String uid payload.substring(0, 8).toUpperCase();更麻烦的是 UID 的正序反序问题。同样一张卡A 读卡器输出 A1B2C3D4B 读卡器输出 D4C3B2A1。解决方案不是在代码里做全排列而是在设备接入表里维护一台读卡器一个解析策略。这个解析策略要写进文档否则换人维护时会反复出现“卡号变了”的假 bug。4.4 依赖加载失败和前端跨域旧源码用 Maven 或 npm 拉历史版本依赖经常失败优先换成国内镜像再不行锁定源码里原来的版本号。前端跑不起来时检查 Node 版本Vue3 项目通常用 Node 16 以上。前后端分离项目最常见的联调问题是跨域很多源码把跨域写死在过滤器里改起来麻烦直接在 WebMvcConfigurer 里统一配置更清晰Spring Boot 加一个配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:5173) .allowedMethods(GET, POST, PUT, DELETE); } }allowedOrigins 写具体地址不要用*否则带凭证访问时会被浏览器拦截。5173 是 Vite 默认端口后端 8080 在同一个内网时这样配置就能解决登录和接口请求的跨域问题。5. 别把UID当成唯一凭证RFID系统加固与对账5.1 给卡加一层扇区校验普通 M1 卡 UID 出厂写死但市面上已出现可写 UID 的兼容卡这就是“RFID怎么复制”能成立的原因。如果系统只读 UID复制卡能顶替原卡进出。正确做法是发卡时向指定扇区写入卡片内部编号和随机因子刷卡时不仅读 UID还要读扇区数据做校验。代码中可以用CardCredentialService封装这个逻辑让业务层只接收CardCredentialResult不直接暴露原始扇区内容。提示如果读卡器 SDK 只能读 UID没有读数据块指令这种读卡器就不适合做有安全要求的门禁考勤。短期不想换 CPU 卡也要做到不同地点的系统不要共用同一个 UID 作为主键前台页面不展示完整扇区明文。这样即使卡被复制内部校验码也不会被轻易拿到RFID 信号的屏蔽卡套可以作为员工主动防护手段但它替代不了系统校验。5.2 用对账 SQL 查超发和重复绑定最后一个实用技巧是给每日刷卡流水做对账。先查同一 UID 是否绑定了多个员工SELECT c.card_uid, COUNT(DISTINCT c.employee_id) AS emp_count FROM rfid_card c GROUP BY c.card_uid HAVING emp_count 1;emp_count 大于 1 说明换卡没解绑或者库里存在脏数据。再用另一句找出 30 天没刷卡但状态仍为正常的卡做回收或注销SELECT c.id, c.card_uid, MAX(e.scan_time) AS last_time FROM rfid_card c LEFT JOIN rfid_event e ON c.card_uid e.card_uid WHERE c.card_status 1 GROUP BY c.id, c.card_uid HAVING last_time IS NULL OR last_time DATE_SUB(NOW(), INTERVAL 30 DAY);把这两条 SQL 写进每日巡检脚本就能在卡片状态真正影响门禁和考勤之前发现问题。实际运行时先在测试库里确认card_uid在事件表中存在且两种设备表现一致再把这套对账逻辑接到自动化告警上。本文还有配套的精品资源点击获取