最近后台收到好多读者留言问学生项目或者课设到底怎么选技术栈SpringBoot 和 SSM 有什么区别前后端分离的项目怎么联调。正巧我自己手上完整跑过一个“基于 SpringBoot Vue 的图书管理系统”从数据库设计到后端接口再到前端页面和打包部署全程都走了不止一遍踩了不少坑也总结了不少经验。今天就把这套系统怎么设计与实现核心代码怎么写关键点在哪里一次性说清楚。这套系统适合几类人正在做毕业设计的学生、刚入门想搞懂 SpringBoot MyBatis 整合的新人、以及想快速搭一套前后端分离项目当练手的开发者。很多教程只给源码不给思路很多源码只讲结果不讲为什么我这篇会把选型理由、表结构设计、接口实现、前端联调、部署避坑全部串起来讲让拿到源码的人不仅会跑还知道每个模块在做什么这样答辩或者面试的时候才讲得出东西。1. 为什么是这套技术栈选型思路与整体设计1.1 技术选型的真实考量先说说为什么选 SpringBoot Vue MySQL MyBatis 这套组合。很多人纠结要不要用 SpringCloud、要不要上 Redis、前端要不要用 TypeScript其实对图书管理这类典型 CRUD 系统来说核心诉求是上手快、结构清晰、资料多、面试好讲。SpringBoot 简化了 Spring 繁琐的 XML 配置内嵌 Tomcat一个 jar 包就能跑Vue 做前端开发效率高组件化让页面代码可维护性大大提升MyBatis 的 SQL 完全由自己掌控比起 JPA 的“自动生成 SQL”更容易排查问题尤其适合面试时被问“你 SQL 是怎么写的”。有的同学可能会问都 2025 年了为什么不用 MyBatis-Plus我的看法是基础项目优先用原生 MyBatis原因有两个第一MyBatis-Plus 的 LambdaQueryWrapper 确实很爽但很多初学者用了之后连 ResultMap 都不认识了底层原理问一下就露馅第二图书管理系统涉及多表联查、条件分页、动态 SQL这些正是 MyBatis 的强项练一遍 XML 写法受益比直接用 MP 大得多。这套系统在设计上采用前后端完全分离的模式Vue 项目独立运行在 8080 端口或自定义端口SpringBoot 后端独立运行在 8081 端口前后端通过 RESTful API 进行数据交互JSON 作为统一数据格式。这种模式下前端的页面渲染和后端的数据逻辑互不干扰也方便以后拆分部署。1.2 功能模块与角色权限划分图书管理系统的功能从用户角度可以分成两类角色管理员和普通读者。管理员负责图书的增删改查、分类管理、借阅审核、归还登记、读者管理读者可以浏览图书、检索图书、发起借阅、查看个人借阅记录。我把模块拆成六个部分登录注册模块、图书管理模块、读者管理模块、借阅管理模块、分类管理模块、统计看板模块。业务上借阅流程是最核心的部分。一个读者最多能借几本书借期多久逾期怎么算这些规则我都把它放到后端统一校验而不是在前端写死。比如我设定的规则是普通读者最多同时借 5 本借期为 30 天逾期每天滞纳金 0.1 元。为什么放后端因为前端校验可以被绕过后端才是数据安全的最后一道关口。角色权限我用的是最简单的拦截器方案定义一个 Role 字段管理员为 1读者为 0。拦截器在请求进入 Controller 之前校验 Token 和角色的匹配关系像添加图书、删除用户这类操作只允许管理员访问。业务简单的时候没必要直接上 Spring Security JWT 全家桶那套东西安全是安全但对新手来讲反而很容易配错并把自己绕晕。1.3 数据库设计表结构与关系数据库设计可以说是整个项目的地基。表关系没设计好后面写 SQL 都是要还债的。我这套系统的表结构一共 5 张核心表用户表 t_user、图书表 t_book、图书分类表 t_category、借阅记录表 t_borrow、以及一张评论表 t_comment阅读扩展用如果你不需要完全可以去掉。用户表字段包括 id、username、password、nickname、role、phone、create_time。注意 password 我存的是 MD5 加密后的值绝不存明文。图书表字段有 id、book_name、author、publisher、isbn、category_id、total_stock、available_stock、description、cover_url。其中 category_id 关联分类表available_stock 是可借库存每次借阅成功会减一归还时加回来。借阅记录表是整个系统的“账本”字段有 id、user_id、book_id、borrow_time、due_time、return_time、status、fine_amount。status 我设计了 0 待审核、1 借出中、2 已归还、3 已逾期这四个状态。为什么要单独维护 due_time 和 fine_amount因为逾期费用的计算需要基于应还日而不是基于当前时间动态算否则用户每次刷新看到不同金额体验极差。还书的时候一次算清楚记录在表中后续统计也方便。CREATE TABLE t_book ( id INT PRIMARY KEY AUTO_INCREMENT, book_name VARCHAR(100) NOT NULL, author VARCHAR(50), publisher VARCHAR(100), isbn VARCHAR(20) UNIQUE, category_id INT, total_stock INT DEFAULT 0, available_stock INT DEFAULT 0, description TEXT, cover_url VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (category_id) REFERENCES t_category(id) );表结构设计时有一个特别值得说的经验available_stock 这种“冗余字段”到底要不要加从严格的数据库范式来讲可借库存可以通过 total_stock 减去处于借出状态的记录数动态计算出来属于冗余。但真实业务中每次查询图书列表都要 count 一次借阅表数据量大了性能非常难看。所以我在图书表里冗余一个可借库存字段借书/还书时通过事务保证它和借阅记录同步更新。这种“用空间换时间”的做法是实际开发中很常见的取舍。2. 后端动手实录SpringBoot MyBatis 核心实现2.1 项目初始化与目录规划后端项目的搭建我用的 Spring Initializr依赖选配了 Spring Web、MyBatis Framework、MySQL Driver、Lombok。SpringBoot 版本用的 2.7.x这里特别提示不要一上来就用 3.x因为 SpringBoot 3 要求 Java 17 起步包名也从 javax 变成了 jakarta很多网上的老教程、博客的代码在 3.x 下直接复制是跑不起来的。等到你把 2.7 这套逻辑吃透了再升级也不迟。项目包结构我习惯按“按功能模块分包”。com.library 下面拆出 controller、service、mapper、entity、common、config 这几个子包。Entity 放数据库实体类Mapper 负责数据访问接口和 XML 映射Service 写业务逻辑Controller 只做参数接收和结果返回。很多新手把业务逻辑直接写在 Controller 里图一时省事后面想加一个校验或者复用一个逻辑的时候就要改很多处所以分层还是得认真做。application.yml 中的配置是绕不开的。数据库连接、MyBatis 映射、端口号都在这里。server: port: 8081 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/library_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: yourpassword mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.library.entity configuration: map-underscore-to-camel-case: true这里有个我刚开始经常踩的坑MySQL 8.0 的驱动类必须是 com.mysql.cj.jdbc.Driver不是旧版的 com.mysql.jdbc.Driver。还有 serverTimezone 如果不设置连接时会直接报 CST 时区错误。map-underscore-to-camel-case 设置成 true 后数据库里 create_time 这种下划线字段就能自动映射成 Java 里的 createTime省去大量手动配置 ResultMap 的功夫。2.2 图书管理接口这样写最清晰图书列表是一个典型的分页查询加多条件筛选接口。前端会传当前页码 pageNum、每页大小 pageSize、可选的书名关键字 bookName、分类 ID categoryId。后端需要返回一个包含总记录数和当前页数据的 PageResult 对象。我先把 Mapper 接口定义出来Mapper public interface BookMapper { ListBook selectBookList(Param(bookName) String bookName, Param(categoryId) Integer categoryId, Param(offset) int offset, Param(limit) int limit); int countBookList(Param(bookName) String bookName, Param(categoryId) Integer categoryId); }对应的 XML 文件里重点展示动态 SQL 的写法。MyBatis 最厉害的地方就在于if标签可以根据条件动态拼接 SQL这样就不需要为了不同查询条件编写不同的 SQL 语句了。select idselectBookList resultTypecom.library.entity.Book SELECT * FROM t_book where if testbookName ! null and bookName ! AND book_name LIKE CONCAT(%, #{bookName}, %) /if if testcategoryId ! null AND category_id #{categoryId} /if /where ORDER BY create_time DESC LIMIT #{offset}, #{limit} /select为什么 count 查询要单独写而不是用 selectBookList 的结果 size 代替因为分页时我们查询的只是当前页的数据例如每页 10 条总共 100 条记录selectBookList 查出来的集合 size 最多只有 10远不是总数。前端分页组件需要知道总记录数才能计算总页数所以必须有 count 查询。如果你想偷懒也可以集成 PageHelper但我建议自己手写一次分页面试被问原理时才心里有底。新增和修改图书的逻辑我会放在 Service 层。新增图书时先校验 ISBN 是否已存在已存在直接抛出业务异常。修改图书时会涉及库存变化的场景比如管理员把 total_stock 从 10 改成 8那 available_stock 不能无脑跟着改需要判断当前已借出数量保证 available_stock 不小于已借数量否则会出现“库存为负”的数据错误。2.3 借阅归还的事务处理与状态机借书这个操作涉及到两张表的变化借阅记录表要新增一条待审核记录图书表的 available_stock 要减一。这两步必须保证同时成功或同时失败怎么保证Spring 的Transactional注解。我一开始也不理解事务到底有什么意义直到有一次测试时故意让第二步 SQL 报错结果发现借阅记录留下了库存却没有减数据直接对不上了这才知道事务的重要性。Transactional(rollbackFor Exception.class) public void borrowBook(Integer userId, Integer bookId) { // 1. 检查用户是否存在 // 2. 检查图书是否存在且可借库存大于0 // 3. 检查读者当前未归还数量是否达到上限 // 4. 插入借阅记录状态为0待审核 // 5. 更新图书 available_stock available_stock - 1 }rollbackFor Exception.class 这个参数不能省。Spring 的事务默认只对 RuntimeException 回滚如果你抛的是普通 Exception它不会回滚数据就处于半更新状态。图书管理系统里我自定义了一个 BizException 继承 RuntimeException业务校验不通过就抛它配合全局异常处理器统一返回错误信息代码非常干净。借阅状态机的核心设计是status 字段在整个生命周期中只能按照 0 → 1 → 2/3 的方向流转。为什么不让用户把 2 改成 0因为状态回退会破坏业务记录的不可变性。例如一本书已经归还了这时把状态改回借出中库存对账就会出现问题。所以归还操作的后端逻辑是先校验当前状态必须是 1 或 3然后更新状态为 2同时把 available_stock 加一并把实际归还时间写入 return_time。逾期金额在归还时根据 due_time 和 return_time 计算得数入库。2.4 登录鉴权的轻量实现登录模块我用的方案是 JWT 拦截器。用户登录成功后后端生成一个包含用户 ID、用户名、角色的 Token 字符串返回给前端。前端把这个 Token 存在 localStorage 里每次请求时在请求头加Authorization: token值。后端拦截器对除了登录注册外的所有接口做 Token 校验。public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !JwtUtil.verifyToken(token)) { response.setStatus(401); return false; } return true; } }JWT 有个特点是服务端不保存登录状态Token 里本身就包含用户信息解析后就能拿到 userId 和 role。对于图书管理系统这种体量完全够用。如果你要做强制下线或者踢人功能JWT 就比较尴尬那就得引入 Redis 做会话管理了这个可以后续再扩展。除了登录还有一个容易被忽略的点也是我实际开发中花费很多时间的地方统一返回格式。我定义了一个 Result 类包含 code、message、data 三个字段。所有 Controller 的返回值都包一层 Result前端用响应拦截器统一判断 code 是否为 200非 200 直接弹错误提示。这样做的好处是前后端约定非常清晰不会出现前端拿到一个 list 后又得判断是不是 null 的混乱情况。3. 前端实现与联调Vue Axios 完整落地3.1 前端工程创建与基础配置前端我用的是 Vue 2 的 Vue CLI 来创建的项目。为什么不推荐 Vue 3倒不是说 Vue 3 不好而是图书管理系统当前用到的 Element UI 组件库在 Vue 2 下的资料最丰富遇到问题搜索最快。如果你已经熟练了用 Vue 3 Element Plus 也完全没问题原理是一样的。创建命令就两行vue create library-web npm install axios element-ui vue-router vuex环境配置上有一个值得注意的点Node 版本不能太高也不能太低。之前我在一台装了 Node 20 的机器上跑 Vue 2 项目编译直接报 OpenSSL 错误后来把 Node 降到 16 才正常。如果你遇到error:0308010C:digital envelope routines::unsupported可以考虑切换 Node 版本或者在 package.json 的 scripts 里加上set NODE_OPTIONS--openssl-legacy-provider。项目的核心目录结构是 src 下面分 views、router、api、utils、components。Api 目录统一放 axios 请求方法这是前后端分离项目的一个最佳实践。项目里所有接口都集中管理后端改路径只需要改一个文件不用去每个页面翻代码。3.2 页面与路由设计页面规划是登录页、系统布局页包含侧边栏和顶栏、图书列表页、图书新增/编辑页、借阅记录页、读者管理页、个人中心页。路由配置用 Vue Router在路由元信息 meta 里加 requireAuth 和 role 字段。前置守卫里判断如果没有 Token 就跳转登录页如果有 Token 但路由的 role 不匹配就提示无权限。router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.meta.requireAuth !token) { next(/login); } else if (to.meta.role to.meta.role ! store.state.user.role) { next(/403); } else { next(); } });图书列表页看起来简单实际做起来有很多细节。表格展示带上封面图搜索栏是书名输入框加分类下拉框加搜索按钮。分页组件绑定 currentPage 和 pageSize每次切换页码重新请求接口。还有一个重要的小功能借阅按钮要根据 available_stock 判断是否可点库存为 0 时按钮置灰并显示“不可借”。这些交互点虽然小但直接影响用户体验。编辑图书时我用一个对话框而不是独立页面这样列表和编辑在同一个页面内交互省去路由跳转的割裂感。表单验证用 Element UI 自带的 rules 规则比如 ISBN 必填、库存必须是正整数。这里再强调一下前端校验只是提升体验真正必须校验的是后端。不要以为前端拦住了就万事大吉别人用 Postman 照样可以绕过前端直接调你的接口。3.3 与后端联调时的跨域与拦截器前后端分离必须面对跨域问题。浏览器出于安全策略默认禁止从一个域名的页面去请求另一个域名的接口。开发环境最简单的解法是配置一个 Vue CLI 的 devServer 代理所有以/api开头的请求转发到http://localhost:8081。// vue.config.js module.exports { devServer: { port: 8080, proxy: { /api: { target: http://localhost:8081, changeOrigin: true } } } };这样做的好处不仅仅是解决跨域接口地址也不用写死上线时只要用 Nginx 配一个反向代理就好。我在开发时习惯所有后端接口路径都以 /api 开头例如/api/book/list、/api/user/login这样代理配置只需要写一次。Axios 的封装也很重要。我项目里在 utils/request.js 中创建 axios 实例设置 baseURL 为/api然后添加请求拦截器和响应拦截器。请求拦截器里从 localStorage 取 Token 放到请求头响应拦截器里判断 HTTP 状态码401 时清除本地信息跳转登录页业务错误码直接弹 Message 提示。封装完以后页面里的请求代码就可以精简成一行getBookList(params).then(res { this.tableData res.data.records; this.total res.data.total; });联调阶段最常见的报错就是 404 或者 500。404 大概率是后端接口路径和前端 api 方法里的路径拼错了尤其是大小写问题我踩过一次 BookName 和 bookName 不一致排查了快一小时500 一般是后端空指针或者 SQL 异常解决办法是看后端控制台的完整堆栈而不是只看前端返回的 error 信息。很多新人联调一报错就盯着前端看方向就反了。4. 环境搭建与部署实录4.1 MySQL 8.0 安装与建库先把数据库搞定。这里以 MySQL 8.0 为例我在 Windows 和 Linux 上都部署过。Windows 上安装时最容易忽略的就是选择好字符集我建议安装时直接选 utf8mb4它可以完整支持中文和一些特殊字符。装好后打开命令行窗口执行mysql -u root -p登录然后建库CREATE DATABASE library_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE library_db; -- 然后执行建表 SQL初始化数据也别空着手写我通常在根目录放一个 init.sql 文件包含全部建表语句和基础的测试数据比如几个分类、几本示例图书、一个管理员账号。拿到项目的人第一步就是执行这个 SQL能少很多麻烦。这里有个小细节我建库时没有任何敏感数据也没有涉及任何政策法律相关内容只是纯粹的测试数据可以放心使用。4.2 SpringBoot 配置要点后端配置前面已经展示过一部分 application.yml这里还想再提两个点。一个是多环境配置我拆了 application-dev.yml 和 application-prod.ymldev 环境数据库是本机的prod 环境是服务器的启动时用--spring.profiles.activeprod来指定。第二个是日志配置MyBatis 打印 SQL 的开关在测试阶段一定要打开这样你能看到每条查询实际执行的 SQL 语句。logging: level: com.library.mapper: debug把这个配置加到 yml 中MyBatis 的执行日志就会打印到控制台。排查 SQL 问题、确认参数传递是否正确这个开关负责任地说能帮你省一半的时间。上线时再把日志级别调回 info避免性能损耗和日志刷屏。打包部署也很简单。后端在项目根目录执行mvn clean package -DskipTests就会生成一个 library-backend-0.0.1-SNAPSHOT.jar 文件。然后在服务器上执行nohup java -jar library-backend-0.0.1-SNAPSHOT.jar app.log 21 后端就跑起来了。前端执行npm run build生成 dist 目录用 Nginx 指向这个目录并配置好反向代理整个系统就上线了。4.3 一个可复用的部署检查清单部署容易漏配置下面这个清单是我每次部署都会过一遍的每次都能检查出问题。数据库连接信息是否正确账号密码是否匹配前端构建时接口前缀是否指向线上地址或者 Nginx 代理是否生效后端启动端口是否被占用如果被占用用netstat -tunlp | grep 8081查看防火墙是否放行了相应端口Nginx 配置中前端路由是否使用了 history 模式如果用了 history 模式需要配置 try_files 防止刷新页面变成 404。Nginx 单页应用配置的核心就一句是所有做过前端部署的人都应该知道的location / { root /data/www/library; index index.html; try_files $uri $uri/ /index.html; }不加 try_files 这行Vue Router 用 history 模式时用户一旦手动刷新/book/edit/3这个页面Nginx 就会去服务器找这个路径对应的文件找不到就返回 404。加了 try_files 后所有路径都回退到 index.html 交给前端路由处理。这个坑我当年部署时踩过一次刷新页面直接白屏的体验真的很让人崩溃。5. 常见问题与跟踪排查实录5.1 项目开发中我踩过的坑第一个坑是关于数据库字段下划线与 Java 驼峰命名的映射。表里写的 create_time实体类写的 createTime如果 yml 里没有开启 map-underscore-to-camel-caseMyBatis 查询出来的 createTime 永远是 null。一开始我还以为是数据库没数据加了半天测试数据才发现是映射配置问题。解决办法就是我在前面提到的 yml 配置项。第二个坑是事务不生效。我在一个 Service 里写了个方法进行借书操作但故意让第二步 SQL 报错一查数据发现借阅记录已经插进去了库存却没减。查了资料才发现是调用了同类内部的另一个方法导致事务失效。Spring 事务基于 AOP 代理同类内 this 调用不会经过代理对象解决办法有两种把内部方法移到另一个 Service或者用 AopContext 获取代理类。我最后选择了拆成两个 Service结构更清晰也更好理解。这个点面试时被问到的概率非常高能讲出场景演示出来印象分蹭蹭涨。第三个坑是跨域配置。有时候开发环境用代理已经解决了但在某些笔记本上代理不生效接口请求一直报错。后来我发现是 devServer 配置写错了把 target 的 localhost 写成了项目名称或错误 IP。启动前端后打开浏览器 F12network 面板看实际请求的 URL就知道哪里转发错了比盲目改代码高效得多。第四个坑是前端组件的数据绑定问题。Element UI 的表格数据经常需要:datatableData绑定但 tableData 在异步请求返回后要重新赋值才能触发视图更新。我在操作借阅成功后调用了this.getBookList()重新拉取列表而不是手动修改表格里某一行的数据这样可以保证视图和数据的一致性也让代码逻辑更简单。记住一个原则列表数据任何时候都从接口拉不要试图在前端做源数据的修改。5.2 面试常被问到的高频问题做完这个项目后不管是应聘 Java 开发实习生还是本科毕业找工作这个项目大概率是你简历上最拿得出手的东西。面试官也比较喜欢基于这个项目往深处问。我整理了几道常考的问题以及从项目出发的回答思路这次分享在这里第一个问题SpringBoot 的自动配置原理是什么。回答这个问题要结合项目你可以说我在图书管理系统里引入了 mybatis-spring-boot-starter 依赖后没有手动配置 SqlSessionFactory因为它利用 SpringFactoriesLoader 机制加载了 MybatisAutoConfiguration 配置类再通过 ConditionalOnClass 和 ConditionalOnMissingBean 这些条件注解自动创建好了需要的 Bean。只有讲出项目里用到的细节面试官才会认定你是真的写得多而不是背面试题。第二个问题MyBatis 中 #{} 和 ${} 的区别。这是一个送分题但很多人都答不全。#{} 是预编译会生成一个问号占位符由 PreparedStatement 来赋值能有效防止 SQL 注入${} 是直接拼接字符串通常用在表名、排序字段这种不能预编译的场景。在图书列表的动态查询里我用的是 #{}WHERE book_name LIKE CONCAT(%, #{bookName}, %)。注意 LIKE 查询不能直接写成LIKE %#{bookName}%那个不是语法错误但结果绝不会是你预期的因为参数根本没有被拼接到 LIKE 的 % 中间去。这也是一个隐藏很深的坑。第三个问题index 和事务。比如一次借书操作我为什么用事务怎么保证多张表的数据一致性你可以回答利用 Transactional脏回滚就是有 RuntimeException 的时候全部回滚保证借阅记录表和图书表的操作要么都成功要么都失败。这样的回答既有原理又有实践比单纯背概念要扎实。第四个问题JWT 整体流程及优缺点。要结合项目讲清楚客户端携带 Token 访问受保护接口的完整流程再讲每个 Token 过期处理方案比如续期、刷新以及怎么用拦截器只放行登录接口。如果面试官问 JWT 的缺点你可以说服务端不能主动吊销 Token。这个优缺点讨论和项目实际做法结合起来就是很出色的作答。5.3 项目还能怎么扩展如果做完基础版本还想加亮点我推荐三个方向。第一个是引入 Redis 做热门图书缓存每次查询列表时先查缓存缓存没有再去查数据库这就能引出缓存穿透、缓存击穿、缓存雪崩的一串问题把项目的技术含量直接拉高一个档次。第二个是增加上传功能让管理员能上传图书封面图片涉及本地存储路径配置、静态资源映射。第三个是加入定时任务每天凌晨扫描 overdue 状态的借阅记录自动计算逾期费用并短信通知读者这个可以通过 Spring 自带的 Scheduled 定时注解实现加上之后项目就有了“主动服务”的亮点。我个人的体会是图书管理系统虽然表面上是个 CRUD 项目但把它的每一个模块都做深、把每一步的原理都搞清楚你收获的绝对不只是“会跑一个项目”这么简单。从表设计到事务处理从 JWT 鉴权到前后端跨域再到打包部署这一条线完整走下来你对 Java 后端开发的全链路认知会清晰非常多。最后再分享一个小技巧项目写好以后一定记得写一份 README把技术栈、模块图、数据库脚本位置、启动步骤写清楚。这不只是给别人看更是给三个月后的自己看。我见过很多人项目写完就扔等到答辩或者面试要讲的时候看着自己的代码一脸茫然。保持好复盘习惯才能让这套源码真正变成你自己的东西。