简介：面向Java开发与毕业设计场景，这是一份基于SSM（Spring+SpringMVC+MyBatis）框架实现的银行系统完整项目。它适合计算机相关专业学生或初级开发者，用来理解企业级Web应用的前后台协作、账户流水与业务处理流程，也可直接作为毕业设计或课程设计的运行参考。压缩包共1210个文件，以Java源码、JSP/HTML页面、CSS与JavaScript脚本、XML配置、Jar依赖库等为主体，整体约46.61MB；源码目录按模块组织，便于阅读和二次开发。目前已有673人学习或下载。通过该资源可得到一套含登录、用户管理、银行卡、理财产品等模块的前后台代码，并附有使用IDEA打开项目、添加Apache服务、配置MySQL的导入说明，能帮助读者快速跑通项目，理解SSM整合流程并继续扩展功能。
1. 一个SSM银行系统zip，为什么值得你花两周去复现
拿到一个“java开发毕业设计基于SSM的银行系统.zip”，第一反应通常是：这又是一个能跑就行的课设产物。但你解压之后会发现，这个zip里其实藏着一个完整的三层架构项目——Spring管理业务对象、SpringMVC处理请求分发、MyBatis操作数据库，外加用户、账户、转账、流水、管理员审核这些标准银行业务模块。它适合两类人：一类是需要交毕业设计、想快速把项目跑起来并讲清楚每个注解含义的学生；另一类是java学习路线刚走到SSM阶段、想找个真实业务场景练手的开发新人。这里有一个和直觉相反的结论：真正能把这个zip跑起来的人不少，但能在答辩时把事务、并发、金额精度这几个点讲明白的人很少——后者才是这个项目真正的价值所在。
2. SSM在银行系统里的分工：选型理由与三层架构落地
2.1 控制层用SpringMVC：为什么银行功能最适合做请求-响应模型
打开这个项目的源码包，第一眼看到的不是业务代码，而是web.xml里配置的DispatcherServlet。SSM项目的控制层几乎无一例外用SpringMVC，这不是巧合，而是银行系统的功能特性决定的：开户、登录、转账、查询流水，每一步都是用户发起一个HTTP请求、系统返回一个页面或JSON的过程，天然适配SpringMVC的请求-响应模型。
我在实际跑通这类项目时，会先看三件事：web.xml中DispatcherServlet的url-pattern是*.do还是/；spring-mvc.xml里有没有开启注解驱动；Controller里方法的返回值是ModelAndView还是@ResponseBody。这三件事决定了你访问bank/login.do时是走视图解析器拼JSP路径，还是直接返回JSON给前端。毕业设计里的银行系统通常两者都有——页面跳转用ModelAndView，Ajax查询转账结果时用@ResponseBody，这在同一个Controller里共存是没问题的。
<!-- web.xml 中 DispatcherServlet 的经典配置 --> <servlet> <servlet-name>springmvc</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>springmvc</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping>这里把url-pattern写成*.do是这类SSM项目的常见做法，目的很直接：让所有以.do结尾的请求都进入SpringMVC，而CSS、JS、图片等静态资源完全不受影响。代价是Controller里的每个方法都要带.do后缀，比如login.do、transfer.do。如果把这个pattern改成/，静态资源就会全部被DispatcherServlet拦截，需要在spring-mvc.xml里额外配置<mvc:default-servlet-handler/>——这是我在后面避坑章节里会重点展开的一个高频404来源。
spring-mvc.xml里还有一个容易被忽略但很重要的配置项：注解驱动。它决定@Controller、@RequestMapping这些注解是否生效。
<!-- spring-mvc.xml 中必须开启的注解驱动 --> <mvc:annotation-driven /> <context:component-scan base-package="com.bank.controller" /> <mvc:default-servlet-handler /><mvc:annotation-driven />会注册RequestMappingHandlerMapping和RequestMappingHandlerAdapter，把@RequestMapping注解和方法参数绑定全部接管过来。这里的base-package扫描范围要和Controller所在包严格对上，多扫一个包不会报错，但少扫了就会出现访问路径返回404且控制台没有任何报错——这类问题排查起来非常让人头疼，因为它不抛异常，看起来像是什么都没发生。
2.2 持久层用MyBatis：动态SQL和银行查询场景的配合
银行系统的持久层几乎必须用MyBatis而不是JPA/Hibernate，原因很现实：银行查询条件太多变。余额查询、按卡号查、按身份证查、按时间段查流水、按状态查审核记录，这些查询的字段组合频繁变化，MyBatis的动态SQL配置可以让一个Mapper方法对应多种查询组合，而不需要为每种组合写一个JPQL方法。
在这个项目里，MyBatis和Spring是通过SqlSessionFactoryBean接起来的。配置的关键在mybatis-config.xml和applicationContext.xml两处，前者管MyBatis自身行为，后者管数据源和Mapper扫描。
<!-- applicationContext.xml 中 MyBatis 与 Spring 的整合核心 --> <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close"> <property name="driverClassName" value="${jdbc.driver}" /> <property name="url" value="${jdbc.url}" /> <property name="username" value="${jdbc.username}" /> <property name="password" value="${jdbc.password}" /> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource" /> <property name="mapperLocations" value="classpath:com/bank/mapper/*.xml" /> <property name="typeAliasesPackage" value="com.bank.pojo" /> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.bank.mapper" /> <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory" /> </bean>这里用了Druid作为数据源，这种选择在SSM银行系统这种项目里很常见。Druid的主要优势是自带监控页面和SQL统计，答辩时可以打开druid/index.html给老师展示SQL执行次数和慢查询日志，这是一个低成本但效果很好的加分项。
mapperLocations指向了com/bank/mapper/*.xml，这是Mapper接口和XML文件分离的标准做法。我一般会提醒跑这类项目的人注意一个细节：Mapper接口的全限定名必须和XML文件里的namespace完全一致，方法名必须和XML里的id一致，否则启动时不会报错，但第一次调用该方法时会抛绑定异常——这是MyBatis最容易踩的静默错误之一。
2.3 毕业设计里事务为什么必须放在Service层而不是Controller层
很多初学SSM的人在写转账功能时，会顺手在Controller里写事务注解，这是一个经典误用。Spring的事务管理是通过AOP代理实现的，@Transactional注解标注在Controller上时，Controller对象通常是单例但不受Spring事务代理管理（取决于配置），而且事务拦截器在进入Controller之前就已经对请求完成拦截，标注在Controller上往往不生效或者作用范围不符合预期。
正确做法是让Service层接口和实现类分离，把@Transactional标注在Service实现类的方法上，让Spring通过JDK动态代理为接口生成代理对象，事务边界刚好覆盖到一个完整的业务操作。在银行的转账场景里，这个边界意味着：扣减转出账户余额、增加转入账户余额、写入交易流水，三步要么全部成功，要么全部回滚。如果事务只覆盖到其中一步，就会出现扣了钱但流水没记上、对不上账的严重问题。
@Service public class TransferServiceImpl implements TransferService { @Autowired private AccountMapper accountMapper; @Autowired private TransactionMapper transactionMapper; @Override @Transactional(rollbackFor = Exception.class) public void transfer(TransferDTO dto) { // 扣减转出账户余额 int rows = accountMapper.decreaseBalance(dto.getFromAccount(), dto.getAmount()); if (rows == 0) { throw new BusinessException("账户不存在或余额不足"); } // 增加转入账户余额 accountMapper.increaseBalance(dto.getToAccount(), dto.getAmount()); // 写入交易流水 transactionMapper.insertRecord(dto); } }这里有个细节值得展开：@Transactional默认只对RuntimeException及其子类回滚，对受检异常（checked exception）不会回滚。所以转账时如果自定义了BusinessException继承RuntimeException，上面这段代码任何一步抛异常都会触发完整回滚。如果这里写成throws Exception让转账异常以受检异常形式往外抛，那事务就不会回滚，余额照扣、流水没记，这是银行系统里绝对不能接受的。rollbackFor = Exception.class这个参数是这类项目里我最强调的一行配置，没有之一。
3. 把zip变成能跑的系统：从解压、建库到首页出现的四个验证点
3.1 环境锁定：JDK、Tomcat和MySQL版本的匹配清单
拿到zip后不要着急用IDEA打开。我的习惯是先建一个干净的目录，把zip解压进去，然后按序检查三个东西：项目里pom.xml里指定的依赖版本、Maven编译器插件指定的Java版本、以及web.xml中Servlet的版本声明。这三者对应到运行环境就是JDK版本、Tomcat版本、MySQL版本。
这类SSM银行系统最常见的版本组合是JDK 1.8、Tomcat 8或9、MySQL 5.7。高版本的Tomcat 10换成了Jakarta命名空间，直接跑老SSM项目会报ClassNotFoundException: javax.servlet.Filter这类错。Maven里如果用了旧版的mysql-connector-java，连接MySQL 8.x还会出现时钟同步和认证插件不识别的问题。我的做法是提前锁定一套测试过的组合，而不是让Maven自己拉最新版。
<!-- pom.xml 中三组必须锁死的版本号 --> <properties> <java.version>1.8</java.version> <spring.version>5.2.22.RELEASE</spring.version> <mybatis.version>3.5.6</mybatis.version> </properties> <dependencies> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.49</version> </dependency> </dependencies>Spring 5.2.x搭配JDK 1.8可以正常使用javax命名空间的注解；MyBatis 3.5.x对动态SQL的解析更完善，同时保持了和Spring整合的兼容性。这里真正容易出问题的反而是mysql-connector-java——网上教程用5.1.x的多，但如果你本机装的是MySQL 8，这个驱动也能连，前提是连接URL里要显式写上serverTimezone，否则会直接抛一个难以理解的时区异常。
3.2 导入数据库脚本和初始化数据时的三个动作
解压后的sql目录里一般有一个bank.sql或init.sql。导入之前，不是直接source执行，而是先做三件事：用文本编辑器打开看了一遍表结构；确认建表语句里的存储引擎；确认是否有初始化数据。很多SSM银行系统的SQL脚本会出现这样的问题：create table语句没写ENGINE=InnoDB，在MySQL 5.5之前的版本会默认用MyISAM，而MyISAM不支持事务——上一章的转账事务在这个存储引擎下完全失效。
-- 转账表（或交易流水表）必须使用支持事务的存储引擎 CREATE TABLE `t_transaction` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '流水ID', `serial_no` VARCHAR(64) NOT NULL COMMENT '交易流水号', `from_account` VARCHAR(32) NOT NULL COMMENT '转出账号', `to_account` VARCHAR(32) NOT NULL COMMENT '转入账号', `amount` DECIMAL(12, 2) NOT NULL COMMENT '交易金额', `status` TINYINT DEFAULT 0 COMMENT '0处理中 1成功 2失败', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '交易时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_serial_no` (`serial_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='交易流水表';用DECIMAL而不是DOUBLE存金额，这是银行系统里写在表结构里的底线。DOUBLE和FLOAT都是浮点数，0.1+0.2这种基础运算都会出现精度偏差，在金额字段上绝对不能用；DECIMAL(12,2)的12是总位数、2是小数位数，10位整数加2位小数足够普通银行系统账户余额使用。sql脚本导入后，我会运行一句SHOW CREATE TABLE确认ENGINE和CHARSET已经正确，这一步成本很低但能避免后面所有与事务和中文乱码相关的坑。
3.3 修改配置文件、启动Tomcat，用四个验证点确认系统真的跑通了
环境就绪后，把项目导入IDEA，等Maven依赖下载完成。这一环节的关键是修改src/main/resources/jdbc.properties里的数据库连接参数，然后启动Tomcat。启动成功后不要急着点页面上的按钮，而是按四个验证点依次确认：登录页能打开、默认管理员能登录、能创建一个测试账户、能用测试账户发起一笔转账。这四个验证点分别对应静态资源、认证逻辑、权限控制和事务机制，任何一个失败都能帮你定位到具体层面的问题。
# jdbc.properties 中需要手动修改的四个参数 jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/bank?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=你的数据库密码useUnicode=true和characterEncoding=utf-8这两个参数在连接MySQL时必须同时出现，否则插入中文用户名时会出现乱码或者报SQLException不支持的字符集。serverTimezone=Asia/Shanghai这一步只对MySQL 8的驱动是必须的，但注意字符集配置在数据库连接层只是第一层，Tomcat的URI编码是第二层，页面响应头是第三层，后面避坑章节里我会专门展开。数据库密码如果你设了特殊字符，比如&或?，在properties里要记得转义。
启动Tomcat后，如果控制台没有报错但访问login.do出现404，第一反先看IDEA下边部署的那个Artifact是不是war exploded，构建输出路径是不是真的放到了Tomcat的webapps下面。这是IDEA跑SSM项目最常见的启动假成功——Tomcat起来了，但你的Web模块压根没部署上去。
4. SSM银行系统避坑：从乱码、404到事务回滚的排查清单
4.1 中文乱码出现在交易备注里，但登录页却完全正常
现象：登录页上的欢迎语是正常中文，但开户成功后查询账户列表，用户的姓名变成了问号。更诡异的是，新插入的数据乱码，而SQL脚本里已有的旧数据正常。
原因：这里有三层编码需要对齐——MySQL连接层的characterEncoding、Tomcat接收请求时的URIEncoding、以及JSP页面本身的pageEncoding。登录页正常是因为它的中文来自页面模板本身，走的是JSP文件读取通道；乱码来自表单提交到数据库插入这一整条链路，任何一个环节编码不对都会出问题。常见的检查顺序是：先看数据库字符集是utf8还是utf8mb4，再用SHOW CREATE TABLE确认表的CHARSET，然后确认JSP的pageEncoding，三层只要有一层是latin1或gbk，中文就会在边界处变形。
解决：统一改成UTF-8，关键步骤是Tomcat连接器上设置URIEncoding。在conf/server.xml里找到Connector节点，加上URIEncoding="UTF-8"；同时确认jdbc.url里的characterEncoding=utf-8；最后把JSP页面头部的pageEncoding改成UTF-8。三个地方全部对齐后重新启动，再插入中文数据测试。经验上这三处改完，90%的SSM中文乱码问题都能解决，剩下的情况是MySQL服务端初始化时没设置默认字符集，需要在my.ini里配置character-set-server=utf8mb4后重启数据库服务。
// 如果使用了过滤器，字符集过滤器应放在过滤器链的最前端 public class CharacterEncodingFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { request.setCharacterEncoding("UTF-8"); response.setContentType("text/html; charset=UTF-8"); chain.doFilter(request, response); } }这个自定义Filter在几乎所有SSM项目里都有，要注意它的url-pattern必须写成/*而不是*.do，否则只有以.do结尾的请求会被过滤，而JSP页面本身的请求是*.jsp，中文数据就在这漏掉了。
4.2 转账事务回滚没生效：扣了钱但流水没记上
现象：转账接口测试时，在写入流水之前故意抛一个RuntimeException来验证回滚，发现转出账户的余额已经被扣了，但流水表里没有记录。事务像是不存在一样。
原因：第一优先排查存储引擎。如果流水表是MyISAM，它根本不支持事务，@Transactional注解等于摆设。第二排查连接池的监控页——如果你配置了Druid，打开监控页看到这个连接的autocommit是true，说明在建立连接时自动提交被开启了，事务管理器根本没接管连接。第三是排查@Transactional是否标注在了实现类的public方法上，并且该类被Spring的component-scan扫描到了。这个场景里标注在private方法上是非常隐蔽的坑，Spring通过CGLIB代理时不会对private方法做事务增强，方法照样执行、事务完全不生效，而且没有任何报错。
解决：按顺序执行三件事。第一，确认表结构里所有涉及资金变化的表都是ENGINE=InnoDB；第二，查看Spring配置文件里事务管理器的dataSource是否和Dao层用的是同一个数据源实例，出现事务不生效时有一半是这里配了两个不同的dataSource连接了同一套库；第三，在Service实现类的转账方法上补上rollbackFor = Exception.class参数，并重启后再次验证。
<!-- 事务管理器与数据源必须绑定同一个实例 --> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource" /> </bean> <tx:annotation-driven transaction-manager="transactionManager" />4.3 表单提交404：DispatcherServlet把静态资源路径全部吃掉了
现象：项目正常启动，登录页样式全丢了、图片打不开，点提交按钮后URL变成login.do但页面显示404。控制台没有任何Error输出。
原因：DispatcherServlet的url-pattern配置成了/，而spring-mvc.xml里又没有配置<mvc:default-servlet-handler/>。当url-pattern为/时，所有的请求包括JS、CSS、图片都会被DispatcherServlet接管，SpringMVC找不到对应的Handler，只能返回404。这个错误的特点是：页面能显示，但纯文字没有样式，看起来像网站被拆了一半。
解决：如果你用的Spring版本是5.x，在spring-mvc.xml里加上<mvc:default-servlet-handler/>，它会把请求重新交回给Tomcat的DefaultServlet处理静态资源。注意这个配置会和<mvc:annotation-driven />同时存在，一次配齐不要遗漏。我还见过一种更简单的修复方式：把url-pattern从/改回*.do，所有Controller方法保持.do后缀，这样静态资源完全不走SpringMVC，是这类老SSM系统里最稳的写法，前提是项目里的表单action和超链接地址都踩着.do的规则。
4.4 余额查询越来越慢：like查询和索引失效的两个真实场景
现象：银行流水页面按备注查询时，数据刚导入时响应挺快，测试数据到了几万条以后，这个查询开始卡顿，页面等待时间明显变长。
原因：这里有两个索引问题的叠加。第一个是流水表的备注字段上如果加了普通索引，但SQL写成了WHERE remark LIKE '%刷卡%'，前导通配符会导致该字段上的索引完全失效，MySQL只能走全表扫描；第二个是金额过滤如果写成WHERE amount + 0 > 100，字段参与了函数运算，索引同样会失效。这类问题在银行系统里很常见，因为刚导入数据量小，全表扫描也要不了几十毫秒，但随着演示数据增长，慢查询的体感差别会越来越明显。
解决：把模糊查询需求拆成两个方向处理。能在创建账户时规范备注输入的，就把备注前缀做成固定枚举值，LIKE 'POS_%'这类前导通配符不会导致索引失效；确认必须做包含匹配的，就接受全表扫描并控制数据量。把金额条件的SQL改写成amount > 100，去掉函数运算。这些修正配合Druid监控页的SQL统计项，在答辩时可以作为“性能优化”素材直接展示。
-- 修正前：全文扫描 SELECT * FROM t_transaction WHERE remark LIKE '%刷卡%' AND amount + 0 > 100; -- 修正后：索引友好写法 SELECT * FROM t_transaction WHERE remark LIKE 'POS_%' AND amount > 100;4.5 密码明文存储和你在答辩时如何应对
现象：数据库user表里直接存着明文密码，后台管理员能看到所有用户的密码。这几乎是网上SSM银行系统项目的通病，但同时也是答辩时最容易暴露的一个技术短板。
原因：原始项目为了演示方便，把注册功能简化成了明文入库。这个问题不是框架层面的疏漏，而是业务设计层面的欠缺，属于毕业设计项目里典型的“能跑但不像产品”的问题。
解决：在UserService的注册方法里引入MD5加盐。不要用单独的MD5（现在MD5已经能被轻松碰撞），而是先为每个用户生成一段随机盐值，再用salt+password拼起来计算摘要，数据库里保存salt和digest两列。登录验证时取出盐值重新计算再比较，这样即使数据库泄露，密码原文也相对不容易被反推。这个改动成本很低，但能在答辩中体现你对安全这块的考虑。
// 注册时的密码摘要计算 String salt = UUID.randomUUID().toString().substring(0, 8); String digest = DigestUtils.md5Hex(salt + rawPassword); user.setSalt(salt); user.setPasswordDigest(digest);// 登录时的验证逻辑 User storedUser = userMapper.selectByUsername(username); String testDigest = DigestUtils.md5Hex(storedUser.getSalt() + rawPassword); if (!storedUser.getPasswordDigest().equals(testDigest)) { throw new LoginException("用户名或密码错误"); }这里的DigestUtils用的是Spring自带的org.springframework.util.DigestUtils——我一般不建议在毕业设计里再引一个完整的加密库，但这句话只在项目本身没有引入Spring Security时才成立。这个改动的答辩价值非常高：老师问“你觉得这个系统有什么不足”时，正好接住这个问题，进一步讲如何改为BCrypt，再延展到登录接口的防暴力破解，直接就把回答层次拉高了。
5. 把转账模块改成幂等：一个能写进简历的毕业设计改进
5.1 用乐观锁解决重复提交转账请求
原zip里的转账方法通常长这样：先查询余额，判断充足后扣款、加款、写流水。它最大的问题是两个用户同时从同一个账户转账时，两边都读到同一份余额，两个请求都判定“余额充足”，账上最后可能会变成负数。这个场景在银行系统里是必须解决的。
我给出的改进方向：在账户表加一个version字段，每次更新余额时把version一起带上并在SQL里做条件判断。这用到的策略叫乐观锁，比使用SELECT FOR UPDATE悲观锁更适合演示页面操作，因为悲观锁会长时间锁住账户行，转账期间该账户的所有其他操作都会被阻塞。
-- 账户表新增版本号字段 ALTER TABLE t_account ADD COLUMN version INT NOT NULL DEFAULT 0;-- 扣减余额，带上版本号作为更新条件 UPDATE t_account SET balance = balance - #{amount}, version = version + 1 WHERE account_no = #{accountNo} AND version = #{version};上面这条UPDATE返回的rows等于0时，说明这一时刻账户的version已经被其他请求改过，当前请求拿到的version已经过期，此时事务应该抛出异常并整体回滚。转账方法接收到这个返回结果后，引导用户重新查询最新余额并再次提交。这个改动的意义在于：它把“重复提交导致余额变成负数”这个银行级问题，从一个答辩扣分点变成了一个加分点。
5.2 答辩被追问时这三句话让你把框架讲清楚
这套SSM项目到答辩环节，老师通常会从“为什么用SSM”问起。我的习惯是不背概念，而是用“我做了什么”开头：控制层用SpringMVC处理后端请求，Service层用Spring管理事务和依赖注入，持久层用MyBatis的Mapper接口和XML的组合应对动态查询条件。然后补一句SSM本身的特点：Spring是容器和事务管理器、SpringMVC负责请求路由、MyBatis是数据访问层的SQL映射器，三个框架各自专注一块，整合时通过Spring的contextConfigLocation统一装配。
如果被问到“和Spring Boot相比”，诚实的回答是：Boot把配置约定化，让同一个系统可以用更少的XML跑起来，但SSM能让我理解每个组件是怎么被装进容器的。这句话老师和面试官都吃这一套——它说明你不是只会拖依赖的人。回答完概念，顺手把避坑章节里说过的InnoDB事务边界、BigDecimal金额精度、字符集三层对齐这三个点带出来，整场答辩的核心内容就稳了。
最后一个建议：把银行系统的表结构整理成一张简短的ER图放进论文里，登录、开户、转账、审核四条主流程分别对应到Controller、Service、Mapper三层各一个方法，让老师顺着调用链一眼看懂你的设计。这一步不是写代码，但能把你做的所有工作和这个zip的价值直接锚定在一个可复现的交付物上。希望这些踩过坑的经验能帮你的毕业设计少走一段弯路。
本文还有配套的精品资源，点击获取
