尧图网站建设 
图书管理系统大概是Java开发圈子里最常见的实战项目了——校园毕设、培训机构作业、新人练手到处都能看到它的身影。但很多项目还停留在JSPServlet或者SpringBootThymeleaf的旧模式前后端耦合在一起改个页面都要重启服务。今天要聊的这套源码用SpringBoot Vue3 MyBatis MySQL的组合后端只出接口前端单独维护整个架构从一开始就是按真实项目的标准来组织的。如果你正打算做一个前后端分离的Java项目或者想用一套完整源码来研究Vue3配合SpringBoot到底怎么配合这篇文章可以帮你省下不少摸索的时间。我会从项目功能拆解、技术选型理由到后端分层实现、前端封装联调再到部署时踩过的坑尽量把每个环节为什么这样做讲清楚。内容偏实操跟着走一遍你不仅能跑起这个图书管理系统还能顺手把它改造成自己想要的形态。1. 项目定位与功能拆解1.1 图书管理系统到底要解决什么问题做图书管理系统之前先别急着打开IDE写代码。我习惯先想一个问题图书管理员每天最烦什么图书找不到、借出不知道借给谁、归还日期记不清、盘点数目对不上。系统要解决的其实就是这类琐碎问题——把纸面记录变成数据结构把人工核对变成SQL查询。所以这个项目围绕三条主线展开图书档案管理、借阅流转管理、读者信息管理再配上统计和登录权限。这三条线几乎覆盖了CRUD、多表联查、条件分页、状态流转、关联删除这些Java后端最常见的面试考点这也是我推荐拿它练手的原因。举个具体的例子借阅模块不是简单的insert一条记录它至少要处理三件事查读者是否存在且未拉黑、查图书库存是否大于0、把图书表的库存字段减一。如果归还还要反查借阅记录更新状态、库存加一。这套业务流转做下来你对事务和SQL的掌握会比写一百个单表接口都扎实。1.2 为什么必须前后端分离很多教材项目至今仍用Thymeleaf直接把数据渲染到页面一个Controller里既写接口又返回视图。以前的玩法看着简单可一旦页面复杂起来就难受得要命——前端改一行样式后端要重新编译打包接口给第三方用还得再复制一套JSON输出。前后端分离的好处是后端只关心接口返回数据前端只关心页面怎么渲染。开发时两边可以并行前端用mock数据调样式后端用Postman测接口最后联调时对一下字段名就行。部署上也灵活可以前端Nginx、后端jar包分开跑也可以把前端打包产物直接扔进SpringBoot的static目录一台服务器就能搞定。这套源码采用的就是完全分离的方式前端所有请求通过HTTP接口走后端后端只返回JSON不做任何页面跳转逻辑。在我看来这才是一个能让你理解真实工作流的项目结构。1.3 功能清单与页面规划我用表格列一下这套图书管理系统最终包含的功能模块方便你对照源码理解模块页面功能后端接口要点登录模块账号密码登录、退出、当前用户信息JWT Token签发与校验图书管理图书列表、条件搜索书名/ISBN/分类/状态、新增、编辑、删除、上架下架分页查询、多条件动态SQL、库存更新分类管理分类树/列表、新增子分类、编辑、删除父子级联、删除前检查关联图书读者管理读者列表、押金状态、借阅历史、冻结/解冻关联借阅记录统计借阅管理借书登记、还书登记、借阅记录查询、超期标记事务操作、库存联动、状态流转统计面板图书总量、借出数量、分类占比、近7日借阅趋势聚合查询、日期分组页面端对应的是Vue3里的路由划分比如/book/list对应图书列表页/borrow/record对应借阅记录页。路由守卫会在未登录时把用户踢回登录页。这套菜单和页面规划不算复杂但每个页面都覆盖了“列表表单详情删除确认”的基本闭环是很典型的管理后台形态。2. 技术栈选型与核心原理2.1 SpringBoot为什么它是后端的第一选择SpringBoot真正解决了Spring配置地狱的问题。以前搭一个SpringMVC工程要写一堆XML配数据源、配事务、配扫描包每一步都可能因为版本不兼容翻车。SpringBoot通过自动配置和约定优于配置把大部分默认行为都给你安排好了你只需要关注业务代码。这套系统选用SpringBoot还有一个实际原因部署成本低。打包成可执行jar后服务器上只需要有JDK环境一行java -jar就能启动内置的Tomcat替你解决Web容器安装问题。对初学者来说这是最容易获得正反馈的启动方式。需要提醒的是SpringBoot版本选择。网上大量教程都在用2.x但新项目用3.x也不少。版本太高容易遇到两类问题一是javax包名变成了jakarta老代码的import全部报错二是部分第三方starter还没跟上可能出现启动异常。如果你的毕设或生产项目追求稳定建议先用SpringBoot 2.7.x搭配JDK8把整套流程跑通后再考虑升3.x。我从实际经验出发版本升级的坑远比功能收益多没必要在这上面折腾。2.2 MyBatis MySQL灵活SQL与配置细节选MyBatis而不选JPA核心原因就一条SQL的可控性。图书管理系统的查询条件千奇百怪——书名模糊匹配、分类筛选、状态组合、日期区间MyBatis可以让你直接写原生SQL动态标签对条件进行拼接完全清楚最终执行的是什么东西。调试起来也直观把日志里的SQL复制到Navicat里一跑问题出在哪一清二楚。这套项目里MyBatis的使用方式是经典的三件套Mapper接口定义方法、XML文件写SQL、实体类做参数映射。动态SQL的where、if、foreach标签会在图书列表查询里大量出现这也是为什么我说做这个项目能练到面试常问的MyBatis动态SQL。MySQL这边要提醒几个细节。第一是字符集建库时建议指定utf8mb4它可以存emoji和生僻字否则前端输入特殊字符可能报错。第二是时区连接串里加上serverTimezoneAsia/Shanghai不然日期字段会差几个小时。第三是SSL连接如果你用的是MySQL 8.0以上连接串不加useSSLfalse本地测试时经常报SSL错误虽然不影响功能但看着很闹心。这三个配置我在后文会给出具体写法。2.3 Vue3组合式API带来的开发效率提升Vue3最核心的变化是引入了Composition API也就是setup语法。这个转变对管理后台类项目尤其友好。以前用Options API一个页面的数据、计算属性、方法按选项散落各处代码一旦超过300行维护起来就东翻西找。Composition API允许你把某个业务逻辑的变量和函数写在一起按模块组织代码阅读体验和复用性都强得多。我打个比方Options API像你衣柜里所有衣服都按类型叠好找一件T恤得翻半天Composition API像按套装挂起来一套衣服一个区域拿起来就能穿。图书列表页如果把“搜索表单、表格数据、分页参数、加载方法”聚拢在一块逻辑清晰程度会完全不一样。Vue3配合Vite开发时热更新速度比Webpack时代的Vue2快很多。再加上Element Plus组件库表格、表单、弹窗、消息提示这些现成的UI组件基本能覆盖管理后台的全部需求。我实测跑下来从初始化工程到做出第一个可联调的图书列表页熟练的话半天就够。3. 后端从0到1实现过程3.1 数据库设计与建表SQL数据库设计是整个项目的地基。我设计这套图书管理系统数据库时遵循一个原则先定业务关系再定表结构。核心关系是图书和借阅记录是一对多读者和借阅记录是一对多分类和图书是一对多。基于这个关系建表并不复杂。我直接给出一份精简的建表SQL方便你能在MySQL里跑通实际源码会在字段上扩展一些时间字段和冗余字段。CREATE DATABASE IF NOT EXISTS library_db DEFAULT CHARACTER SET utf8mb4; USE library_db; CREATE TABLE book_category ( id int NOT NULL AUTO_INCREMENT, name varchar(64) NOT NULL COMMENT 分类名称, parent_id int DEFAULT 0 COMMENT 父分类ID, sort int DEFAULT 0 COMMENT 排序号, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT图书分类表; CREATE TABLE book ( id int NOT NULL AUTO_INCREMENT, isbn varchar(32) DEFAULT NULL COMMENT ISBN号, name varchar(128) NOT NULL COMMENT 书名, author varchar(64) DEFAULT NULL COMMENT 作者, category_id int DEFAULT NULL COMMENT 分类ID, publisher varchar(128) DEFAULT NULL COMMENT 出版社, publish_date date DEFAULT NULL COMMENT 出版日期, stock int DEFAULT 1 COMMENT 库存总量, borrowed_count int DEFAULT 0 COMMENT 当前借出数量, status tinyint DEFAULT 1 COMMENT 1在架 0下架, PRIMARY KEY (id), KEY idx_category_id (category_id), KEY idx_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT图书表; CREATE TABLE reader ( id int NOT NULL AUTO_INCREMENT, card_no varchar(32) NOT NULL COMMENT 读者证号, name varchar(64) NOT NULL COMMENT 姓名, phone varchar(20) DEFAULT NULL, status tinyint DEFAULT 1 COMMENT 1正常 0冻结, PRIMARY KEY (id), UNIQUE KEY uk_card_no (card_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT读者表; CREATE TABLE borrow_record ( id int NOT NULL AUTO_INCREMENT, book_id int NOT NULL COMMENT 图书ID, reader_id int NOT NULL COMMENT 读者ID, borrow_date datetime NOT NULL COMMENT 借出时间, due_date datetime NOT NULL COMMENT 应还时间, return_date datetime DEFAULT NULL COMMENT 实际归还时间, status tinyint DEFAULT 0 COMMENT 0借阅中 1已归还 2超期, PRIMARY KEY (id), KEY idx_reader_id (reader_id), KEY idx_book_id (book_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT借阅记录表;库存字段我特意设计了stock和borrowed_count两个数。为什么不用一个remain_stock字段因为图书列表页要展示总库存和借出数如果用单字段你得在列表接口里做子查询统计借阅表性能差且写法复杂。冗余一个borrowed_count字段虽然增加了一点维护成本但换来了查询时的简单和高效。这种“用可接受的冗余换查询性能”的思路在真实项目里非常常见。3.2 工程初始化与分层配置后端工程建议直接用Spring Initializr构建。依赖只需要spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-j、lombok这几个。如果是SpringBoot 2.x版本MyBatis的starter坐标是org.mybatis.spring.boot:mybatis-spring-boot-starter:2.3.1SpringBoot 3.x版本需要换2.3.x以上的starter这块可以直接查Maven仓库最新版本。整个工程我建议分成四个包controller接收请求、参数校验、返回统一结果service业务逻辑、事务管理mapperMyBatis的Mapper接口entity数据库表对应的实体类再加上一个common包放统一返回体、异常处理、分页结果。分层的意义在于职责分离。Controller只做参数与响应的转换Service只做业务规则Mapper只做数据访问。你以后接手任何Java项目基本都是这个套路提前养成习惯会少吃很多亏。application.yml里的关键配置我给出一份参考server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/library_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的密码 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplmap-underscore-to-camel-case这个配置建议一定开启它能自动把数据库的category_id映射成实体的categoryId少写一堆resultMap。log-impl配置成StdOutImpl可以在控制台打印完整SQL调试后端时能看清MyBatis实际执行了哪条语句、传了什么参数。我几乎每个项目默认都会开联调阶段能省大量排查时间。3.3 分层实现与核心代码示例分层代码的关键就是每层别越界。我先从实体开始。图书实体类基本就是照着表字段写用Lombok的Data注解省掉getter/setter。Data public class Book { private Integer id; private String isbn; private String name; private String author; private Integer categoryId; private String publisher; private LocalDate publishDate; private Integer stock; private Integer borrowedCount; private Integer status; }Mapper接口只做接口声明Mapper public interface BookMapper { ListBook selectByCondition(Param(name) String name, Param(categoryId) Integer categoryId, Param(status) Integer status, Param(offset) int offset, Param(limit) int limit); long countByCondition(Param(name) String name, Param(categoryId) Integer categoryId, Param(status) Integer status); Book selectById(Integer id); int insert(Book book); int updateById(Book book); int deleteById(Integer id); }SQL写在XML里重点看动态条件拼接select idselectByCondition resultTypecom.example.entity.Book SELECT * FROM book where if testname ! null and name ! AND name LIKE CONCAT(%, #{name}, %) /if if testcategoryId ! null AND category_id #{categoryId} /if if teststatus ! null AND status #{status} /if /where ORDER BY id DESC LIMIT #{offset}, #{limit} /selectwhere标签会自动去掉第一个多余的AND这是MyBatis最常用的动态SQL技巧。分页我用手写LIMIT而不是引入PageHelper插件理由是这套系统数据量不大手写分页更容易理解原理也能减少一个依赖。你要是在面试里被问MyBatis分页先能解释清楚手写LIMIT再说PageHelper的拦截器原理层次会高很多。Service层处理业务规则。拿借书接口举例Transactional public void borrowBook(Integer bookId, Integer readerId) { Book book bookMapper.selectById(bookId); if (book null || book.getStatus() 0) { throw new RuntimeException(图书不存在或已下架); } if (book.getStock() - book.getBorrowedCount() 0) { throw new RuntimeException(图书库存不足); } Reader reader readerMapper.selectById(readerId); if (reader null || reader.getStatus() 0) { throw new RuntimeException(读者不存在或已被冻结); } borrowRecordMapper.insert(bookId, readerId, LocalDateTime.now(), LocalDateTime.now().plusDays(30)); bookMapper.increaseBorrowedCount(bookId); }注意接口上的Transactional注解。借书操作必须同时完成插入借阅记录和更新库存两步不能分开执行。没有事务中途抛异常就会出现“记录插入了但库存没扣”或者反过来这类数据不一致在图书系统这种业务场景下很容易暴露。面试官很喜欢问的事务这就是一个特别实在的落地点。统一返回体我习惯这么设计Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }前端只要判断code是不是200就能决定走成功逻辑还是错误提示。这套规范虽然简单但前后端沟通成本会大幅度降低。3.4 接口自测与调试技巧写完接口不要急着写前端先花半小时把接口全部验证一遍。我建议直接用Postman或Apifox把每个接口的请求方式、参数、返回体确认好。这里有个小技巧先按设计好的接口文档自测再交给前端联调表面上看多花了点时间实际上能避免联调阶段反复拉扯。调试MyBatis还有一个实用技巧把log-impl配置好之后每次请求都能在控制台看到类似这样的输出 Preparing: SELECT * FROM book WHERE name LIKE CONCAT(%, ?, %) AND category_id ? LIMIT ?, ? Parameters: 三(String), 1(Integer), 0(Integer), 10(Integer) Columns: id, isbn, name, author, category_id, stock, borrowed_count Row: 1, 9787111213826, 三体, 刘慈欣, 1, 10, 3如果你发现SQL里条件没拼上或者参数传错了控制台一对比就能看出来。很多新手遇到“列表查不出数据”的问题第一反应是去前端调代码其实更快的路径是先看后端控制台打印的SQL拿到Navicat里执行一遍。哪个环节出问题一目了然。4. Vue3前端实现与关键细节4.1 用Vite初始化工程与安装组件库前端工程我推荐用Vite初始化命令很简单npm create vitelatest library-web -- --template vue cd library-web npm install npm install element-plus axios vue-router pinia到这里有个常见的坑很多人会用npm create vite交互式去选模板跳到框架选择那一层容易选到React或原生JS。加--template vue直接指定模板可以省掉选择题。我一般还会顺手把vueuse/core装上里面有一堆实用的组合式函数比如useDebounceFn做搜索防抖省得自己写定时器。4.2 Axios封装与跨域处理前端所有接口请求建议集中封装。一个基础配置长这样import axios from axios import { ElMessage } from element-plus import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) // 请求拦截器 request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 响应拦截器 request.interceptors.response.use( response { const res response.data if (res.code 200) { return res.data } ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } ElMessage.error(error.message || 网络异常) return Promise.reject(error) } ) export default request这段代码有三个关键点请求拦截器自动携带Token响应拦截器统一处理业务码和401跳登录接口调用方只需要关心成功数据。前端任何页面拿到的不再是包了一层的结果体而直接是后端返回的业务数据代码会干净很多。关于跨域本地开发时最容易遇到这个问题。Vite的解决方案是在vite.config.js里配置代理export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } } })这样前端请求/api/book/list会被代理转发到后端的/book/list浏览器端不产生跨域请求也就不会出现Access-Control-Allow-Origin的一堆报错。这里说句实在话Vite的代理配置比Vue2时代的webpack还简单但很多新手不知道有这个方案愣是跑去后端加CORS配置虽然也能解决但本地代理才是前端团队更常用的玩法。4.3 核心页面实现思路图书列表页是整个系统最有代表性的页面。我建议用Composition API的组织方式把搜索、表格、分页聚拢在同一个逻辑区域。我强烈建议用script setup语法写法更简洁导入组件后不需要注册直接用就行。用一个精简示例看看图书列表页的组织方式template el-card el-form :inlinetrue :modelqueryForm el-form-item label书名 el-input v-modelqueryForm.name placeholder请输入书名 clearable / /el-form-item el-form-item label分类 el-select v-modelqueryForm.categoryId placeholder请选择分类 clearable el-option v-foritem in categories :keyitem.id :labelitem.name :valueitem.id / /el-select /el-form-item el-form-item el-button typeprimary clickhandleSearch查询/el-button el-button clickhandleReset重置/el-button /el-form-item /el-form el-table :datatableData border stripe v-loadingloading el-table-column propisbn labelISBN width160 / el-table-column propname label书名 min-width200 / el-table-column propauthor label作者 width130 / el-table-column propstock label库存 width80 / el-table-column propborrowedCount label借出 width80 / el-table-column label操作 width160 fixedright template #default{ row } el-button link typeprimary clickhandleEdit(row)编辑/el-button el-button link typedanger clickhandleDelete(row)删除/el-button /template /el-table-column /el-table el-pagination v-model:current-pagequeryForm.pageNum v-model:page-sizequeryForm.pageSize :totaltotal :page-sizes[10, 20, 50] layouttotal, sizes, prev, pager, next changeloadData / /el-card /template script setup import { onMounted, reactive, ref } from vue import { getBookList, deleteBook } from /api/book const queryForm reactive({ name: , categoryId: null, pageNum: 1, pageSize: 10 }) const tableData ref([]) const total ref(0) const loading ref(false) async function loadData() { loading.value true try { const data await getBookList(queryForm) tableData.value data.list total.value data.total } finally { loading.value false } } function handleSearch() { queryForm.pageNum 1 loadData() } function handleReset() { queryForm.name queryForm.categoryId null queryForm.pageNum 1 loadData() } onMounted(loadData) /script这里我特别解释一下loadData的写法。loading.value true放在请求前finally里关闭无论接口成功还是失败都不会让表格一直处于加载状态。还有handleSearch把页码重置为1这个细节很容易被忽略——如果你正在第3页筛选不重置页码查询结果出来可能是个空页用户会误以为查询没生效。4.4 路由守卫与权限控制有了Token之后前端还需要用路由守卫控制页面访问权限。在router/index.js里加一个全局前置守卫router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path /login) { next() } else if (!token) { next(/login) } else { next() } })这段逻辑的作用是未登录用户无论访问哪个页面都会被强制跳回登录页。看起来简单但它能挡住一大类问题——直接刷新页面时Vue应用状态丢失如果没有守卫判断用户会看到一个空白页面或一堆接口报错。有了守卫刷新后先验证本地Token再决定放不放行。我实测下来一套图书管理系统的前端最核心的就是这四块工程初始化、请求封装、页面组件、路由守卫。把这四块吃透你几乎可以拿着同一套模板去套任何管理后台项目。5. 联调部署与问题排查实录5.1 前后端联调中的高频问题联调阶段是项目中最容易出问题的地方。我做个速查表这些问题基本属于必踩类型现象根本原因解决思路前端请求报CORS错误端口不同导致的跨域优先用Vite代理生产用Nginx反向代理时间精确到秒但前端只显示日期后端返回格式不匹配统一在实体字段加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)删除图书报无法删除借阅记录关联数据未处理先检查借阅表中是否有未归还记录提示用户列表接口返回字段全是null实体属性与表字段映射不上开启map-underscore-to-camel-case或补充resultMap分页后总条数对不上没走count查询或一对多关联查询将count和list分开查询中文乱码数据库字符集或连接参数问题统一utf8mb4连接串加characterEncodingutf8CORS问题我再多说几句。前端项目如果用npm run dev起在5173端口后端8080端口直接请求后端接口浏览器会因为跨域拦截报错。最省事的做法是从一开始就约定好前端所有请求都走/api前缀开发时Vite代理转发部署时Nginx反向代理到后端端口。这样代码里不需要写任何跨域注解生产环境也不会暴露后端端口安全和维护性都会好很多。5.2 打包部署的两种路径联调完成后接下来就是部署。这套系统有两种部署方式都可以选。方式一前端打包后交给SpringBoot托管。先在前端目录执行npm run build会产生一个dist目录。把这个目录里的文件全部复制到SpringBoot项目的src/main/resources/static目录下重新打包后端jar。这样前端页面和后端接口都跑在同一个端口访问根路径就是图书管理系统页面。这种方式适合小项目一台服务器、一个进程部署最简单。方式二前端打包后用Nginx托管后端jar单独跑。Nginx配置静态资源目录和反向代理server { listen 80; server_name your-domain.com; location / { root /var/www/library-web/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files这个配置尤其重要。Vue3是单页应用路由用的是history模式用户刷新/book/list页面时Nginx如果没有这个配置会直接返回404。加上try_files后所有路径都会回退到index.html由前端路由接管。这个坑我见过太多次了不算复杂但不加上页面刷新就挂。方式二适合后续要扩展、做负载均衡、前后端要分别部署的场景。个人项目我建议先用方式一一步到位部署最简单。5.3 一些实际的避坑经验最后分享几个我在这个项目上积累的实操经验基本都是百度不到的那种。第一SQL date类型别用java.util.Date。Java 8之后建议用LocalDate和LocalDateTime和MySQL的date/datetime对应更准确也省去时区转换的麻烦。如果项目里日期字段出现“差8小时”的诡异情况多半就是Date和时区在捣乱。第二前端删除操作一定要二次确认。Element Plus的ElMessageBox.confirm不算复杂但很关键。很多用户误删图书如果连个确认弹窗都没有体验非常糟糕。从设计角度说删除和新增编辑不同它是不可逆操作必须给用户一个反悔的机会。第三图书库存扣减要考虑并发。借书接口虽然加了事务但高并发场景下两个用户同时借同一本书理论上是可能超借的。这个项目里我用UPDATE book SET borrowed_count borrowed_count 1 WHERE id ? AND borrowed_count stock这样的条件更新来解决让数据库帮我们做校验。你面试时能提到这种细节比背八股文加分得多。第四MyBatis的缓存机制。默认情况下MyBatis的二级缓存是关闭的你不需要刻意配置。网上很多文章把它讲得神乎其神实际项目里我反而不建议乱开尤其是这种图书借阅系统数据变动频繁缓存一旦失效策略没配置好很容易出现脏数据。保持默认关闭等真的需要性能优化时再做针对性的缓存设计。6. 这套源码还能怎么扩展如果你跑通这套图书管理系统之后觉得不过瘾我建议从这几个方向做升级用Redis缓存图书分类和热门图书排行榜减少数据库压力给借阅模块加定时任务每天自动扫描超期记录并更新状态用Excel导出功能把图书清单和借阅记录导给管理员归档加一个简单的读者OpenID登录变成手机端也能用的形态。我个人做这个项目最大的体会是一个系统只有跑在真实场景里才会暴露各种问题。你设计得再完美的表结构遇到一个“同一本书被两个人同时借”的需求也得去思考并发控制你接口文档写得再清楚遇到前端传错一个字段名也会去追数据流。这些经验不是看书看出来的是要动手一个字一个字敲出来才能沉淀下来的。对我来说图书管理系统最大的价值不在于功能本身而在于它把Java后端、Vue3前端、MySQL存储这条完整链路串到一起让你在做一个“正经系统”的过程中把那些零散的知识点真正焊接起来。你可以把它当作面试前的实战训练场也可以在这个基础上加自己的业务需求。拿这套代码多折腾几次收获一定会超出预期。 SpringBoot+Vue3前后端分离图书管理系统实战解析
图书管理系统大概是Java开发圈子里最常见的实战项目了——校园毕设、培训机构作业、新人练手到处都能看到它的身影。但很多项目还停留在JSPServlet或者SpringBootThymeleaf的旧模式前后端耦合在一起改个页面都要重启服务。今天要聊的这套源码用SpringBoot Vue3 MyBatis MySQL的组合后端只出接口前端单独维护整个架构从一开始就是按真实项目的标准来组织的。如果你正打算做一个前后端分离的Java项目或者想用一套完整源码来研究Vue3配合SpringBoot到底怎么配合这篇文章可以帮你省下不少摸索的时间。我会从项目功能拆解、技术选型理由到后端分层实现、前端封装联调再到部署时踩过的坑尽量把每个环节为什么这样做讲清楚。内容偏实操跟着走一遍你不仅能跑起这个图书管理系统还能顺手把它改造成自己想要的形态。1. 项目定位与功能拆解1.1 图书管理系统到底要解决什么问题做图书管理系统之前先别急着打开IDE写代码。我习惯先想一个问题图书管理员每天最烦什么图书找不到、借出不知道借给谁、归还日期记不清、盘点数目对不上。系统要解决的其实就是这类琐碎问题——把纸面记录变成数据结构把人工核对变成SQL查询。所以这个项目围绕三条主线展开图书档案管理、借阅流转管理、读者信息管理再配上统计和登录权限。这三条线几乎覆盖了CRUD、多表联查、条件分页、状态流转、关联删除这些Java后端最常见的面试考点这也是我推荐拿它练手的原因。举个具体的例子借阅模块不是简单的insert一条记录它至少要处理三件事查读者是否存在且未拉黑、查图书库存是否大于0、把图书表的库存字段减一。如果归还还要反查借阅记录更新状态、库存加一。这套业务流转做下来你对事务和SQL的掌握会比写一百个单表接口都扎实。1.2 为什么必须前后端分离很多教材项目至今仍用Thymeleaf直接把数据渲染到页面一个Controller里既写接口又返回视图。以前的玩法看着简单可一旦页面复杂起来就难受得要命——前端改一行样式后端要重新编译打包接口给第三方用还得再复制一套JSON输出。前后端分离的好处是后端只关心接口返回数据前端只关心页面怎么渲染。开发时两边可以并行前端用mock数据调样式后端用Postman测接口最后联调时对一下字段名就行。部署上也灵活可以前端Nginx、后端jar包分开跑也可以把前端打包产物直接扔进SpringBoot的static目录一台服务器就能搞定。这套源码采用的就是完全分离的方式前端所有请求通过HTTP接口走后端后端只返回JSON不做任何页面跳转逻辑。在我看来这才是一个能让你理解真实工作流的项目结构。1.3 功能清单与页面规划我用表格列一下这套图书管理系统最终包含的功能模块方便你对照源码理解模块页面功能后端接口要点登录模块账号密码登录、退出、当前用户信息JWT Token签发与校验图书管理图书列表、条件搜索书名/ISBN/分类/状态、新增、编辑、删除、上架下架分页查询、多条件动态SQL、库存更新分类管理分类树/列表、新增子分类、编辑、删除父子级联、删除前检查关联图书读者管理读者列表、押金状态、借阅历史、冻结/解冻关联借阅记录统计借阅管理借书登记、还书登记、借阅记录查询、超期标记事务操作、库存联动、状态流转统计面板图书总量、借出数量、分类占比、近7日借阅趋势聚合查询、日期分组页面端对应的是Vue3里的路由划分比如/book/list对应图书列表页/borrow/record对应借阅记录页。路由守卫会在未登录时把用户踢回登录页。这套菜单和页面规划不算复杂但每个页面都覆盖了“列表表单详情删除确认”的基本闭环是很典型的管理后台形态。2. 技术栈选型与核心原理2.1 SpringBoot为什么它是后端的第一选择SpringBoot真正解决了Spring配置地狱的问题。以前搭一个SpringMVC工程要写一堆XML配数据源、配事务、配扫描包每一步都可能因为版本不兼容翻车。SpringBoot通过自动配置和约定优于配置把大部分默认行为都给你安排好了你只需要关注业务代码。这套系统选用SpringBoot还有一个实际原因部署成本低。打包成可执行jar后服务器上只需要有JDK环境一行java -jar就能启动内置的Tomcat替你解决Web容器安装问题。对初学者来说这是最容易获得正反馈的启动方式。需要提醒的是SpringBoot版本选择。网上大量教程都在用2.x但新项目用3.x也不少。版本太高容易遇到两类问题一是javax包名变成了jakarta老代码的import全部报错二是部分第三方starter还没跟上可能出现启动异常。如果你的毕设或生产项目追求稳定建议先用SpringBoot 2.7.x搭配JDK8把整套流程跑通后再考虑升3.x。我从实际经验出发版本升级的坑远比功能收益多没必要在这上面折腾。2.2 MyBatis MySQL灵活SQL与配置细节选MyBatis而不选JPA核心原因就一条SQL的可控性。图书管理系统的查询条件千奇百怪——书名模糊匹配、分类筛选、状态组合、日期区间MyBatis可以让你直接写原生SQL动态标签对条件进行拼接完全清楚最终执行的是什么东西。调试起来也直观把日志里的SQL复制到Navicat里一跑问题出在哪一清二楚。这套项目里MyBatis的使用方式是经典的三件套Mapper接口定义方法、XML文件写SQL、实体类做参数映射。动态SQL的where、if、foreach标签会在图书列表查询里大量出现这也是为什么我说做这个项目能练到面试常问的MyBatis动态SQL。MySQL这边要提醒几个细节。第一是字符集建库时建议指定utf8mb4它可以存emoji和生僻字否则前端输入特殊字符可能报错。第二是时区连接串里加上serverTimezoneAsia/Shanghai不然日期字段会差几个小时。第三是SSL连接如果你用的是MySQL 8.0以上连接串不加useSSLfalse本地测试时经常报SSL错误虽然不影响功能但看着很闹心。这三个配置我在后文会给出具体写法。2.3 Vue3组合式API带来的开发效率提升Vue3最核心的变化是引入了Composition API也就是setup语法。这个转变对管理后台类项目尤其友好。以前用Options API一个页面的数据、计算属性、方法按选项散落各处代码一旦超过300行维护起来就东翻西找。Composition API允许你把某个业务逻辑的变量和函数写在一起按模块组织代码阅读体验和复用性都强得多。我打个比方Options API像你衣柜里所有衣服都按类型叠好找一件T恤得翻半天Composition API像按套装挂起来一套衣服一个区域拿起来就能穿。图书列表页如果把“搜索表单、表格数据、分页参数、加载方法”聚拢在一块逻辑清晰程度会完全不一样。Vue3配合Vite开发时热更新速度比Webpack时代的Vue2快很多。再加上Element Plus组件库表格、表单、弹窗、消息提示这些现成的UI组件基本能覆盖管理后台的全部需求。我实测跑下来从初始化工程到做出第一个可联调的图书列表页熟练的话半天就够。3. 后端从0到1实现过程3.1 数据库设计与建表SQL数据库设计是整个项目的地基。我设计这套图书管理系统数据库时遵循一个原则先定业务关系再定表结构。核心关系是图书和借阅记录是一对多读者和借阅记录是一对多分类和图书是一对多。基于这个关系建表并不复杂。我直接给出一份精简的建表SQL方便你能在MySQL里跑通实际源码会在字段上扩展一些时间字段和冗余字段。CREATE DATABASE IF NOT EXISTS library_db DEFAULT CHARACTER SET utf8mb4; USE library_db; CREATE TABLE book_category ( id int NOT NULL AUTO_INCREMENT, name varchar(64) NOT NULL COMMENT 分类名称, parent_id int DEFAULT 0 COMMENT 父分类ID, sort int DEFAULT 0 COMMENT 排序号, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT图书分类表; CREATE TABLE book ( id int NOT NULL AUTO_INCREMENT, isbn varchar(32) DEFAULT NULL COMMENT ISBN号, name varchar(128) NOT NULL COMMENT 书名, author varchar(64) DEFAULT NULL COMMENT 作者, category_id int DEFAULT NULL COMMENT 分类ID, publisher varchar(128) DEFAULT NULL COMMENT 出版社, publish_date date DEFAULT NULL COMMENT 出版日期, stock int DEFAULT 1 COMMENT 库存总量, borrowed_count int DEFAULT 0 COMMENT 当前借出数量, status tinyint DEFAULT 1 COMMENT 1在架 0下架, PRIMARY KEY (id), KEY idx_category_id (category_id), KEY idx_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT图书表; CREATE TABLE reader ( id int NOT NULL AUTO_INCREMENT, card_no varchar(32) NOT NULL COMMENT 读者证号, name varchar(64) NOT NULL COMMENT 姓名, phone varchar(20) DEFAULT NULL, status tinyint DEFAULT 1 COMMENT 1正常 0冻结, PRIMARY KEY (id), UNIQUE KEY uk_card_no (card_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT读者表; CREATE TABLE borrow_record ( id int NOT NULL AUTO_INCREMENT, book_id int NOT NULL COMMENT 图书ID, reader_id int NOT NULL COMMENT 读者ID, borrow_date datetime NOT NULL COMMENT 借出时间, due_date datetime NOT NULL COMMENT 应还时间, return_date datetime DEFAULT NULL COMMENT 实际归还时间, status tinyint DEFAULT 0 COMMENT 0借阅中 1已归还 2超期, PRIMARY KEY (id), KEY idx_reader_id (reader_id), KEY idx_book_id (book_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT借阅记录表;库存字段我特意设计了stock和borrowed_count两个数。为什么不用一个remain_stock字段因为图书列表页要展示总库存和借出数如果用单字段你得在列表接口里做子查询统计借阅表性能差且写法复杂。冗余一个borrowed_count字段虽然增加了一点维护成本但换来了查询时的简单和高效。这种“用可接受的冗余换查询性能”的思路在真实项目里非常常见。3.2 工程初始化与分层配置后端工程建议直接用Spring Initializr构建。依赖只需要spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-j、lombok这几个。如果是SpringBoot 2.x版本MyBatis的starter坐标是org.mybatis.spring.boot:mybatis-spring-boot-starter:2.3.1SpringBoot 3.x版本需要换2.3.x以上的starter这块可以直接查Maven仓库最新版本。整个工程我建议分成四个包controller接收请求、参数校验、返回统一结果service业务逻辑、事务管理mapperMyBatis的Mapper接口entity数据库表对应的实体类再加上一个common包放统一返回体、异常处理、分页结果。分层的意义在于职责分离。Controller只做参数与响应的转换Service只做业务规则Mapper只做数据访问。你以后接手任何Java项目基本都是这个套路提前养成习惯会少吃很多亏。application.yml里的关键配置我给出一份参考server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/library_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的密码 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplmap-underscore-to-camel-case这个配置建议一定开启它能自动把数据库的category_id映射成实体的categoryId少写一堆resultMap。log-impl配置成StdOutImpl可以在控制台打印完整SQL调试后端时能看清MyBatis实际执行了哪条语句、传了什么参数。我几乎每个项目默认都会开联调阶段能省大量排查时间。3.3 分层实现与核心代码示例分层代码的关键就是每层别越界。我先从实体开始。图书实体类基本就是照着表字段写用Lombok的Data注解省掉getter/setter。Data public class Book { private Integer id; private String isbn; private String name; private String author; private Integer categoryId; private String publisher; private LocalDate publishDate; private Integer stock; private Integer borrowedCount; private Integer status; }Mapper接口只做接口声明Mapper public interface BookMapper { ListBook selectByCondition(Param(name) String name, Param(categoryId) Integer categoryId, Param(status) Integer status, Param(offset) int offset, Param(limit) int limit); long countByCondition(Param(name) String name, Param(categoryId) Integer categoryId, Param(status) Integer status); Book selectById(Integer id); int insert(Book book); int updateById(Book book); int deleteById(Integer id); }SQL写在XML里重点看动态条件拼接select idselectByCondition resultTypecom.example.entity.Book SELECT * FROM book where if testname ! null and name ! AND name LIKE CONCAT(%, #{name}, %) /if if testcategoryId ! null AND category_id #{categoryId} /if if teststatus ! null AND status #{status} /if /where ORDER BY id DESC LIMIT #{offset}, #{limit} /selectwhere标签会自动去掉第一个多余的AND这是MyBatis最常用的动态SQL技巧。分页我用手写LIMIT而不是引入PageHelper插件理由是这套系统数据量不大手写分页更容易理解原理也能减少一个依赖。你要是在面试里被问MyBatis分页先能解释清楚手写LIMIT再说PageHelper的拦截器原理层次会高很多。Service层处理业务规则。拿借书接口举例Transactional public void borrowBook(Integer bookId, Integer readerId) { Book book bookMapper.selectById(bookId); if (book null || book.getStatus() 0) { throw new RuntimeException(图书不存在或已下架); } if (book.getStock() - book.getBorrowedCount() 0) { throw new RuntimeException(图书库存不足); } Reader reader readerMapper.selectById(readerId); if (reader null || reader.getStatus() 0) { throw new RuntimeException(读者不存在或已被冻结); } borrowRecordMapper.insert(bookId, readerId, LocalDateTime.now(), LocalDateTime.now().plusDays(30)); bookMapper.increaseBorrowedCount(bookId); }注意接口上的Transactional注解。借书操作必须同时完成插入借阅记录和更新库存两步不能分开执行。没有事务中途抛异常就会出现“记录插入了但库存没扣”或者反过来这类数据不一致在图书系统这种业务场景下很容易暴露。面试官很喜欢问的事务这就是一个特别实在的落地点。统一返回体我习惯这么设计Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }前端只要判断code是不是200就能决定走成功逻辑还是错误提示。这套规范虽然简单但前后端沟通成本会大幅度降低。3.4 接口自测与调试技巧写完接口不要急着写前端先花半小时把接口全部验证一遍。我建议直接用Postman或Apifox把每个接口的请求方式、参数、返回体确认好。这里有个小技巧先按设计好的接口文档自测再交给前端联调表面上看多花了点时间实际上能避免联调阶段反复拉扯。调试MyBatis还有一个实用技巧把log-impl配置好之后每次请求都能在控制台看到类似这样的输出 Preparing: SELECT * FROM book WHERE name LIKE CONCAT(%, ?, %) AND category_id ? LIMIT ?, ? Parameters: 三(String), 1(Integer), 0(Integer), 10(Integer) Columns: id, isbn, name, author, category_id, stock, borrowed_count Row: 1, 9787111213826, 三体, 刘慈欣, 1, 10, 3如果你发现SQL里条件没拼上或者参数传错了控制台一对比就能看出来。很多新手遇到“列表查不出数据”的问题第一反应是去前端调代码其实更快的路径是先看后端控制台打印的SQL拿到Navicat里执行一遍。哪个环节出问题一目了然。4. Vue3前端实现与关键细节4.1 用Vite初始化工程与安装组件库前端工程我推荐用Vite初始化命令很简单npm create vitelatest library-web -- --template vue cd library-web npm install npm install element-plus axios vue-router pinia到这里有个常见的坑很多人会用npm create vite交互式去选模板跳到框架选择那一层容易选到React或原生JS。加--template vue直接指定模板可以省掉选择题。我一般还会顺手把vueuse/core装上里面有一堆实用的组合式函数比如useDebounceFn做搜索防抖省得自己写定时器。4.2 Axios封装与跨域处理前端所有接口请求建议集中封装。一个基础配置长这样import axios from axios import { ElMessage } from element-plus import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) // 请求拦截器 request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 响应拦截器 request.interceptors.response.use( response { const res response.data if (res.code 200) { return res.data } ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } ElMessage.error(error.message || 网络异常) return Promise.reject(error) } ) export default request这段代码有三个关键点请求拦截器自动携带Token响应拦截器统一处理业务码和401跳登录接口调用方只需要关心成功数据。前端任何页面拿到的不再是包了一层的结果体而直接是后端返回的业务数据代码会干净很多。关于跨域本地开发时最容易遇到这个问题。Vite的解决方案是在vite.config.js里配置代理export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } } })这样前端请求/api/book/list会被代理转发到后端的/book/list浏览器端不产生跨域请求也就不会出现Access-Control-Allow-Origin的一堆报错。这里说句实在话Vite的代理配置比Vue2时代的webpack还简单但很多新手不知道有这个方案愣是跑去后端加CORS配置虽然也能解决但本地代理才是前端团队更常用的玩法。4.3 核心页面实现思路图书列表页是整个系统最有代表性的页面。我建议用Composition API的组织方式把搜索、表格、分页聚拢在同一个逻辑区域。我强烈建议用script setup语法写法更简洁导入组件后不需要注册直接用就行。用一个精简示例看看图书列表页的组织方式template el-card el-form :inlinetrue :modelqueryForm el-form-item label书名 el-input v-modelqueryForm.name placeholder请输入书名 clearable / /el-form-item el-form-item label分类 el-select v-modelqueryForm.categoryId placeholder请选择分类 clearable el-option v-foritem in categories :keyitem.id :labelitem.name :valueitem.id / /el-select /el-form-item el-form-item el-button typeprimary clickhandleSearch查询/el-button el-button clickhandleReset重置/el-button /el-form-item /el-form el-table :datatableData border stripe v-loadingloading el-table-column propisbn labelISBN width160 / el-table-column propname label书名 min-width200 / el-table-column propauthor label作者 width130 / el-table-column propstock label库存 width80 / el-table-column propborrowedCount label借出 width80 / el-table-column label操作 width160 fixedright template #default{ row } el-button link typeprimary clickhandleEdit(row)编辑/el-button el-button link typedanger clickhandleDelete(row)删除/el-button /template /el-table-column /el-table el-pagination v-model:current-pagequeryForm.pageNum v-model:page-sizequeryForm.pageSize :totaltotal :page-sizes[10, 20, 50] layouttotal, sizes, prev, pager, next changeloadData / /el-card /template script setup import { onMounted, reactive, ref } from vue import { getBookList, deleteBook } from /api/book const queryForm reactive({ name: , categoryId: null, pageNum: 1, pageSize: 10 }) const tableData ref([]) const total ref(0) const loading ref(false) async function loadData() { loading.value true try { const data await getBookList(queryForm) tableData.value data.list total.value data.total } finally { loading.value false } } function handleSearch() { queryForm.pageNum 1 loadData() } function handleReset() { queryForm.name queryForm.categoryId null queryForm.pageNum 1 loadData() } onMounted(loadData) /script这里我特别解释一下loadData的写法。loading.value true放在请求前finally里关闭无论接口成功还是失败都不会让表格一直处于加载状态。还有handleSearch把页码重置为1这个细节很容易被忽略——如果你正在第3页筛选不重置页码查询结果出来可能是个空页用户会误以为查询没生效。4.4 路由守卫与权限控制有了Token之后前端还需要用路由守卫控制页面访问权限。在router/index.js里加一个全局前置守卫router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path /login) { next() } else if (!token) { next(/login) } else { next() } })这段逻辑的作用是未登录用户无论访问哪个页面都会被强制跳回登录页。看起来简单但它能挡住一大类问题——直接刷新页面时Vue应用状态丢失如果没有守卫判断用户会看到一个空白页面或一堆接口报错。有了守卫刷新后先验证本地Token再决定放不放行。我实测下来一套图书管理系统的前端最核心的就是这四块工程初始化、请求封装、页面组件、路由守卫。把这四块吃透你几乎可以拿着同一套模板去套任何管理后台项目。5. 联调部署与问题排查实录5.1 前后端联调中的高频问题联调阶段是项目中最容易出问题的地方。我做个速查表这些问题基本属于必踩类型现象根本原因解决思路前端请求报CORS错误端口不同导致的跨域优先用Vite代理生产用Nginx反向代理时间精确到秒但前端只显示日期后端返回格式不匹配统一在实体字段加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)删除图书报无法删除借阅记录关联数据未处理先检查借阅表中是否有未归还记录提示用户列表接口返回字段全是null实体属性与表字段映射不上开启map-underscore-to-camel-case或补充resultMap分页后总条数对不上没走count查询或一对多关联查询将count和list分开查询中文乱码数据库字符集或连接参数问题统一utf8mb4连接串加characterEncodingutf8CORS问题我再多说几句。前端项目如果用npm run dev起在5173端口后端8080端口直接请求后端接口浏览器会因为跨域拦截报错。最省事的做法是从一开始就约定好前端所有请求都走/api前缀开发时Vite代理转发部署时Nginx反向代理到后端端口。这样代码里不需要写任何跨域注解生产环境也不会暴露后端端口安全和维护性都会好很多。5.2 打包部署的两种路径联调完成后接下来就是部署。这套系统有两种部署方式都可以选。方式一前端打包后交给SpringBoot托管。先在前端目录执行npm run build会产生一个dist目录。把这个目录里的文件全部复制到SpringBoot项目的src/main/resources/static目录下重新打包后端jar。这样前端页面和后端接口都跑在同一个端口访问根路径就是图书管理系统页面。这种方式适合小项目一台服务器、一个进程部署最简单。方式二前端打包后用Nginx托管后端jar单独跑。Nginx配置静态资源目录和反向代理server { listen 80; server_name your-domain.com; location / { root /var/www/library-web/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files这个配置尤其重要。Vue3是单页应用路由用的是history模式用户刷新/book/list页面时Nginx如果没有这个配置会直接返回404。加上try_files后所有路径都会回退到index.html由前端路由接管。这个坑我见过太多次了不算复杂但不加上页面刷新就挂。方式二适合后续要扩展、做负载均衡、前后端要分别部署的场景。个人项目我建议先用方式一一步到位部署最简单。5.3 一些实际的避坑经验最后分享几个我在这个项目上积累的实操经验基本都是百度不到的那种。第一SQL date类型别用java.util.Date。Java 8之后建议用LocalDate和LocalDateTime和MySQL的date/datetime对应更准确也省去时区转换的麻烦。如果项目里日期字段出现“差8小时”的诡异情况多半就是Date和时区在捣乱。第二前端删除操作一定要二次确认。Element Plus的ElMessageBox.confirm不算复杂但很关键。很多用户误删图书如果连个确认弹窗都没有体验非常糟糕。从设计角度说删除和新增编辑不同它是不可逆操作必须给用户一个反悔的机会。第三图书库存扣减要考虑并发。借书接口虽然加了事务但高并发场景下两个用户同时借同一本书理论上是可能超借的。这个项目里我用UPDATE book SET borrowed_count borrowed_count 1 WHERE id ? AND borrowed_count stock这样的条件更新来解决让数据库帮我们做校验。你面试时能提到这种细节比背八股文加分得多。第四MyBatis的缓存机制。默认情况下MyBatis的二级缓存是关闭的你不需要刻意配置。网上很多文章把它讲得神乎其神实际项目里我反而不建议乱开尤其是这种图书借阅系统数据变动频繁缓存一旦失效策略没配置好很容易出现脏数据。保持默认关闭等真的需要性能优化时再做针对性的缓存设计。6. 这套源码还能怎么扩展如果你跑通这套图书管理系统之后觉得不过瘾我建议从这几个方向做升级用Redis缓存图书分类和热门图书排行榜减少数据库压力给借阅模块加定时任务每天自动扫描超期记录并更新状态用Excel导出功能把图书清单和借阅记录导给管理员归档加一个简单的读者OpenID登录变成手机端也能用的形态。我个人做这个项目最大的体会是一个系统只有跑在真实场景里才会暴露各种问题。你设计得再完美的表结构遇到一个“同一本书被两个人同时借”的需求也得去思考并发控制你接口文档写得再清楚遇到前端传错一个字段名也会去追数据流。这些经验不是看书看出来的是要动手一个字一个字敲出来才能沉淀下来的。对我来说图书管理系统最大的价值不在于功能本身而在于它把Java后端、Vue3前端、MySQL存储这条完整链路串到一起让你在做一个“正经系统”的过程中把那些零散的知识点真正焊接起来。你可以把它当作面试前的实战训练场也可以在这个基础上加自己的业务需求。拿这套代码多折腾几次收获一定会超出预期。