简介面向高校课程设计与毕业设计场景的一卡通消费系统源码包采用 SpringBoot 与 Vue 前后端分离架构结合 Java、JSP、Servlet、MySQL 等技术覆盖人脸识别、扫码支付与实体卡刷卡三种消费方式适合具备一定 Java Web 基础、希望完整走通前后端联调与数据库设计的学习者参考复用。压缩包共 748 个文件约 1.67MB以 380 个 Java 后端源码、92 个 Vue 组件、82 个 JavaScript 脚本和 83 个 SVG 图标为主另含 XML 配置、SCSS 样式、YML 与 properties 配置项及批量启动打包脚本前后端分层清晰、便于按模块检索。源码均经本地编译验证按文档配置环境即可运行已有 90 人学习。读者可获得可运行的三端消费业务实现、数据库与接口组织范例、前端页面交互代码及部署脚本模板为毕设答辩与课设作业提供完整可对照的参考。1. 一卡通消费系统到底难在哪先看真实需求再谈选型很多同学做一卡通消费系统第一反应是“增删改查加个余额字段”真到联调才发现麻烦全在细节里刷码要防重放、人脸识别要控制误识率、实体卡写卡失败要能回滚三端余额还必须对得上。这套基于 SpringBoot Vue 前后端分离架构的一卡通消费系统覆盖人脸、刷码、实体卡三种支付入口本质是解决“一个账户、多种介质、一套账目”的一致性难题。它适合正在做毕设或课程设计、需要一套能讲清架构又能跑通流程的同学也适合想参考前后端分离工程结构的开发者。下面按需求、设计、落地、验收的顺序把整套方案拆开讲重点放在能照着改的模块划分和关键实现上。2. 需求拆解与技术选型三角色、三介质、一条账2.1 三类角色与三条支付链路一卡通系统的需求不能只按功能列表堆得按角色拆。通常的做法是分三类持卡人学生、员工、消费终端食堂窗口、自助机、管理端财务与卡务。持卡人关心余额、流水、挂失终端关心扣款速度和离线容错管理端关心对账、补卡、异常流水处理。三条支付链路的差异必须提前想清楚介质交互方式关键风险校验重点人脸摄像头采集1:N 比对误识、照片攻击活体检测 阈值刷码动态二维码有效期短截图重放、并发重复扣一次性令牌 幂等实体卡读卡器读卡号/扇区复制卡、写卡失败卡号与账户绑定校验这张表是后面所有设计的锚点。人脸链路走的是“身份确认后扣款”刷码走的是“令牌换扣款”实体卡走的是“介质验真后扣款”。三条链路最终都收敛到同一个扣款服务这就是整套系统必须抽象出来的核心。选 SpringBoot 是因为它把事务、拦截器、定时任务这些账务相关的基础设施给全了MyBatis 或 MyBatis-Plus 处理余额更新的行锁语句比 ORM 更可控Vue 做前后端分离管理端和自助端可以复用组件人脸和刷码这类需要调摄像头的页面也好单独维护。2.2 技术栈清单与选型理由后端用 SpringBoot MyBatis-Plus MySQL Redis前端 Vue2 或 Vue3 配 Element UI / Element Plus人脸比对可接本地算法 SDK 或调用部署在局域网内的人脸服务刷码用后端生成的短时效令牌。Redis 在这套系统里承担两件事二维码令牌的过期控制以及扣款时的分布式锁避免同一账户并发扣款出现负余额。MySQL 承担账务主数据余额字段必须配合乐观锁版本号或SELECT ... FOR UPDATE使用。# application.yml 关键片段 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/card_system?useSSLfalseserverTimezoneAsia/Shanghai username: card_app password: ${DB_PASSWORD} # 不要硬编码走环境变量 redis: host: 127.0.0.1 port: 6379 database: 3 card: qrcode: ttl-seconds: 60 # 刷码令牌有效期 face: threshold: 0.82 # 人脸比对相似度阈值按实际样本调配置里的ttl-seconds决定二维码多久失效太短用户体验差太长重放风险高60 秒是常见折中threshold需要拿真实样本跑一遍再定直接抄网上的 0.9 往往导致识别通过率过低。2.3 数据库主表设计账户、介质、流水三件套账务类系统的表设计决定了后期改需求的痛苦程度。核心就三张账户表存余额和状态介质表存人脸特征或卡号与账户的绑定关系流水表记每一笔扣款和充值。流水表一定要冗余“扣款前余额”和“扣款后余额”对账时这就是黑匣子出问题能直接定位。CREATE TABLE account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_no VARCHAR(32) NOT NULL UNIQUE COMMENT 学号/工号, balance DECIMAL(10,2) NOT NULL DEFAULT 0.00, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 0冻结, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) COMMENT账户主表; CREATE TABLE pay_channel ( id BIGINT PRIMARY KEY AUTO_INCREMENT, account_id BIGINT NOT NULL, type TINYINT NOT NULL COMMENT 1人脸 2二维码 3实体卡, credential VARCHAR(255) NOT NULL COMMENT 人脸特征ID/卡号哈希, status TINYINT NOT NULL DEFAULT 1, UNIQUE KEY uk_type_cred (type, credential), KEY idx_account (account_id) ) COMMENT支付介质绑定表; CREATE TABLE trade_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, trade_no VARCHAR(40) NOT NULL UNIQUE COMMENT 业务流水号用于幂等, account_id BIGINT NOT NULL, amount DECIMAL(10,2) NOT NULL, before_bal DECIMAL(10,2) NOT NULL, after_bal DECIMAL(10,2) NOT NULL, channel TINYINT NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1成功 0失败 2待冲正, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_account_time (account_id, created_at) ) COMMENT交易流水表;trade_no的唯一索引是整套系统防重复扣款的第一道闸客户端重试、网络超时重发都靠它挡住。before_bal / after_bal这两个字段看着冗余真出账目争议时没有它们就得翻全部流水重算血泪经验。3. 总体架构与模块划分前后端分离下的四层结构3.1 四层架构与请求走向这套系统按前后端分离组织后端再分四层接口层Controller、业务层Service、领域服务层扣款、认证、对账、数据访问层Mapper。前端分管理端和终端应用两套。一次刷码支付的完整走向是终端页调后端申请二维码 → 后端生成带签名的令牌写 Redis → 终端展示 → 扫码端提交令牌 → 业务层校验令牌并加锁 → 扣款服务执行事务 → 返回结果并作废令牌。关键设计点在于“令牌只负责证明这次请求合法扣款只认 trade_no”。令牌被校验通过后立刻从 Redis 删除防止同一码被两人同时扫扣款服务内部再用trade_no做幂等判断双保险。这种分层的好处是以后要加指纹或工牌等新介质只需在认证层加一个校验器扣款链路完全不改。3.2 扣款服务的核心实现扣款是最容易翻车的地方贴一段核心逻辑。Service public class PayService { Autowired private AccountMapper accountMapper; Autowired private TradeRecordMapper tradeMapper; Autowired private RedisTemplateString, String redis; /** * param accountId 账户ID * param amount 扣款金额单位元保留两位 * param tradeNo 业务流水号由调用方生成全局唯一用于幂等 * param channel 1人脸 2二维码 3实体卡 */ Transactional(rollbackFor Exception.class) public PayResult pay(Long accountId, BigDecimal amount, String tradeNo, int channel) { // 幂等同一 tradeNo 已成功则直接返回不重复扣款 TradeRecord exist tradeMapper.selectByTradeNo(tradeNo); if (exist ! null exist.getStatus() 1) { return PayResult.duplicate(exist); } // 行锁读账户保证并发下余额判断准确 Account acc accountMapper.selectForUpdate(accountId); if (acc null || acc.getStatus() ! 1) { throw new BizException(账户不可用); } if (acc.getBalance().compareTo(amount) 0) { throw new BizException(余额不足); } BigDecimal after acc.getBalance().subtract(amount); // 更新余额并写入流水二者必须同一事务 accountMapper.updateBalance(accountId, after, acc.getVersion()); tradeMapper.insert(TradeRecord.success(tradeNo, accountId, amount, acc.getBalance(), after, channel)); return PayResult.ok(after); } }selectForUpdate对应 Mapper 里的SELECT ... FOR UPDATE作用是锁住这一行直到事务结束避免两个终端同时扣同一账户导致余额算错。updateBalance里带上version做乐观锁兜底正常走行锁时版本号不会冲突但分布式部署或有人绕过服务直接改库时它能拦住脏写。参数tradeNo由终端生成格式建议“终端号 时间戳 随机数”保证全局唯一。失败时看日志里的 tradeNo 就能串起整条链路这是排查问题的入口。3.3 前端两套应用的职责边界Vue 这边我不建议做成一个大而全的项目。管理端负责用户管理、介质绑定、流水查询、对账导出终端端负责扫码、人脸采集、扣款结果展示页面数量少但要求响应快、断网有提示。两端共用一套 axios 封装和权限路由把“请求拦截、统一错误码、token 续期”抽成公共模块避免两边逻辑各写一遍后面改不动。人脸采集页面通常单独处理摄像头权限和失败降级采集不到就走刷码或实体卡这条降级链路要在设计阶段就写进接口文档别等答辩现场演示翻车。4. 三种支付介质的落地细节人脸、刷码、实体卡4.1 刷码支付的令牌设计与防重放刷码链路的核心不是二维码怎么画而是令牌怎么管。令牌里要包含账户标识、签发时间、随机串后端签名后存 Rediskey 形如qr:{tradeNo}value 存账户和金额上限过期时间就是配置里的 60 秒。校验时先查 Redis 存在性存在则删除并继续扣款删除动作必须是原子的。public String issueQrToken(Long accountId, BigDecimal limit) { String tradeNo T System.currentTimeMillis() ThreadLocalRandom.current().nextInt(1000, 9999); String payload accountId | limit | tradeNo; String sign DigestUtils.md5Hex(payload SECRET); // 简易签名生产可用 HMAC redis.opsForValue().set(qr: tradeNo, payload | sign, 60, TimeUnit.SECONDS); return tradeNo . sign; // 前端据此生成二维码图片 } public void consumeQrToken(String token) { String tradeNo token.split(\\.)[0]; // delete 返回 true 才说明这次是唯一一次消费天然防并发重放 Boolean ok redis.delete(qr: tradeNo); if (!Boolean.TRUE.equals(ok)) { throw new BizException(二维码已失效或已被使用); } }用redis.delete的返回值做“消费成功”的判据比先 get 再 delete 安全得多后者在并发下存在窗口期。签名的作用是防止前端伪造 tradeNo 直接调扣款接口校验签名不过直接拒绝。扫码端拿到 token 后先调consumeQrToken再进扣款顺序不能反反了就会出现“扣了款但码没作废”的漏洞。4.2 人脸识别链路的工程化处理人脸这块最容易写成“调个接口就完事”实际要考虑采集质量、活体、阈值、降级。工程上的做法是终端采集时先做质量检测光照、人脸大小、遮挡不合格直接提示重采不把垃圾图送比对比对返回相似度和活体分数两个都过阈值才放行。人脸特征不存原图只存特征向量或算法侧返回的特征 ID绑定关系落在pay_channel表credential字段存特征 ID 的哈希。public boolean verifyFace(Long accountId, FaceSample sample) { // 1. 质量门禁避免模糊图拉低整体通过率 if (sample.getQuality() 0.6) return false; // 2. 活体检测防照片和屏幕翻拍 if (sample.getLiveness() 0.7) return false; // 3. 1:1 比对用账户绑定的特征做比对比 1:N 更稳 FaceFeature bound channelMapper.getFaceFeature(accountId); double score faceSdk.compare(bound, sample.getFeature()); return score faceThreshold; // 阈值来自配置别写死 }注意这里是 1:1 而不是 1:N终端先由用户输入学号或刷卡确定账户再做 1:1 比对准确率和速度都远好于全场 1:N 搜索。很多方案一上来就做 1:N样本一多误识率飙升这是典型踩坑点。阈值一定要用自己场景的样本回归食堂逆光环境和实验室灯光下的最优值能差一截。4.3 实体卡读写的容错与绑定校验实体卡链路的风险在读卡器和写卡失败。读卡只读取卡号或扇区密文后端拿卡号哈希去pay_channel查绑定账户查不到就提示去卡务端绑定。写卡充值写余额到卡失败时必须回滚数据库侧记录或者把卡内余额当作辅助、以服务端余额为准二者选其一并在文档里写死不能两套账并行。public void bindCard(Long accountId, String rawCardNo) { String cred DigestUtils.sha256Hex(rawCardNo CARD_SALT); // 卡号哈希唯一防止一张卡绑多个账户 if (channelMapper.existsByCredential(cred)) { throw new BizException(该卡已绑定其他账户); } channelMapper.insert(accountId, 3, cred); }CARD_SALT是服务端固定盐作用是不让卡号明文落库即便库被拖也拿不到原始卡号。以服务端余额为准是更省心的选择卡内余额只做离线兜底场景并且要在对账任务里定期校准别让两侧长期偏离。5. 避坑与排查账务系统最容易翻车的五个点5.1 并发扣款把余额扣成负数现象是压力测试或食堂高峰期出现负余额。原因是没有行锁也没有幂等两个请求同时读到相同余额各自扣减。解决办法是扣款事务里SELECT ... FOR UPDATE锁行trade_no唯一索引兜住重试再叠加乐观锁版本号做最后防线。三样东西至少要两样只靠应用层判断早晚出事。5.2 二维码被截图重放现象是同一张码在短时间内被多次扣款成功。原因是令牌校验用了先查后删中间有窗口。解决办法是改用 Redis 原子删除的返回值判定消费成功令牌有效期压到 60 秒以内并且令牌与账户、金额上限绑定换账户使用直接拒绝。5.3 人脸误识率在真实环境失控现象是实验室演示没问题换到食堂逆光就频繁失败或误通过。原因是阈值照抄、没做质量门禁、用了 1:N。解决办法是加采集质量检测与活体检测采用 1:1 比对阈值用自己的场景样本回归并且保留刷码和实体卡作为降级通道演示时也别只押人脸一条路。5.4 事务边界写错导致流水与余额不一致现象是余额扣了但流水没记或流水记了余额没动。原因是把 Redis 操作、外部算法调用混进了数据库事务异常一抛事务回滚但缓存已改。解决办法是外部调用放在事务外先校验后开事务事务内只做数据库写流水与余额更新必须在同一个Transactional里失败一起回滚。5.5 对账任务缺失问题攒到月底才爆现象是平时没人发现月底对账发现差额但查不出是哪笔。原因是缺定时对账和异常流水标记。解决办法是加每日对账任务按账户汇总流水与余额比对差额流水置为“待冲正”并告警before_bal / after_bal字段此时就是唯一的后悔药。6. 验收与答辩用一条完整链路证明系统是活的验收别从“功能列表打勾”开始那样讲不出深度也容易被追问到卡壳。我一般会准备一条贯穿三角色的演示链路把设计意图藏在操作里管理端建账户并绑定实体卡 → 终端刷码完成一次扣款 → 同一账户改用人脸再扣一次 → 管理端查流水展示before_bal / after_bal与trade_no→ 现场重复提交同一trade_no证明幂等没重复扣款 → 再展示余额不足和挂失账户被拦截。这条链路一跑完架构、事务、幂等、风控四个点全讲到了。验收标准建议做成表格答辩时直接投出来比口头描述有说服力验收项操作通过标准三介质扣款分别刷码、人脸、实体卡均成功且余额减少一致幂等性同一 tradeNo 提交两次仅一条成功流水余额只扣一次并发安全同账户并发 20 次扣款无负余额流水条数与成功次数一致令牌防重放同一二维码扫两次第二次明确提示已失效异常回滚扣款中途强制抛异常余额与流水均未变对账跑一次日终对账任务账户余额与流水汇总一致代码层面留一个可演示的幂等测试接口用bash循环打两次同一个 tradeNo现场跑一眼就能看出效果# 连续两次提交同一笔流水第二次应返回 duplicate 而不是再扣一次 for i in 1 2; do curl -s -X POST http://localhost:8080/api/pay \ -H Content-Type: application/json \ -d {accountId:1001,amount:5.00,tradeNo:T202405011200001,channel:2} echo done答辩时被问到“为什么这么设计”回答要落到取舍上为什么用 1:1 而不是 1:N、为什么令牌用原子删除、为什么流水要冗余前后余额、为什么以服务端余额为准。这些问题答得出来方案才算真的立住。我吃过一次亏演示只跑了成功路径被追问余额不足时事务怎么回滚现场翻代码才讲清楚从那以后每次验收我都强制把失败路径和幂等测试放进演示脚本先跑通再讲亮点。希望这套结构和验收清单能帮到你拿去对着改比从零搭省太多时间。本文还有配套的精品资源点击获取