简介这是一份基于Java与JavaScript实现的网上银行转账系统设计源码面向Java入门开发者、毕业设计选题学生以及需要快速搭建转账业务原型的研发人员。系统覆盖用户认证、账户信息管理、资金转入转出、事务记录与异常处理等核心环节前端通过JSP和JavaScript完成交互展示后端以19个Java源文件承载主要业务逻辑。资源包共46个文件除Java文件外还包含14个JSP页面文件、7个XML配置文件、2个属性文件、说明文档与JS脚本压缩包大小仅356KB目录结构清晰便于按模块阅读。目前已有279人学习适合作为银行转账类项目的完整参考。通过源码可以学习认证与授权流程、数据库连接配置、Maven依赖管理以及常见Web安全防护的落地方案并可在现有代码基础上进行二次开发与功能扩展。1. 网上银行转账系统的核心不是页面是账怎么才能不错网上银行转账系统是 Java 课程设计里出现频率极高的题目但很多人把它做成了「网页版模拟转账」页面漂亮、数据能查能改一聊到「A 扣了钱 B 没加上怎么办」就答不上来。真正决定这套源码价值的不是界面是事务和数据库设计。核心业务很聚焦开户、查询、转账、流水。难点全在转账链路——扣款、加款、写流水必须要么全成要么全败余额不能因为并发变成负数同一笔转账不能因为重复点击被执行两次。这几个问题恰好也是后端开发日常最常被问到的部分。适合正在做 Java 课程设计的学生也适合想用一个完整后端项目练手、给简历攒素材的初级开发者。下面按选型、建表、代码、排坑的顺序讲照着我这个思路做能跑起来也能答得上「为什么这么设计」。2. 技术栈怎么选Spring Boot 工程版与 ServletJSP 课设版的差距网上流传的「基于 Java 的网上银行转账系统设计源码」里很大一部分是 Servlet JSP JDBC 的老写法有的甚至把业务逻辑直接写在 JSP 页面里。这种写法不是不能跑但你要用 Java 把这个系统做扎实用 Spring Boot 是更省力的路线。判断标准很简单你想花更多时间调 JSP 页面还是花更多时间想清楚转账这件事本身。2.1 三条技术路线对比课设答辩、简历作品、工程实训我给自己带的学生做过一个对比列在这里供你选型时参考技术路线适合场景事务与并发处理主要风险Servlet JSP JDBC课设答辩、教学要求强行指定手动开启 Connection 事务代码里必须自己 commit/rollback稍不注意就漏JSP 里写业务、连接不释放、事务边界混乱是三个常见的翻车点Spring Boot MyBatis MySQL课程设计、简历项目、工程入门一个Transactional注解搞定声明式事务事务边界一目了然需要会一点 Maven 和 Spring 基础环境问题偶发Spring Boot MyBatis-Plus Redis想做强扩展、分布式锁等进阶内容和上面一样但引入更多组件复杂度上升课设范围内 Redis 不是必须引入后反而增加部署成本如果是应付必须用 JSP 的课设要求那老老实实走第一条如果题目没有硬性指定我强烈建议用 Spring Boot。这套「基于 Java」的转账系统Spring Boot 版本对你的收益更大一是代码量少一半二是简历和面试聊到项目时Spring Boot 是主流语境很多 Java 课程设计案例源码都还在用老写法你能用工程化方式做出来是一个明显的加分项。2.2 按 Spring Boot 落地的工程骨架目录结构与启动方式Spring Boot 版本的最小工程不需要太复杂的结构保持层次清晰即可。我一般会这样建包com.bank.transfer ├── TransferApplication.java // 启动类 ├── controller │ ├── AuthController.java // 登录、登出 │ └── TransferController.java // 转账接口 ├── service │ ├── AccountService.java // 账户查询、余额变动 │ ├── TransferService.java // 转账主流程事务边界在这里 │ └── TradeRecordService.java // 流水记录 ├── mapper │ ├── AccountMapper.java │ └── TradeRecordMapper.java ├── entity │ ├── Account.java │ └── TradeRecord.java └── common ├── Result.java // 统一返回体 └── BizException.java // 业务异常触发事务回滚这个目录的划分原则是controller 只做参数接收和响应包装service 放业务判断和事务控制mapper 只碰 SQL。转账这种强资金语义的系统出问题时你可以在 service 层加断点看到从参数校验到扣款、加款、写流水的完整调用链排查效率比逻辑堆在 JSP 里高得多。工程创建后用 IDEA 或命令行启动Maven 工程两个命令就够了mvn clean package -DskipTests java -jar target/bank-transfer-0.0.1-SNAPSHOT.jar这里提醒一句教室机器或老电脑上经常因为 Java 环境变量配置指向了旧版本 JDK 而跑不起来。Spring Boot 3.x 要求 JDK 17Spring Boot 2.x 用 JDK 8 就能跑。启动前先java -version确认版本别在环境上浪费半小时。数据库连接配置放在application.yml里spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/bank_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true几个参数的含义值得说清楚maximum-pool-size是连接池上限课设并发量不大20 足够characterEncodingutf8是解决中文乱码的关键少了它转账备注里存中文大概率变问号serverTimezoneAsia/Shanghai是 MySQL 8.x 连接时防止时间差 8 小时的必填项。map-underscore-to-camel-case打开后数据库的account_no能自动映射到 Java 的accountNo省掉一长串 resultMap。2.3 分层设计的职责边界为什么不能把扣款写在 Controller 里我见过一份课设源码转账逻辑整个写在 JSP 里页面一刷新就执行一次扣款余额直接扣穿。这就是典型的分层混乱。分层不是八股文的负担它给「问题定位」留了一条清晰的路径参数不对找 controller业务判断不对找 serviceSQL 不对找 mapper运行时异常看堆栈第一个框架层就能定位。以转账为例controller 层只做三件事接收 JSON 请求体、调用 service、返回统一结果。service 层负责所有业务规则金额合法性、账户状态、支付密码、余额充足性、事务边界。mapper 层只暴露deductBalance、addBalance、insertRecord这类单一职责的方法。每一层都只做一件事出问题的时候你能迅速判断是「传参错」「逻辑错」还是「SQL 错」不用把整段代码从头读一遍。3. 数据库建模与转账核心表decimal、唯一索引、防超扣 SQL很多课程设计源码把重心放在页面跳转上数据库只有一张用户表。但转账系统的地基是表结构账户表和流水表这两张表的设计直接决定了并发下会不会超扣、对账时能不能把账算平。这一章把建表 SQL 和关键字段的设计理由讲透。3.1 账户表与流水表字段设计金额用 decimal(18,2)别用 double先看建表 SQL两张表就够用CREATE TABLE account ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, account_no varchar(32) NOT NULL COMMENT 银行账号, user_name varchar(64) NOT NULL COMMENT 户名, password varchar(128) NOT NULL COMMENT 登录密码(哈希存储), pay_password varchar(128) NOT NULL COMMENT 支付密码(哈希存储), balance decimal(18,2) NOT NULL DEFAULT 0.00 COMMENT 当前余额, initial_balance decimal(18,2) NOT NULL DEFAULT 0.00 COMMENT 初始余额对账用, status tinyint NOT NULL DEFAULT 1 COMMENT 1-正常 0-冻结, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_account_no (account_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT银行账户表; CREATE TABLE trade_record ( id bigint NOT NULL AUTO_INCREMENT, trade_no varchar(64) NOT NULL COMMENT 交易流水号全局唯一, from_account_no varchar(32) NOT NULL COMMENT 付款账号, to_account_no varchar(32) NOT NULL COMMENT 收款账号, amount decimal(18,2) NOT NULL COMMENT 交易金额, trade_type tinyint NOT NULL COMMENT 1-转账 2-存款 3-取款, status tinyint NOT NULL DEFAULT 1 COMMENT 1-成功 0-失败, remark varchar(255) DEFAULT NULL COMMENT 备注, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_trade_no (trade_no), KEY idx_from_account (from_account_no), KEY idx_to_account (to_account_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT交易流水表;最关键的字段选择是balance和amount都用decimal(18,2)。浮点数的 0.1 加 0.2 不等于 0.3这是 IEEE 754 的二进制表示局限带来的问题存金额用 double 或 float连续转账几次后余额就会多出或少掉一个极小的小数账怎么都对不平。decimal(18,2)是定点数它能精确表示到分18 位总长度对课设和个人项目完全够。account_no和trade_no都建唯一索引。唯一索引的作用不只是查询加速更是幂等控制的兜底手段第 4 章会专门讲这里先在建表时把它留好。initial_balance这个字段很多人会忽略但它是对账的关键锚点——没有它你无法用「当前余额 初始余额 流水净变动」这个等式来验证数据一致性。3.2 转账核心 SQL为什么 update 的 where 子句里要带 balance 条件转账的正确性最终落在两条 SQL 上。这是整套系统最不能写错的地方-- 扣款余额不够或账户被冻结时影响行数为0事务直接回滚 UPDATE account SET balance balance - #{amount}, update_time NOW() WHERE account_no #{fromAccountNo} AND status 1 AND balance #{amount}; -- 加款收款账户存在且正常就加钱影响行数为0说明对方账户有问题 UPDATE account SET balance balance #{amount}, update_time NOW() WHERE account_no #{toAccountNo} AND status 1;很多人习惯「先 SELECT 查余额Java 里判断够不够再 UPDATE 扣款」这个写法在并发下会出事两个请求同时读到余额 1000 元都判断余额充足都执行扣款最终余额变成 -200 元。问题出在 SELECT 和 UPDATE 之间有时间窗口这个窗口里第二个请求读到的余额已经过期了。把balance #{amount}写进 UPDATE 的 WHERE 子句是把余额判断和扣款合并成了一个原子操作。数据库执行 UPDATE 时会锁住这一行第二个 UPDATE 必须等第一个提交后才能执行这时它发现余额已经不够影响行数为 0service 层据此抛出异常并回滚。这套机制靠的是数据库行锁不是 Java 层的同步锁所以即使你的应用部署多个实例也不会超扣。这里顺带说一个容易被忽略的点判断deductBalance的返回值如果影响行数为 0不能当成功处理必须抛异常。同理加款的影响行数为 0 说明收款账户异常也要抛异常让事务回滚。两条 UPDATE 只要有一条失败前面成功的操作必须全部撤销。3.3 交易流水号生成时间戳加随机数为什么不行流水的trade_no需要全局唯一常见的错误是用System.currentTimeMillis()加随机数或者直接用数据库自增 ID。时间戳加随机数在低并发下看着没问题但转账操作是毫秒级并发的同一毫秒内两个请求生成相同的随机数完全可能一旦撞了唯一索引直接报错转账失败。用自增 ID 做流水号外部能看到你的业务量而且多表合并数据时容易冲突。我一般用这种方式业务单号bizId由前端生成格式是yyyyMMddHHmmss加 6 位随机数再加账户后 4 位比如202506141030155218900001。后端把bizId当作trade_no存库唯一索引兜底重复插入时数据库直接拒绝。有更高要求的场景可以用雪花算法但课设和个人项目里前端生成业务单号配合数据库唯一索引已经足够。4. 转账主流程实现从 Controller 参数校验到 Service 事务边界表结构定好之后代码实现的核心是转账主链路。这一章按请求进来之后的顺序把 Controller、Service、Mapper 三层各写什么、事务边界画在哪里一步不落地讲清楚。4.1 Controller 层参数接收、统一返回、不写业务转账接口的 Controller 很简单这是正确形态RestController RequestMapping(/api/bank) public class TransferController { Autowired private TransferService transferService; PostMapping(/transfer) public ResultString transfer(RequestBody Valid TransferRequest request) { // controller 只做两件事把请求交给 service把结果包装返回 transferService.transfer(request); return Result.success(转账成功); } }Valid触发 JSR-303 参数校验TransferRequest里用注解声明基础规则。amount字段必须用String接收前端传来的是 JSON 字符串用String接收再转BigDecimal可以避免double在反序列化时引入精度误差。fromAccountNo、toAccountNo、payPassword都加NotBlankamount加NotNull。Controller 层不写 if 判断。原因是 controller 只负责「翻译」HTTP 层余额够不够、密码对不对这些业务规则放在 service 层才符合分层逻辑也方便在单元测试里直接调 service 验证。很多课设代码在 controller 里写一堆if (balance amount)的判断代码能跑但面试官问你「事务在哪一层」的时候你会发现自己很难自圆其说。4.2 Service 层Transactional 加在哪里为什么是 rollbackFor Exception.class转账主流程集中在TransferService.transfer()方法里这是整套系统最重要的方法Service public class TransferServiceImpl implements TransferService { Autowired private AccountMapper accountMapper; Autowired private TradeRecordMapper tradeRecordMapper; Override Transactional(rollbackFor Exception.class) public void transfer(TransferRequest request) { // 1. 业务参数校验金额必须大于0 if (request.getAmount() null || request.getAmount().compareTo(BigDecimal.ZERO) 0) { throw new BizException(转账金额必须大于0); } // 2. 转出账户扣款余额不足或账户异常时影响行数为0抛异常回滚 int deductRows accountMapper.deductBalance( request.getFromAccountNo(), request.getAmount()); if (deductRows 0) { throw new BizException(转出账户余额不足或账户状态异常); } // 3. 转入账户加款收款账户异常时抛异常触发整个事务回滚 int addRows accountMapper.addBalance( request.getToAccountNo(), request.getAmount()); if (addRows 0) { throw new BizException(转入账户不存在或状态异常); } // 4. 写入交易流水与扣款、加款同处一个事务 TradeRecord record new TradeRecord(); record.setTradeNo(request.getBizId()); record.setFromAccountNo(request.getFromAccountNo()); record.setToAccountNo(request.getToAccountNo()); record.setAmount(request.getAmount()); record.setTradeType(1); record.setStatus(1); record.setRemark(request.getRemark()); tradeRecordMapper.insert(record); } }这个方法的四个步骤必须在同一个事务里。Transactional(rollbackFor Exception.class)的含义是方法内抛出任何Exception或其子类整个事务回滚。这里有个高频坑——Spring 的Transactional默认只对RuntimeException回滚如果你抛的是SQLException这类受检异常不指定rollbackForSpring 默认不回滚结果就是扣款成功、流水没写账直接对不上。事务边界就画在这个方法上第 2 步扣款、第 3 步加款、第 4 步写流水是同生共死的任何一步失败前面成功的操作全部撤销。你不需要在代码里写try-catch来手动回滚那样反而可能把异常吞掉导致回滚失效。还要注意一点Transactional只能通过代理生效同一个类里this.transfer()自调用会让注解失效正确做法是 controller 注入 service由外部调用。4.3 幂等性同一笔转账怎么保证不被执行两次真实场景里用户手抖点了两次「确认转账」或者前端网络超时后自动重试同一笔业务请求会到达后端两次。如果不做控制余额被扣两遍流水多一条。幂等控制的常见做法是把「业务单号」当作唯一键前端在用户点击提交时生成一个bizId整个请求生命周期内不变后端把它写到trade_record.trade_no字段里。由于trade_no建了唯一索引第二次请求插入流水时会抛DuplicateKeyException转账方法整体回滚。你可以捕获这个异常返回「该笔订单已处理」而非报错。这个方案不依赖 Redis 分布式锁靠数据库唯一约束兜底实现成本最低也最可靠。配合前端的「提交按钮置灰 防重复点击」双保险下来重复扣款的概率就基本被堵死了。这个点也是后端常见的面试场景题能讲清楚「唯一索引兜底」这个方案的通常会被高看一眼。5. 转账系统最常见的翻车点现象、原因、排查方法这一章是排坑专章。我按自己实际遇到过的频率列了 5 个在转账系统上最容易出问题的地方。每条按「现象 - 原因 - 解决」来写你可以直接对照排查。5.1 事务不生效抛了异常余额还是被扣了现象转账时故意在加款后抛异常结果数据库里扣款成功了加款和流水都没有账对不上。原因最常见的有三种。一是Transactional没指定rollbackFor Exception.class而代码里catch (Exception e)之后抛出的恰好是受检异常默认不回滚二是事务方法被同类方法this调用Spring 代理不生效三是方法被private修饰代理无法拦截。解决统一用Transactional(rollbackFor Exception.class)且只加在public方法上确保事务方法由外部 Bean 调用不要在同类内部自调用。排查时在事务方法第一行和最后一行各打一条日志看抛异常后有没有打印「回滚完成」比看代码猜快得多。这个点也是 Java 面试八股文里反复被问的理解透了对面试也有实际帮助。5.2 金额精度翻车连续转账后账面对不上现象转 0.1 元再转 0.2 元数据库余额显示为 999999.9999999998带一堆小数尾巴。原因double和float是二进制浮点数无法精确表示 0.1、0.2 这类十进制小数运算次数多了误差积累就暴露了。数据库字段用的可能是doubleJava 里金额用的也可能是double。解决数据库字段统一用decimal(18,2)Java 里金额统一用BigDecimal并且用new BigDecimal(String)构造不要用new BigDecimal(double)。前端传金额时用字符串接收再转换。这条排查要查两处建表 SQL 的字段类型和 VO 类里的字段类型两边不一致也会出问题。5.3 并发超扣同时转账导致余额变负数现象账户余额 1000两个请求各转 600并发提交后两个请求都提示成功余额变成 -200。原因代码里先SELECT查余额Java 判断足够后再UPDATE。两个请求同时读到了 1000都通过了余额判断先后执行扣款。问题出在 SELECT 和 UPDATE 之间不是原子的。解决用第 3.2 节里的方案把balance #{amount}写进 UPDATE 的 WHERE 子句通过影响行数判断是否扣款成功。这是数据库行锁保证的原子操作不需要在 Java 层加 synchronized。验证方法开 50 个线程同时转同一账户跑完检查账户余额是否为「初始余额 - 成功扣款总额」。5.4 重复提交双击按钮导致同一笔转两次现象用户点了一次「转账」页面卡顿又点了一次结果钱转了两笔流水两条。原因前端没有做防重复提交后端也没有幂等控制。第一次请求还在处理中第二次请求已经进来了。解决前端提交后立即把按钮置灰同时后端用bizId做幂等控制——把前端生成的业务单号写入trade_record.trade_no字段靠唯一索引拦截重复请求。注意bizId不能用时间戳要用「时间戳 随机数 账户后缀」之类足够随机的组合否则两个用户可能生成同一个单号。5.5 中文乱码转账备注全是问号现象转账备注里填「房租」库里存的是「」。原因JDBC 连接串没有指定characterEncodingutf8或者 MySQL 表字符集不是 utf8mb4。Tomcat 接收 POST 请求时解析编码也可能不对。解决application.yml的数据库 URL 加上useUnicodetruecharacterEncodingutf8建表时统一用utf8mb4如果请求里有中文确认服务端也指定了 UTF-8 编码。乱码问题排查起来很折腾但往往最后就是一行配置的事。6. 上线前的最后一步并发压测与对账 SQL 兜底功能跑通只是开始真正检验转账系统靠不靠谱一是并发下不出超扣二是事后能对平账。这一章给两个验证手段做完这两步你的系统才算是「敢说能上线」的状态。6.1 用线程池模拟并发转账验证不会超扣手头没有压测工具可以用 JUnit 加线程池快速验证。思路是起 200 个线程同时从一个账户往另一个账户转账全部跑完后校验两个账户的余额是否等于期望值。Test public void testConcurrentTransfer() throws InterruptedException { int threadCount 200; ExecutorService pool Executors.newFixedThreadPool(50); CountDownLatch ready new CountDownLatch(threadCount); CountDownLatch start new CountDownLatch(1); CountDownLatch done new CountDownLatch(threadCount); for (int i 0; i threadCount; i) { pool.execute(() - { try { ready.countDown(); start.await(); // 所有线程就绪后同时放行模拟真实并发 transferService.transfer(buildRequest( 100000000001, 100000000002, 100.00, generateBizId())); } catch (Exception e) { // 记录失败的请求全部应为余额不足而非系统异常 } finally { done.countDown(); } }); } ready.await(); start.countDown(); done.await(); // 断言转出账户余额 初始余额 - 200 * 100失败的请求不扣钱 BigDecimal delta new BigDecimal(20000.00); Assert.assertEquals(initialBalance.subtract(delta), accountMapper.getBalance(100000000001)); }跑完只看两个指标失败的请求必须都是「余额不足」这类业务异常不能出现数据不一致最终余额必须精确等于期望值差一分钱都说明有 bug。这个测试建议单独准备一份测试数据库别拿手里的数据跑。6.2 每日对账 SQL让账自己证明自己并发测试通过不等于可以高枕无忧系统运行中总会有意外——程序 bug、脏数据、人为误操作。对账的作用是每天定时跑一遍发现异常立刻暴露而不是等用户投诉。对账的核心等式是当前余额 初始余额 所有流水净变动。把流水按账户聚合算出每个账户的净流入再和余额比对SELECT a.account_no, a.balance, a.initial_balance, IFNULL(t.net_amount, 0) AS flow_amount, (a.initial_balance IFNULL(t.net_amount, 0)) AS expected_balance FROM account a LEFT JOIN ( SELECT account_no, SUM(change_amount) AS net_amount FROM ( SELECT to_account_no AS account_no, amount AS change_amount FROM trade_record WHERE status 1 UNION ALL SELECT from_account_no AS account_no, -amount AS change_amount FROM trade_record WHERE status 1 ) flow GROUP BY account_no ) t ON t.account_no a.account_no WHERE a.balance (a.initial_balance IFNULL(t.net_amount, 0));查询结果为空说明所有账户余额和流水一致有结果每一行都是一个对不上账的账户expected_balance和balance的差额就是错账金额。这个 SQL 不需要很高深的技术就是 UNION ALL 加 GROUP BY但它是整套系统的最后一道安全网。我的习惯是把这个查询存成一个 SQL 文件每天固定跑一次或者接个定时任务早上 8 点自动执行有异常才告警。很多做课设的同学不写对账答辩时被问到「怎么保证系统不出错」只能回答「我测过了没问题」。但如果你能掏出这个对账 SQL把逻辑讲清楚答辩老师的印象会完全不一样——因为它是让你以后不需要吃「出事只能人肉翻数据库查流水」这碗后悔药的东西。希望帮到你。本文还有配套的精品资源点击获取