简介这是一套基于SpringBootVue前后端分离架构的一卡通消费系统源码面向计算机相关专业的毕业设计、课程设计学生以及需要实战练手的Java开发者。系统整合了Java、JSP、Servlet、MySQL等技术栈并支持人脸识别、扫码支付、实体卡三种消费方式能够帮助读者理解前后端分离项目的完整开发流程与业务落地思路。压缩包共748个文件约1.67MB其中380个Java文件承载后端业务逻辑92个Vue文件与82个JS文件构成前端交互界面另有55个XML、10个VM模板及若干SCSS、YML、Properties等配置资源目录结构清晰便于按模块查阅。目前已有90人学习关注。源码均经过本地编译验证下载后按文档配置环境即可运行项目难度适中内容经助教老师审定适合作为毕设或课设的参考方案也能为读者提供一卡通消费场景下的功能设计与排错思路。1. 一卡通消费系统为什么要走前后端分离从一台食堂 POS 说起食堂窗口前排队的人最怕什么不是菜不好吃是刷卡机卡住。一台 POS 要同时处理实体卡射频读头、扫码枪、人脸摄像头三路输入还要把扣款结果实时写回后台任何一路阻塞都会让队伍停摆。这套「基于 SpringBoot Vue 前后端分离架构的一卡通消费系统支持人脸、刷码、实体卡」要解决的就是把三种支付介质统一到一套账户体系里让消费、充值、对账、权限管理跑在同一套服务上。它适合谁适合做校园、园区、企业食堂这类封闭场景的开发者也适合想拿一个真实多介质支付项目练手 SpringBoot 与 Vue 前后端分离的人。核心难点不在界面而在三路介质如何归一到同一个用户 ID、同一笔流水、同一套幂等扣款逻辑。2. 三种支付介质怎么归一到一套账户架构与选型2.1 为什么用 SpringBoot Vue 而不是单体 JSP一卡通系统有个天然矛盾后台要对接硬件读卡器、人脸机、扫码枪前台要给收银员和财务用。如果还用 JSP 把页面和业务揉在一起改一个收银界面就要重启整个服务硬件回调一多线程就乱。前后端分离后Vue 负责收银台、管理后台、报表三套界面SpringBoot 只暴露 REST 接口硬件回调走独立 Controller互不干扰。选型上SpringBoot 用 2.7.x 或 3.x 都行但要注意热词里提到的「springboot版本太高」这个坑3.x 默认 Jakarta EE 命名空间很多老的人脸 SDK 示例还是 javax直接抄会编译不过。我一般新项目直接上 3.2.x老 SDK 用适配层包一层。Vue 这边用 Vue 3 Vite路由用 vue-router状态管理 Pinia 就够别上 Vuex 徒增复杂度。数据库 MySQL 8.0账户余额字段用 DECIMAL(12,2)绝对不能用 FLOAT否则对账时会出现 0.01 的玄学误差。缓存用 Redis 存会话和幂等令牌人脸特征值这种大字段单独存文件或对象存储数据库只存路径。2.2 三路介质统一到 user_id 的建模实体卡、二维码、人脸本质是三种「凭证」最终都要映射到一个账户。表设计上分三层表名作用关键字段t_user账户主体user_id, name, balance, statust_credential凭证映射cred_id, user_id, type(card/qr/face), valuet_trade交易流水trade_id, user_id, amount, channel, status, idempotent_keyt_credential的 type 字段区分介质value 存卡号、二维码 token 或人脸特征 ID。这样加一种新介质比如指纹只需插一条记录不用改表结构。交易表里 channel 记录实际走的哪一路方便后续按渠道对账。CREATE TABLE t_credential ( cred_id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, type VARCHAR(16) NOT NULL COMMENT card/qr/face, value VARCHAR(128) NOT NULL COMMENT 卡号/token/特征ID, status TINYINT DEFAULT 1, UNIQUE KEY uk_type_value (type, value), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明uk_type_value唯一索引保证同一张卡、同一个二维码 token 不会绑到两个账户这是防止「一卡多绑」的第一道闸。idx_user让「查某人所有凭证」走索引。参数上 value 长度给 128人脸特征如果直接存 base64 会超所以只存特征库里的 ID。2.3 扣款接口的幂等设计收银台最怕重复扣款。网络抖动时前端重试、硬件回调重发都会导致同一笔消费扣两次。做法是前端每次发起消费先生成一个idempotent_keyUUID随请求带上后端在 Redis 里SETNX这个 key成功才继续扣款失败直接返回上次结果。PostMapping(/consume) public Result consume(RequestBody ConsumeDTO dto) { String key dto.getIdempotentKey(); // SETNX 成功返回 true说明是首次请求 Boolean first redisTemplate.opsForValue() .setIfAbsent(trade: key, 1, 5, TimeUnit.MINUTES); if (Boolean.FALSE.equals(first)) { // 重复请求查上次流水直接返回 return Result.ok(tradeService.findByKey(key)); } return Result.ok(tradeService.doConsume(dto)); }逻辑说明setIfAbsent对应 Redis 的 SETNX5 分钟过期足够覆盖一次消费的完整链路。参数上 key 由前端生成后端不信任前端金额只信任 key 和 user_id金额从后端账户表读。注意doConsume里要用数据库行锁或乐观锁扣余额别只靠 Redis。3. 人脸、刷码、实体卡三路接入怎么落地3.1 实体卡读卡器串口数据到接口实体卡最常见的是 M1 卡或 CPU 卡读卡器通过 USB 转串口或网口输出卡号。收银端Vue 跑在收银机浏览器里拿不到串口所以常见做法是本地跑一个小代理程序读串口再通过 WebSocket 或本地 HTTP 把卡号推给前端。// 收银端连接本地读卡代理 const ws new WebSocket(ws://127.0.0.1:9100/card); ws.onmessage (evt) { const cardNo evt.data.trim(); if (!cardNo) return; // 卡号直接调后端消费接口channelcard axios.post(/api/consume, { credentialType: card, credentialValue: cardNo, amount: currentAmount, idempotentKey: crypto.randomUUID() }); };逻辑说明本地代理监听串口读到卡号就推给前端前端拿到后立即发起消费。参数上credentialValue就是卡号后端用t_credential查 user_id。注意读卡器可能连续上报同一张卡前端要做 1 秒去重否则一次刷卡触发多笔。3.2 刷码二维码 token 的生成与校验刷码分两种用户出示付款码被扫或收银台生成码让用户扫主扫。一卡通场景多用被扫用户在小程序或 App 里生成一个带时效的 token收银台扫码枪读入后调后端核销。public String generateQrToken(Long userId) { String token UUID.randomUUID().toString().replace(-, ); // 存 Redis60 秒有效绑定 userId redisTemplate.opsForValue().set(qr: token, userId.toString(), 60, TimeUnit.SECONDS); return token; } public Long resolveQrToken(String token) { String uid redisTemplate.opsForValue().get(qr: token); if (uid null) throw new BizException(二维码已过期); // 核销后立即删除防止一码多用 redisTemplate.delete(qr: token); return Long.valueOf(uid); }逻辑说明token 存 Redis 并设 60 秒过期核销即删保证一码一用。参数上 60 秒是经验值太短用户来不及出示太长有被盗刷风险。扫码枪本质是键盘输入设备前端监听回车即可拿到 token。3.3 人脸特征提取与比对放在哪一层人脸这块最容易翻车。热词里出现的 arcface、viewfacecore、easyai 都是常见方案但关键问题是特征提取和比对放在前端、后端还是人脸机本地我的经验是分场景。如果用人脸门禁机带算力的终端比对在终端本地完成终端只把 user_id 和置信度传给后端后端不碰图像隐私和性能都好。如果用普通摄像头图像传到后端用 SDK 提取特征再和特征库比对。// 后端人脸比对伪代码特征库用向量检索 public FaceResult matchFace(byte[] image) { float[] feature faceSdk.extract(image); // 提取 512 维特征 if (feature null) return FaceResult.noFace(); // 在特征库中找最近邻阈值 0.6 左右 MatchItem item faceIndex.search(feature, 0.6f); if (item null) return FaceResult.noMatch(); return FaceResult.ok(item.getUserId(), item.getScore()); }逻辑说明extract返回归一化后的特征向量search做余弦相似度检索阈值 0.6 是常见起点实际要按误识率和拒识率调。参数上特征维度取决于 SDKarcface 常见 512 维。注意人脸比对只是「识别」扣款还要走账户校验别把识别结果直接当支付成功。提示人脸数据属于敏感信息存储要加密传输走 HTTPS别把原始人脸图长期留在服务器上。4. 避坑与排查三路介质联调时最容易翻车的五件事4.1 刷卡扣了钱但界面没反应现象收银员看到读卡器亮灯但收银界面没跳成功用户却收到扣款短信。原因前端发起消费后后端已扣款但响应在返回途中丢失前端超时重试又带了新 key导致重复扣。解决前端超时后不要生成新 key用原 key 重试后端消费接口必须幂等重复 key 直接返回上次结果。4.2 二维码扫一次能用两次现象同一张付款码被两个收银台先后扫都扣款成功。原因核销逻辑用了get后delete两个请求并发时都读到了 token。解决用 Redis 的GETDEL或 Lua 脚本原子化「读删」保证只有一个请求能拿到 userId。4.3 人脸识别在逆光下集体失灵现象中午阳光直射窗口人脸机识别率骤降用户反复摘口罩。原因摄像头动态范围不够逆光时人脸区域过暗特征提取失败。解决调整摄像头安装角度避开直射或换宽动态摄像头软件侧加图像预处理直方图均衡但别指望算法能救硬件。4.4 SpringBoot 3 升级后人脸 SDK 编译不过现象项目从 2.7 升到 3.x人脸 SDK 的javax.servlet报找不到。原因SpringBoot 3 迁移到 Jakarta EE包名从 javax 变 jakarta。解决优先找 SDK 的新版本找不到就用适配层把 SDK 依赖隔离在独立模块用 javax 编译通过接口和主应用通信。4.5 余额对不上差几分钱现象财务对账时总账和流水差 0.01 到 0.05。原因余额字段用了 FLOAT/DOUBLE累加产生浮点误差或并发扣款时没用行锁出现超扣。解决金额一律 DECIMALJava 侧用 BigDecimal扣款 SQL 用UPDATE ... SET balance balance - ? WHERE user_id ? AND balance ?靠数据库原子性防超扣。5. 把三路介质压测到 500 TPS验证方法与一个收尾技巧系统能不能上生产不看功能全不全看并发下会不会乱。我一般用 JMeter 或 wrk 对消费接口做压测重点观察三个指标扣款成功率、余额一致性、幂等命中率。压测前先造数据1000 个账户每个账户绑一张卡、一个二维码、一条人脸特征。然后用脚本并发打消费接口channel 随机在三路里选。# 用 wrk 压消费接口带幂等 key wrk -t8 -c200 -d60s --latency \ -s consume.lua \ http://localhost:8080/api/consumeconsume.lua里每次请求生成唯一 keybody 里随机 user_id 和 channel。压完查两件事一是t_trade里有没有重复 key二是所有账户的balance 已消费金额是否等于初始余额。这两个对得上基本就稳了。一个收尾技巧把三路介质的消费入口收敛到一个ConsumeService.consume(userId, amount, channel, idempotentKey)方法实体卡、二维码、人脸三条链路只负责「解析出 userId」解析完统一调这个方法。这样扣款逻辑只有一份加介质不用动核心出问题也只查一个地方。我早期图省事给每路写了一套扣款结果改一个费率要改三处血泪教训。人脸这块再补一句别迷信 SDK 给的置信度阈值一定要用自己场景的真实数据跑一遍 ROC找到误识率和拒识率的平衡点。我见过直接抄 demo 阈值 0.8 的结果自己员工都刷不过。希望帮到你。本文还有配套的精品资源点击获取
