SpringBoot+Vue一卡通消费系统：三介质支付与账务一致性设计

简介：面向高校课程设计与毕业设计场景的一卡通消费系统源码包，采用 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 三类角色与三条支付链路

一卡通系统的需求不能只按功能列表堆，得按角色拆。通常的做法是分三类：持卡人（学生、员工）、消费终端（食堂窗口、自助机）、管理端（财务与卡务）。持卡人关心余额、流水、挂失；终端关心扣款速度和离线容错；管理端关心对账、补卡、异常流水处理。三条支付链路的差异必须提前想清楚：

这张表是后面所有设计的锚点。人脸链路走的是“身份确认后扣款”，刷码走的是“令牌换扣款”，实体卡走的是“介质验真后扣款”。三条链路最终都收敛到同一个扣款服务，这就是整套系统必须抽象出来的核心。选 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?useSSL=false&serverTimezone=Asia/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 RedisTemplate<String, 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 刷码支付的令牌设计与防重放

刷码链路的核心不是二维码怎么画，而是令牌怎么管。令牌里要包含账户标识、签发时间、随机串，后端签名后存 Redis，key 形如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，证明幂等没重复扣款 → 再展示余额不足和挂失账户被拦截。这条链路一跑完，架构、事务、幂等、风控四个点全讲到了。

验收标准建议做成表格，答辩时直接投出来，比口头描述有说服力：

代码层面留一个可演示的幂等测试接口，用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、为什么令牌用原子删除、为什么流水要冗余前后余额、为什么以服务端余额为准。这些问题答得出来，方案才算真的立住。我吃过一次亏，演示只跑了成功路径，被追问余额不足时事务怎么回滚，现场翻代码才讲清楚，从那以后每次验收我都强制把失败路径和幂等测试放进演示脚本，先跑通再讲亮点。希望这套结构和验收清单能帮到你，拿去对着改比从零搭省太多时间。

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