1. 项目概述1.1 疫情后图书馆管理面临的新问题2020年之后图书馆这类公共场所的管理逻辑发生了很大变化。过去我们做管理系统更多考虑的是图书编目、读者借还、逾期罚款这些常规流程但疫情让“限流预约”“无接触借还”“读者健康状态登记”“图书消毒跟踪”这些词突然成了刚需。这个项目的选题切点就在这里——它不是简单把图书管理搬到线上而是把疫情场景下的特殊约束和传统图书馆业务流程做了一个整合。先说清楚这套系统能干什么。它不是一个只停留在课程设计层面的demo而是覆盖了图书馆日常运营核心环节的完整闭环读者通过前端页面注册登录、检索图书、在线预约、扫码借还管理员在后台维护图书档案、处理借还审核、管理预约名额、控制同时在馆人数、发布开闭馆通知系统底层用MySQL存储全部业务数据通过MyBatis完成数据持久化操作。前后端通过RESTful API交互数据格式统一采用JSON。适合谁来参考这个项目如果你是准备毕业设计的计算机专业学生这个项目能让你把Java后端、Vue前端、数据库设计三块知识串成一条完整的技能链如果你是在准备Java开发岗位面试这个项目的技术栈覆盖面很广从框架使用到数据库优化到前后端联调几乎每个环节都能提炼出面试官爱问的点如果你是刚入行的初级开发想找一个结构清晰、注释完整、能直接跑起来的全栈项目来练手这套源码也是一个不错的起点。1.2 这套系统的核心价值在哪里我以前带团队做过的管理系统不在少数大部分学生项目的问题在于“重界面、轻逻辑”页面做得花里胡哨但数据表设计一塌糊涂接口也没有异常处理。这套系统的设计思路是反过来的先把业务逻辑捋清楚再谈页面展示。核心价值第一个体现在权限模型上。系统内置了三种角色——超级管理员、图书管理员、普通读者每一种角色能访问的接口和页面都是严格区分的。权限控制不是在前端用v-if简单隐藏按钮而是在后端通过SpringBoot拦截器统一校验JWT令牌中的角色信息前端只是配合做了路由守卫。这套设计保证了即使有人绕过前端直接调API没有合法令牌也进不了管理端。第二个价值在于预约限流机制。疫情期间图书馆最头疼的就是“控制同时在馆人数”这套系统在预约模块里做了一个很实用的设计管理员可以按时间段设定可预约名额读者预约时系统先判断该时间段是否已满已满则自动提示并推荐相邻空档。这个逻辑用到了数据库的行锁查询和事务控制不是简单的前端校验。第三个价值是图书借阅的全流程追踪。从读者提交借阅申请到管理员确认出库再到归还时登记图书状态是否需要消毒隔离每一步都有时间戳和操作人记录。图书的“在馆/借出/消毒中/下架”四种状态转换是系统里状态机设计最复杂的部分也是面试时很值得展开讲的亮点。2. 后端核心实现与SpringBoot工程落地2.1 创建SpringBoot项目时的版本选择后端采用SpringBoot作为核心框架版本这里要特别提醒一下。网上很多教程还在用SpringBoot 2.x但如果你打算长期在这个项目上扩展功能我建议直接上SpringBoot 3.x。我在搭建这套系统的时候用的就是SpringBoot 3.0.5搭配JDK 17。很多初学者在“springboot版本太高”这个问题上栽过跟头——项目一启动就报各种依赖不兼容其实大部分原因是没搞清楚SpringBoot 3.x相比2.x的几个关键变化。SpringBoot 3.x基于Jakarta EE 9规范原来的javax.servlet包全部迁移到了jakarta.servlet。如果你在代码里写import javax.servlet.http.HttpServletRequest在3.x版本下直接编译不过。这个问题在写拦截器、过滤器的时候一定会遇到换成jakarta.servlet.http.HttpServletRequest就对了。另外一个变化是SpringFox的Swagger文档工具在3.x下没法直接用需要换成springdoc-openapi。这个坑我踩过一次折腾了差不多两个小时才定位到问题。如果你不想折腾文档配置直接用knife4j的3.0.3版本也可以它对SpringBoot 3.x的支持做得比较早。依赖管理用Maven还是Gradle这个因人而异我的习惯是Maven主要是pom.xml的依赖声明大家看得更熟悉。但要注意SpringBoot 3.x的父级POM里已经帮我们锁定了大部分依赖版本你不需要为每个starter手动指定版本号只需要在parent里声明好父POM即可。手动指定版本反而容易造成冲突这个是我见过很多新手常犯的错误。核心依赖清单大致如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-impl/artifactId version0.11.5/version scoperuntime/scope /dependency2.2 统一返回结果与全局异常处理接口返回格式统一这件事看起来是小事实际对前后端联调的效率影响非常大。我见过太多项目一个接口返回{code:200, data:{...}}另一个接口又直接返回裸数据前端每次都要针对不同接口写不同的解析逻辑维护成本极高。这套系统定义了一个统一的ResultT类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(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }有了这个基础之后全局异常处理就顺理成章了。用RestControllerAdvice注解拦截所有Controller层抛出的异常业务异常比如预约已满、图书不存在统一返回code500参数校验失败返回code400未登录或Token过期返回code401。前端Axios封装里只需要判断code字段code200就走成功逻辑否则弹出message字段的内容提示用户。关于全局异常处理的实操经验一定要把异常日志用log.error打出来包括堆栈信息不要只返回一个“系统错误”给前端就完事了。线上排障的时候这些日志就是你定位问题的唯一线索。2.3 JWT认证与拦截器实现认证这块我选择了JWT而不是传统的Session。原因有两个一来前后端分离架构下Session的跨域处理比较麻烦需要额外配置CORS的allowCredentials二来JWT无状态、可扩展性强以后如果做分布式部署不需要引入Redis来同步Session。JWT令牌的结构包含三部分Header、Payload、Signature。在Payload里我放了userId、username、role三个核心字段过期时间设置为2小时。签名算法用HS256密钥硬编码在配置文件中实际生产环境应该放在环境变量或配置中心里。拦截器的实现思路是这样的自定义一个JwtInterceptor实现HandlerInterceptor接口在preHandle方法里从请求头Authorization字段取出Token解析成功后把用户信息放入ThreadLocal或直接放入Request Attribute中方便后续的Controller方法获取当前登录用户。放行的白名单包括登录接口、注册接口、图书检索接口、验证码接口。这里有一个容易忽略的细节拦截器放行规则用的是addPathPatterns(/**).excludePathPatterns(/api/user/login, /api/user/register)但如果你想对管理端接口比如/api/admin/**做角色校验最好在拦截器里这样处理String role claims.get(role, String.class); String uri request.getRequestURI(); if (uri.startsWith(/api/admin) !ADMIN.equals(role)) { throw new BusinessException(无权访问); }前端配合路由守卫在vue-router的beforeEach钩子里检查localStorage中的Token是否存在如果目标路由需要管理员角色而当前用户不是就跳转到403页面。这样双端校验安全性基本到位了。2.4 核心业务接口设计与实现图书管理模块的接口设计遵循RESTful风格我举几个典型接口来拆解图书模糊搜索接口GET /api/books?keyword三体category文学pageNum1pageSize10这个接口的后台逻辑用到了MyBatis的动态SQL。传入的关键字可能匹配书名、作者、ISBN中任意一项类别是可选参数。如果使用MyBatis-Plus可以封装一个LambdaQueryWrapper来处理但为了让你了解底层机制我手写了一段XML映射select idsearchBooks resultTypecom.library.entity.Book SELECT * FROM book where if testkeyword ! null and keyword ! AND (title LIKE CONCAT(%, #{keyword}, %) OR author LIKE CONCAT(%, #{keyword}, %) OR isbn LIKE CONCAT(%, #{keyword}, %)) /if if testcategory ! null and category ! AND category #{category} /if AND status ! DISCARDED /where ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} /select注意几点模糊查询的CONCAT(%, #{keyword}, %)写法可以防止SQL注入不要在Java代码里拼%到参数中再传入分页参数用offset, limit的方式在数据量不大的情况下够用如果以后图书量超过十万条建议改成pageSize传参、在SQL中用LIMIT #{pageSize} OFFSET #{offset}的形式配合覆盖索引来优化。预约借书接口POST /api/reservations这个接口要处理的事务比较多校验读者是否有未归还的图书超过3本——超过就不能再借校验所选时间段预约名额是否已满——已满返回提示校验该读者是否已经预约过同一本书——避免重复预约。三步校验全部通过之后才真正插入一条预约记录并把图书状态改为“已预约”。整个过程在Service层用Transactional注解任何一步抛出异常事务回滚不会产生脏数据。关于事务的一个经验之谈Transactional默认只回滚RuntimeException和Error如果业务方法抛的是受检异常比如Exception事务不会回滚。所以我在项目里定义了一个继承RuntimeException的BusinessException类所有业务异常都走这个类确保事务边界正确。3. 前端Vue3页面开发与前后端协作3.1 Vue3工程创建与核心依赖前端部分用Vue3vite构建Node版本要求16以上。创建工程直接用命令npm create vitelatest library-web -- --template vue为什么不用vue-cliVite的冷启动速度和热更新体验比webpack好太多开发效率完全不在一个量级。Vue3的Composition API在组织代码时比Options API更灵活尤其在做图书筛选、多条件搜索这类交互的时候把状态逻辑抽离成自定义hook复用起来特别爽。核心依赖我装了这些vue-router做路由管理pinia替代vuex做状态管理pinia更轻量而且对TypeScript支持更好axios做请求发送element-plus做后台UI组件库echarts做数据统计图表sass做样式预处理器。3.2 登录流程与令牌管理登录是整个前端的基础设施这块设计好了后面的页面开发就会顺畅很多。登录流程是这样的用户输入账号密码前端调用/api/user/login后端验证通过后返回JWT令牌和用户信息。前端拿到Token后存入localStorage同时用pinia维护一个userStore对象保存用户基本信息。Axios请求拦截器统一做令牌注入service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer ${token} } return config })响应拦截器统一做错误处理service.interceptors.response.use( response { const res response.data if (res.code 200) { return res.data } if (res.code 401) { localStorage.removeItem(token) router.push(/login) } ElMessage.error(res.message) return Promise.reject(new Error(res.message)) }, error { ElMessage.error(网络异常请稍后重试) return Promise.reject(error) } )这样的统一封装能省掉每一个页面各自处理错误逻辑的重复劳动。而且把res.data直接返回后页面里调用接口就非常简洁const bookList await getBooks({ keyword: 三体 })不需要层层解包。3.3 图书管理核心页面实现图书列表页是整个系统里最有代表性的页面它综合了表格展示、条件筛选、分页、弹窗编辑、批量操作等多个典型后台功能。我简化说明一下核心逻辑。筛选区域放了三个条件关键字输入框、分类下拉框、状态下拉框。点击“搜索”按钮时把筛选条件存入“响应式对象”触发fetchBookList函数重新拉取数据。这里有一个实战中很加分的细节使用watch监听筛选条件变化搭配debounce防抖函数让输入关键字时自动搜索不用每次点按钮。Element Plus的el-table绑定数据后分页用el-pagination组件。页码和每页条数变化时更新查询参数再重新请求。这里要注意分页组件的时间戳要绑定服务端返回的total字段不要用当前页数据长度否则翻页时总页数会算错。编辑弹窗用el-dialog内嵌el-form表单校验规则用Element Plus的rules属性配置。提交时先调用formRef.validate()做前端校验通过后再调更新接口。整个流程下来页面代码会自然地组织成“搜索区域-表格区域-分页区域-弹窗区域”四块结构清晰后续别人接手也容易理解。3.4 前后端联调与跨域配置跨域问题可以说是前后端分离项目里最经典的“坑”了。前端跑在http://localhost:5173后端跑在http://localhost:8080两者端口不同浏览器默认会拦截跨域请求。解决方式有两种方案。第一种在后端配置CORSConfiguration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }第二种是前端配置Vite代理// vite.config.js server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }两种方案各有优劣。在开发阶段用Vite代理更方便因为浏览器看到的请求是同源的不会触发预检请求OPTIONS请求效率更高部署到生产环境后一般用Nginx做反向代理把/api前缀转发到后端服务。如果选择后端CORS方案注意allowedOriginPatterns(*)不能和allowCredentials(true)同时使用的坑——这是SpringBoot的规范限制某些版本的SpringBoot会直接报错。如果你一定要携带Cookie就明确指定允许的来源域不要使用通配符。联调时我给自己的一个要求是前端不要写死任何假数据来等后端后端也不要为了赶进度把接口返回结构随意调整。前端Mock数据可以在后端接口未完成时用来开发调试但联调时必须切换到真实接口用统一的接口文档我比较推荐Apifox来约束参数和返回体结构。4. 数据库设计与MyBatis实践4.1 核心表结构与关系设计数据库设计是这套系统的地基我用了8张核心表来支撑整个业务流程user表用户表包含id、username、passwordBCrypt加密后存储、name、phone、role、status字段。role区分ADMIN和READER。book表图书表包含id、title、author、publisher、isbn、category、total_count、available_count、status、location字段。available_count代表当前可借数量status代表图书整体状态。book_category表图书分类表id、category_name、description字段。分类独立成表是为了方便日后扩展分类层级。reservation表预约记录表id、user_id、book_id、appointment_date、time_slot、status、create_time字段。status区分PENDING、CONFIRMED、CANCELLED、COMPLETED。borrow_record表借阅记录表id、user_id、book_id、borrow_time、due_time、return_time、status字段。每一条借阅行为都在这里留痕。fine_record表逾期罚款记录表id、borrow_id、user_id、fine_amount、is_paid、create_time字段。逾期费用的计算逻辑是超过应还日期后每本每天0.1元。notice表公告表id、title、content、publish_time、publisher_id字段。管理员发布的限流通知、开闭馆通知都在这张表里。system_log表操作日志表id、user_id、operation、detail、ip、create_time字段。关键操作的审计追踪全靠它。借阅记录表和图书表是多对一关系借阅记录表和用户表是多对一关系预约记录表是用户和图书之间的多对多关联关系的体现。用户和图书没有直接做多对多映射表而是通过borrow_record这张事实表来建立关联这种设计更适合记录每次借阅的细节。MySQL引擎统一用InnoDB字符集utf8mb4排序规则utf8mb4_general_ci。utf8mb4不是可选项是必须项因为utf8在MySQL里只能存3字节的字符遇到emoji表情就会报错虽然图书管理系统里不太可能出现emoji但这是规范问题必须从一开始就做到位。4.2 MyBatis动态SQL在复杂查询中的作用MyBatis是这个项目的持久层框架我用了MyBatis-Plus作为增强工具。QueryWrapper和LambdaQueryWrapper能覆盖80%的单表查询需求但遇到多表关联或复杂条件时还是需要手写XML。举一个实际例子管理端的“图书借阅排行”报表需要按图书维度统计借阅次数关联borrow_record表和book表并按借阅次数降序排列。这段SQL手写如下select idselectBorrowRanking resultTypemap SELECT b.id, b.title, b.author, COUNT(br.id) AS borrow_count FROM book b LEFT JOIN borrow_record br ON b.id br.book_id AND br.status ! CANCELLED where if teststartDate ! null AND br.borrow_time gt; #{startDate} /if if testendDate ! null AND br.borrow_time lt; #{endDate} /if /where GROUP BY b.id, b.title, b.author ORDER BY borrow_count DESC LIMIT #{limit} /select这里有两个细节值得注意。第一LEFT JOIN后追加的条件br.status ! CANCELLED必须放在ON子句里如果放到WHERE里就变成内连接了统计结果会错。第二gt;和lt;是XML中大于等于、小于等于的正确写法直接写会解析报错。这两个都是很隐蔽的坑我第一次写就踩过。MyBatis缓存这块项目默认用了二级缓存。你可能会问“mybatis缓存”这个东西要怎么配置才合理我的回答是在图书管理这种读多写少的场景下一级缓存和二级缓存可以开启但要注意缓存的失效策略。如果某本图书的库存被借出后减少了而缓存里还存着旧的库存数查询就会出错。所以在执行INSERT、UPDATE、DELETE操作后明确调用缓存刷新CacheEvict(value bookCache, allEntries true) public void updateBook(Book book) { bookMapper.updateById(book); }使用Spring的CacheEvict注解比MyBatis自带的缓存刷新更可控也更容易在面试时讲清楚。4.3 MySQL数据库安装与配置要点很多同学在环境准备阶段就被MySQL安装绊住了。MySQL 8.0是目前使用最广泛的版本安装时有几个关键点一定要处理好。Windows下安装MySQL 8.0去官网下载MySQL Installer选择Server only即可。安装过程中会让你设置root用户密码建议设置一个你确定记得住的密码比如root123456后面连接字符串里要用到。安装完成后最重要的一件事是确认MySQL服务是否已经启动可以通过Windows服务管理器查看“MySQL80”这个服务的状态也可以命令行执行mysql -u root -p输入密码后能进入mysql提示符就说明安装成功。配置方面my.ini文件里建议设置如下参数[mysqld] character-set-serverutf8mb4 collation-serverutf8mb4_general_ci max_connections200 default-storage-engineINNODB还有一点容易被忽略MySQL 8.0默认的认证插件是caching_sha2_password而SpringBoot的mysql-connector-java 8.x版本对此完全兼容不需要额外处理。但如果你用的驱动版本是5.x就会报“Public Key Retrieval is not allowed”的错误。解决方案是升级驱动到8.x或是在jdbc连接串上加上allowPublicKeyRetrievaltrueuseSSLfalse。这个坑在网络上的提问频率极高提前讲清楚能帮你省下半个小时的排查时间。数据库连接池我用了HikariCP这是SpringBoot 2.x之后默认集成的连接池性能比Druid在纯读写场景下略好。配置如下spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/library_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root123456 hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 300004.4 图书借还状态流转的SQL实现图书借还流程是整个系统事务最密集的部分。借书事务包含两步在borrow_record表插入一条借阅记录status设置为BORROWED同时执行一条更新语句让book表的available_count减1并且当available_count变为0时把status改为“借出”。这两步必须放在同一个事务里。我用的是在Service层加Transactional(rollbackFor Exception.class)确保原子性。一个在实际开发中很关键的优化点更新库存时不要先查再改而是用一条乐观锁式的更新语句UPDATE book SET available_count available_count - 1 WHERE id #{bookId} AND available_count 0这条语句返回的影响行数是1说明扣减成功返回0说明库存已经被扣到0了。这样可以避免并发场景下的超卖问题——也就是两个读者同时借同一本书的最后一本结果两个人都认为借成功了。说白了这就是数据库层面的乐观锁思想面试官很喜欢问这个场景的解决方案。还书事务对称处理更新borrow_record状态为RETURNED填写return_time字段同时让book表的available_count加1。如果还书时间超过due_time则根据逾期天数计算罚款金额并写入fine_record表。这里逾期天数的计算放在Java代码里完成不依赖数据库函数便于做单元测试。5. 常见问题与排查技巧实录5.1 环境配置阶段的经典问题问题1SpringBoot项目启动报错“Failed to configure a DataSource”这个错误90%的情况是application.yml文件里的数据源配置没有生效。常见原因有两个一是配置文件名字写错SpringBoot默认加载的是application.yml或application.properties如果你创建的是application-dev.yml但没有在application.yml里激活该profile配置就不会加载二是yml文件的缩进格式错误SpringBoot的配置解析对缩进非常敏感少一个空格就会导致整个配置失效。排查技巧在启动类上加SpringBootApplication后可以先写一个简单的测试接口不连接数据库单独测试Web层是否正常。如果Web层没问题再逐步引入数据源配置这样可以快速定位是配置问题还是代码问题。问题2Vue3安装依赖时提示“npm ERR! ERESOLVE unable to resolve dependency tree”这个问题大多是依赖版本冲突导致的。解决方案有两种其一在安装命令后面加--legacy-peer-deps参数跳过节点头校验其二升级npm版本到7以上的同时手动拉齐Vue3生态核心包的版本。实际项目中我推荐第二种因为第一种虽然能装成功但隐藏的版本冲突日后可能会引发运行时错误。问题3IDEA中运行SpringBoot时控制台中文乱码在Settings - Editor - File Encodings里把Global Encoding、Project Encoding、Properties Files三项都改为UTF-8。同时在启动配置的VM options里加一句-Dfile.encodingUTF-8。这两步做完再重启基本能解决90%的乱码问题。5.2 前后端联调阶段的报错排查问题4前端请求接口返回404先确认后端服务是否启动成功再检查请求路径是否匹配。比如后端Controller里定义的映射是RequestMapping(/api/books)前端请求的URL就必须是/api/books。这里有一个很容易忽略的点如果使用了Vite代理代理配置里的/api前缀转发规则如果是target path而后端也是以/api开头的路径那么最终请求路径是正确的但如果后端Controller的路径没有加/api前缀只是/books那么代理配置就需要做路径重写。这个规则理不清就很容易出现404。问题5前端请求报403 Forbidden大部分情况是跨域预检请求OPTIONS没有被后端拦截器放行。我拦截器里通常这样处理if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; }在preHandle方法开头直接放行OPTIONS请求然后再做JWT校验能有效避免跨域场景下的403问题。问题6MyBatis报“Invalid bound statement (not found)”这个错误99%是Mapper接口和XML文件没有绑定成功。检查以下几点XML文件的namespace是否和Mapper接口的完整类名一致XML文件中select标签的id是否和Mapper接口方法名一致XML文件是否放在resources目录下的正确包路径如果用了MyBatis-Plus检查application.yml中是否有指定mapper-locations配置。mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml5.3 上线部署阶段的运维经验这套系统我最终是部署在一台2核4G的云服务器上的配置不算高但应付图书馆这种量级的并发完全够用。部署架构很简单Nginx做前端静态资源的托管和反向代理后端以jar包形式通过systemd守护运行MySQL和Redis直接装在服务器上。前后端分离的生产部署方式有几个要点值得记一下前端构建前需要把代码里的API请求地址环境变量化。我在项目根目录建了.env.production文件里面写VITE_API_BASE_URL/api在Vite配置中用envPrefix来识别。构建命令执行npm run build构建产物在dist目录把dist目录里所有文件上传到服务器的/var/www/library目录。Nginx配置最关键的部分就是两个静态文件路径和代理转发。完整的最小配置如下server { listen 80; server_name your-domain.com; root /var/www/library; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }注意try_files $uri $uri/ /index.html;这一行必须加上否则前端路由使用的history模式在刷新页面时会404。这也是很多新手部署完访问首页没问题但一刷新子页面就报错的原因。后端jar包的systemd服务配置如下[Unit] DescriptionLibrary Management System Afternetwork.target [Service] Userroot WorkingDirectory/opt/library ExecStart/usr/local/java/bin/java -Xms512m -Xmx1024m -jar /opt/library/library-server.jar SuccessExitStatus143 Restartalways RestartSec10 [Install] WantedBymulti-user.targetSuccessExitStatus143这个配置很关键因为在systemd停止Java进程时JVM收到SIGTERM信号会以143退出如果不声明这个为正常退出码systemd会认为服务异常终止并触发重启导致你明明执行了systemctl stop服务又很快自己拉起来了。上线后进行压测时我观察到这个配置下的QPS大约能到800左右图书查询接口在1000并发时响应时间仍然在80ms以内。MySQL的慢查询日志配置打开后我发现高频的模糊搜索接口因为LIKE %keyword%无法走索引查询耗时偏高。优化方案是引入全文索引但对目前的业务量来说并不算特别紧迫的需求。5.4 面试中经常被问到的问题基于这个项目面试官最爱问的问题集中在以下几个方面提前准备好回答思路面试时会自信很多。第一个问题为什么选择SpringBootVue3这套技术栈回答思路可以从“生态成熟度”和“开发效率”两个维度展开。SpringBoot简化了Spring的配置复杂度约定大于配置的理念让项目从零到可运行只需要几分钟Vue3的Composition API让组件逻辑复用变得简单而且TypeScript支持越来越好适合中大型前端项目。再补充一点这两个框架学习曲线相对平缓社区资源丰富遇到问题能快速找到解决方案。第二个问题项目的权限控制是怎么实现的这个问题答得好不好直接体现你是否有实践经验。先讲后端拦截器校验JWT令牌中的角色信息再讲前端路由守卫配合做页面级控制最后强调业务接口层面的二次校验。如果面试官继续追问“如果有一个普通读者绕过前端直接调管理员接口怎么办”你就可以底气十足地回答后端拦截器会对/api/admin/**路径做角色校验非ADMIN角色直接返回401。这个环节是展示你对前后端分离安全模型理解深度的大好机会。第三个问题高并发场景下怎么保证图书库存不超卖我在这篇博文前面已经详细讲过解决方案通过数据库层面的乐观锁在更新时用WHERE available_count 0条件判断而不是先查询再更新。如果面试官继续问“那如果请求量更大怎么办”可以提一下Redis分布式锁或者ZooKeeper实现分布式锁的方案顺便拿出项目里的预约限流逻辑作为实践支撑面试官会认为你是真的做过并发控制而不是只背过八股文。第四个问题项目里有没有用过索引怎么设计索引这个项目的高频查询场景是图书模糊搜索和借阅记录查询。我针对这两个场景做了索引优化图书表的title、author字段加普通索引因为模糊查询LIKE keyword%可以走索引借阅记录表的user_id加索引方便按用户维度查询历史记录borrow_time字段加索引支持按时间范围查询报表。但要注意索引不是越多越好——索引会占用存储空间还会拖慢INSERT/UPDATE/DELETE的性能需要在读写之间找一个平衡点。6. 项目扩展与个人经验总结这套系统如果只是停留在课程设计或结业作业的层面那确实有些浪费了。我在实际开发完之后又给它加了不少扩展功能这里顺便做个分享。第一个扩展是引入Redis做验证码存储和高频访问控制。登录接口增加验证码校验验证码的值存储在Redis中有效时间5分钟。同时利用Redis做接口频控同一个IP在1分钟内最多只能请求10次登录接口超过就拒绝。这个功能虽然不算复杂但让系统的健壮性提升了一个档次也让我在后来的面试中多了一个可以谈的技术亮点。第二个扩展是图书推荐功能。我在“借阅排行”基础上根据读者历史借阅记录中的分类分布做一个简单的协同过滤推荐——把高频分类的未读图书优先展示在首页。这个功能用SQL就能计算不需要专门引入推荐算法框架但对用户体验的提升很明显。第三个建议是补一套完整的单元测试。我当时给核心的借阅服务写出了覆盖全部业务分支的JUnit测试用例把超期罚金计算、预约冲突检测这些容易出错的逻辑跑得明明白白。这部分工作看似增加工作量但后续做功能变更时带给我的信心是无可替代的——改完代码跑一遍测试如果全绿就可以放心提交了。最后说一点个人体会。我从搭建这套系统的过程中最深的感觉是技术本身并不难难的是把每个模块之间的耦合关系理清楚。一开始我也踩过不少坑比如前端的接口请求路径和后端RestController的路径没对齐导致联调时浪费了大半天再比如图书状态流转时一开始没设计状态机导致某处逻辑分支遗漏直到测试用例跑出异常才修补完整。这些经历让我明白了架构设计的前置思考有多重要——你现在偷懒没有定义清楚的状态和边界后面一定会花更多时间来修补。如果你也在做类似的图书馆管理系统或者正在犹豫自己的毕设课题我的建议是先把业务流程图画清楚把数据表设计好再动手写代码。好的数据库设计能承载业务的扩展需求好的接口设计能减少前后端扯皮好的代码结构能支撑后来的维护者顺畅接手。技术圈里有一句老话叫“先跑起来再优化”但对于一个管理系统类项目我更愿意说“先想明白再做出来”。希望这篇博客的分享能帮你少走一些弯路顺利把项目做出来。
疫情后图书馆管理系统实战：SpringBoot+Vue3全栈开发指南
1. 项目概述1.1 疫情后图书馆管理面临的新问题2020年之后图书馆这类公共场所的管理逻辑发生了很大变化。过去我们做管理系统更多考虑的是图书编目、读者借还、逾期罚款这些常规流程但疫情让“限流预约”“无接触借还”“读者健康状态登记”“图书消毒跟踪”这些词突然成了刚需。这个项目的选题切点就在这里——它不是简单把图书管理搬到线上而是把疫情场景下的特殊约束和传统图书馆业务流程做了一个整合。先说清楚这套系统能干什么。它不是一个只停留在课程设计层面的demo而是覆盖了图书馆日常运营核心环节的完整闭环读者通过前端页面注册登录、检索图书、在线预约、扫码借还管理员在后台维护图书档案、处理借还审核、管理预约名额、控制同时在馆人数、发布开闭馆通知系统底层用MySQL存储全部业务数据通过MyBatis完成数据持久化操作。前后端通过RESTful API交互数据格式统一采用JSON。适合谁来参考这个项目如果你是准备毕业设计的计算机专业学生这个项目能让你把Java后端、Vue前端、数据库设计三块知识串成一条完整的技能链如果你是在准备Java开发岗位面试这个项目的技术栈覆盖面很广从框架使用到数据库优化到前后端联调几乎每个环节都能提炼出面试官爱问的点如果你是刚入行的初级开发想找一个结构清晰、注释完整、能直接跑起来的全栈项目来练手这套源码也是一个不错的起点。1.2 这套系统的核心价值在哪里我以前带团队做过的管理系统不在少数大部分学生项目的问题在于“重界面、轻逻辑”页面做得花里胡哨但数据表设计一塌糊涂接口也没有异常处理。这套系统的设计思路是反过来的先把业务逻辑捋清楚再谈页面展示。核心价值第一个体现在权限模型上。系统内置了三种角色——超级管理员、图书管理员、普通读者每一种角色能访问的接口和页面都是严格区分的。权限控制不是在前端用v-if简单隐藏按钮而是在后端通过SpringBoot拦截器统一校验JWT令牌中的角色信息前端只是配合做了路由守卫。这套设计保证了即使有人绕过前端直接调API没有合法令牌也进不了管理端。第二个价值在于预约限流机制。疫情期间图书馆最头疼的就是“控制同时在馆人数”这套系统在预约模块里做了一个很实用的设计管理员可以按时间段设定可预约名额读者预约时系统先判断该时间段是否已满已满则自动提示并推荐相邻空档。这个逻辑用到了数据库的行锁查询和事务控制不是简单的前端校验。第三个价值是图书借阅的全流程追踪。从读者提交借阅申请到管理员确认出库再到归还时登记图书状态是否需要消毒隔离每一步都有时间戳和操作人记录。图书的“在馆/借出/消毒中/下架”四种状态转换是系统里状态机设计最复杂的部分也是面试时很值得展开讲的亮点。2. 后端核心实现与SpringBoot工程落地2.1 创建SpringBoot项目时的版本选择后端采用SpringBoot作为核心框架版本这里要特别提醒一下。网上很多教程还在用SpringBoot 2.x但如果你打算长期在这个项目上扩展功能我建议直接上SpringBoot 3.x。我在搭建这套系统的时候用的就是SpringBoot 3.0.5搭配JDK 17。很多初学者在“springboot版本太高”这个问题上栽过跟头——项目一启动就报各种依赖不兼容其实大部分原因是没搞清楚SpringBoot 3.x相比2.x的几个关键变化。SpringBoot 3.x基于Jakarta EE 9规范原来的javax.servlet包全部迁移到了jakarta.servlet。如果你在代码里写import javax.servlet.http.HttpServletRequest在3.x版本下直接编译不过。这个问题在写拦截器、过滤器的时候一定会遇到换成jakarta.servlet.http.HttpServletRequest就对了。另外一个变化是SpringFox的Swagger文档工具在3.x下没法直接用需要换成springdoc-openapi。这个坑我踩过一次折腾了差不多两个小时才定位到问题。如果你不想折腾文档配置直接用knife4j的3.0.3版本也可以它对SpringBoot 3.x的支持做得比较早。依赖管理用Maven还是Gradle这个因人而异我的习惯是Maven主要是pom.xml的依赖声明大家看得更熟悉。但要注意SpringBoot 3.x的父级POM里已经帮我们锁定了大部分依赖版本你不需要为每个starter手动指定版本号只需要在parent里声明好父POM即可。手动指定版本反而容易造成冲突这个是我见过很多新手常犯的错误。核心依赖清单大致如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-impl/artifactId version0.11.5/version scoperuntime/scope /dependency2.2 统一返回结果与全局异常处理接口返回格式统一这件事看起来是小事实际对前后端联调的效率影响非常大。我见过太多项目一个接口返回{code:200, data:{...}}另一个接口又直接返回裸数据前端每次都要针对不同接口写不同的解析逻辑维护成本极高。这套系统定义了一个统一的ResultT类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(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }有了这个基础之后全局异常处理就顺理成章了。用RestControllerAdvice注解拦截所有Controller层抛出的异常业务异常比如预约已满、图书不存在统一返回code500参数校验失败返回code400未登录或Token过期返回code401。前端Axios封装里只需要判断code字段code200就走成功逻辑否则弹出message字段的内容提示用户。关于全局异常处理的实操经验一定要把异常日志用log.error打出来包括堆栈信息不要只返回一个“系统错误”给前端就完事了。线上排障的时候这些日志就是你定位问题的唯一线索。2.3 JWT认证与拦截器实现认证这块我选择了JWT而不是传统的Session。原因有两个一来前后端分离架构下Session的跨域处理比较麻烦需要额外配置CORS的allowCredentials二来JWT无状态、可扩展性强以后如果做分布式部署不需要引入Redis来同步Session。JWT令牌的结构包含三部分Header、Payload、Signature。在Payload里我放了userId、username、role三个核心字段过期时间设置为2小时。签名算法用HS256密钥硬编码在配置文件中实际生产环境应该放在环境变量或配置中心里。拦截器的实现思路是这样的自定义一个JwtInterceptor实现HandlerInterceptor接口在preHandle方法里从请求头Authorization字段取出Token解析成功后把用户信息放入ThreadLocal或直接放入Request Attribute中方便后续的Controller方法获取当前登录用户。放行的白名单包括登录接口、注册接口、图书检索接口、验证码接口。这里有一个容易忽略的细节拦截器放行规则用的是addPathPatterns(/**).excludePathPatterns(/api/user/login, /api/user/register)但如果你想对管理端接口比如/api/admin/**做角色校验最好在拦截器里这样处理String role claims.get(role, String.class); String uri request.getRequestURI(); if (uri.startsWith(/api/admin) !ADMIN.equals(role)) { throw new BusinessException(无权访问); }前端配合路由守卫在vue-router的beforeEach钩子里检查localStorage中的Token是否存在如果目标路由需要管理员角色而当前用户不是就跳转到403页面。这样双端校验安全性基本到位了。2.4 核心业务接口设计与实现图书管理模块的接口设计遵循RESTful风格我举几个典型接口来拆解图书模糊搜索接口GET /api/books?keyword三体category文学pageNum1pageSize10这个接口的后台逻辑用到了MyBatis的动态SQL。传入的关键字可能匹配书名、作者、ISBN中任意一项类别是可选参数。如果使用MyBatis-Plus可以封装一个LambdaQueryWrapper来处理但为了让你了解底层机制我手写了一段XML映射select idsearchBooks resultTypecom.library.entity.Book SELECT * FROM book where if testkeyword ! null and keyword ! AND (title LIKE CONCAT(%, #{keyword}, %) OR author LIKE CONCAT(%, #{keyword}, %) OR isbn LIKE CONCAT(%, #{keyword}, %)) /if if testcategory ! null and category ! AND category #{category} /if AND status ! DISCARDED /where ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} /select注意几点模糊查询的CONCAT(%, #{keyword}, %)写法可以防止SQL注入不要在Java代码里拼%到参数中再传入分页参数用offset, limit的方式在数据量不大的情况下够用如果以后图书量超过十万条建议改成pageSize传参、在SQL中用LIMIT #{pageSize} OFFSET #{offset}的形式配合覆盖索引来优化。预约借书接口POST /api/reservations这个接口要处理的事务比较多校验读者是否有未归还的图书超过3本——超过就不能再借校验所选时间段预约名额是否已满——已满返回提示校验该读者是否已经预约过同一本书——避免重复预约。三步校验全部通过之后才真正插入一条预约记录并把图书状态改为“已预约”。整个过程在Service层用Transactional注解任何一步抛出异常事务回滚不会产生脏数据。关于事务的一个经验之谈Transactional默认只回滚RuntimeException和Error如果业务方法抛的是受检异常比如Exception事务不会回滚。所以我在项目里定义了一个继承RuntimeException的BusinessException类所有业务异常都走这个类确保事务边界正确。3. 前端Vue3页面开发与前后端协作3.1 Vue3工程创建与核心依赖前端部分用Vue3vite构建Node版本要求16以上。创建工程直接用命令npm create vitelatest library-web -- --template vue为什么不用vue-cliVite的冷启动速度和热更新体验比webpack好太多开发效率完全不在一个量级。Vue3的Composition API在组织代码时比Options API更灵活尤其在做图书筛选、多条件搜索这类交互的时候把状态逻辑抽离成自定义hook复用起来特别爽。核心依赖我装了这些vue-router做路由管理pinia替代vuex做状态管理pinia更轻量而且对TypeScript支持更好axios做请求发送element-plus做后台UI组件库echarts做数据统计图表sass做样式预处理器。3.2 登录流程与令牌管理登录是整个前端的基础设施这块设计好了后面的页面开发就会顺畅很多。登录流程是这样的用户输入账号密码前端调用/api/user/login后端验证通过后返回JWT令牌和用户信息。前端拿到Token后存入localStorage同时用pinia维护一个userStore对象保存用户基本信息。Axios请求拦截器统一做令牌注入service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer ${token} } return config })响应拦截器统一做错误处理service.interceptors.response.use( response { const res response.data if (res.code 200) { return res.data } if (res.code 401) { localStorage.removeItem(token) router.push(/login) } ElMessage.error(res.message) return Promise.reject(new Error(res.message)) }, error { ElMessage.error(网络异常请稍后重试) return Promise.reject(error) } )这样的统一封装能省掉每一个页面各自处理错误逻辑的重复劳动。而且把res.data直接返回后页面里调用接口就非常简洁const bookList await getBooks({ keyword: 三体 })不需要层层解包。3.3 图书管理核心页面实现图书列表页是整个系统里最有代表性的页面它综合了表格展示、条件筛选、分页、弹窗编辑、批量操作等多个典型后台功能。我简化说明一下核心逻辑。筛选区域放了三个条件关键字输入框、分类下拉框、状态下拉框。点击“搜索”按钮时把筛选条件存入“响应式对象”触发fetchBookList函数重新拉取数据。这里有一个实战中很加分的细节使用watch监听筛选条件变化搭配debounce防抖函数让输入关键字时自动搜索不用每次点按钮。Element Plus的el-table绑定数据后分页用el-pagination组件。页码和每页条数变化时更新查询参数再重新请求。这里要注意分页组件的时间戳要绑定服务端返回的total字段不要用当前页数据长度否则翻页时总页数会算错。编辑弹窗用el-dialog内嵌el-form表单校验规则用Element Plus的rules属性配置。提交时先调用formRef.validate()做前端校验通过后再调更新接口。整个流程下来页面代码会自然地组织成“搜索区域-表格区域-分页区域-弹窗区域”四块结构清晰后续别人接手也容易理解。3.4 前后端联调与跨域配置跨域问题可以说是前后端分离项目里最经典的“坑”了。前端跑在http://localhost:5173后端跑在http://localhost:8080两者端口不同浏览器默认会拦截跨域请求。解决方式有两种方案。第一种在后端配置CORSConfiguration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }第二种是前端配置Vite代理// vite.config.js server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }两种方案各有优劣。在开发阶段用Vite代理更方便因为浏览器看到的请求是同源的不会触发预检请求OPTIONS请求效率更高部署到生产环境后一般用Nginx做反向代理把/api前缀转发到后端服务。如果选择后端CORS方案注意allowedOriginPatterns(*)不能和allowCredentials(true)同时使用的坑——这是SpringBoot的规范限制某些版本的SpringBoot会直接报错。如果你一定要携带Cookie就明确指定允许的来源域不要使用通配符。联调时我给自己的一个要求是前端不要写死任何假数据来等后端后端也不要为了赶进度把接口返回结构随意调整。前端Mock数据可以在后端接口未完成时用来开发调试但联调时必须切换到真实接口用统一的接口文档我比较推荐Apifox来约束参数和返回体结构。4. 数据库设计与MyBatis实践4.1 核心表结构与关系设计数据库设计是这套系统的地基我用了8张核心表来支撑整个业务流程user表用户表包含id、username、passwordBCrypt加密后存储、name、phone、role、status字段。role区分ADMIN和READER。book表图书表包含id、title、author、publisher、isbn、category、total_count、available_count、status、location字段。available_count代表当前可借数量status代表图书整体状态。book_category表图书分类表id、category_name、description字段。分类独立成表是为了方便日后扩展分类层级。reservation表预约记录表id、user_id、book_id、appointment_date、time_slot、status、create_time字段。status区分PENDING、CONFIRMED、CANCELLED、COMPLETED。borrow_record表借阅记录表id、user_id、book_id、borrow_time、due_time、return_time、status字段。每一条借阅行为都在这里留痕。fine_record表逾期罚款记录表id、borrow_id、user_id、fine_amount、is_paid、create_time字段。逾期费用的计算逻辑是超过应还日期后每本每天0.1元。notice表公告表id、title、content、publish_time、publisher_id字段。管理员发布的限流通知、开闭馆通知都在这张表里。system_log表操作日志表id、user_id、operation、detail、ip、create_time字段。关键操作的审计追踪全靠它。借阅记录表和图书表是多对一关系借阅记录表和用户表是多对一关系预约记录表是用户和图书之间的多对多关联关系的体现。用户和图书没有直接做多对多映射表而是通过borrow_record这张事实表来建立关联这种设计更适合记录每次借阅的细节。MySQL引擎统一用InnoDB字符集utf8mb4排序规则utf8mb4_general_ci。utf8mb4不是可选项是必须项因为utf8在MySQL里只能存3字节的字符遇到emoji表情就会报错虽然图书管理系统里不太可能出现emoji但这是规范问题必须从一开始就做到位。4.2 MyBatis动态SQL在复杂查询中的作用MyBatis是这个项目的持久层框架我用了MyBatis-Plus作为增强工具。QueryWrapper和LambdaQueryWrapper能覆盖80%的单表查询需求但遇到多表关联或复杂条件时还是需要手写XML。举一个实际例子管理端的“图书借阅排行”报表需要按图书维度统计借阅次数关联borrow_record表和book表并按借阅次数降序排列。这段SQL手写如下select idselectBorrowRanking resultTypemap SELECT b.id, b.title, b.author, COUNT(br.id) AS borrow_count FROM book b LEFT JOIN borrow_record br ON b.id br.book_id AND br.status ! CANCELLED where if teststartDate ! null AND br.borrow_time gt; #{startDate} /if if testendDate ! null AND br.borrow_time lt; #{endDate} /if /where GROUP BY b.id, b.title, b.author ORDER BY borrow_count DESC LIMIT #{limit} /select这里有两个细节值得注意。第一LEFT JOIN后追加的条件br.status ! CANCELLED必须放在ON子句里如果放到WHERE里就变成内连接了统计结果会错。第二gt;和lt;是XML中大于等于、小于等于的正确写法直接写会解析报错。这两个都是很隐蔽的坑我第一次写就踩过。MyBatis缓存这块项目默认用了二级缓存。你可能会问“mybatis缓存”这个东西要怎么配置才合理我的回答是在图书管理这种读多写少的场景下一级缓存和二级缓存可以开启但要注意缓存的失效策略。如果某本图书的库存被借出后减少了而缓存里还存着旧的库存数查询就会出错。所以在执行INSERT、UPDATE、DELETE操作后明确调用缓存刷新CacheEvict(value bookCache, allEntries true) public void updateBook(Book book) { bookMapper.updateById(book); }使用Spring的CacheEvict注解比MyBatis自带的缓存刷新更可控也更容易在面试时讲清楚。4.3 MySQL数据库安装与配置要点很多同学在环境准备阶段就被MySQL安装绊住了。MySQL 8.0是目前使用最广泛的版本安装时有几个关键点一定要处理好。Windows下安装MySQL 8.0去官网下载MySQL Installer选择Server only即可。安装过程中会让你设置root用户密码建议设置一个你确定记得住的密码比如root123456后面连接字符串里要用到。安装完成后最重要的一件事是确认MySQL服务是否已经启动可以通过Windows服务管理器查看“MySQL80”这个服务的状态也可以命令行执行mysql -u root -p输入密码后能进入mysql提示符就说明安装成功。配置方面my.ini文件里建议设置如下参数[mysqld] character-set-serverutf8mb4 collation-serverutf8mb4_general_ci max_connections200 default-storage-engineINNODB还有一点容易被忽略MySQL 8.0默认的认证插件是caching_sha2_password而SpringBoot的mysql-connector-java 8.x版本对此完全兼容不需要额外处理。但如果你用的驱动版本是5.x就会报“Public Key Retrieval is not allowed”的错误。解决方案是升级驱动到8.x或是在jdbc连接串上加上allowPublicKeyRetrievaltrueuseSSLfalse。这个坑在网络上的提问频率极高提前讲清楚能帮你省下半个小时的排查时间。数据库连接池我用了HikariCP这是SpringBoot 2.x之后默认集成的连接池性能比Druid在纯读写场景下略好。配置如下spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/library_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root123456 hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 300004.4 图书借还状态流转的SQL实现图书借还流程是整个系统事务最密集的部分。借书事务包含两步在borrow_record表插入一条借阅记录status设置为BORROWED同时执行一条更新语句让book表的available_count减1并且当available_count变为0时把status改为“借出”。这两步必须放在同一个事务里。我用的是在Service层加Transactional(rollbackFor Exception.class)确保原子性。一个在实际开发中很关键的优化点更新库存时不要先查再改而是用一条乐观锁式的更新语句UPDATE book SET available_count available_count - 1 WHERE id #{bookId} AND available_count 0这条语句返回的影响行数是1说明扣减成功返回0说明库存已经被扣到0了。这样可以避免并发场景下的超卖问题——也就是两个读者同时借同一本书的最后一本结果两个人都认为借成功了。说白了这就是数据库层面的乐观锁思想面试官很喜欢问这个场景的解决方案。还书事务对称处理更新borrow_record状态为RETURNED填写return_time字段同时让book表的available_count加1。如果还书时间超过due_time则根据逾期天数计算罚款金额并写入fine_record表。这里逾期天数的计算放在Java代码里完成不依赖数据库函数便于做单元测试。5. 常见问题与排查技巧实录5.1 环境配置阶段的经典问题问题1SpringBoot项目启动报错“Failed to configure a DataSource”这个错误90%的情况是application.yml文件里的数据源配置没有生效。常见原因有两个一是配置文件名字写错SpringBoot默认加载的是application.yml或application.properties如果你创建的是application-dev.yml但没有在application.yml里激活该profile配置就不会加载二是yml文件的缩进格式错误SpringBoot的配置解析对缩进非常敏感少一个空格就会导致整个配置失效。排查技巧在启动类上加SpringBootApplication后可以先写一个简单的测试接口不连接数据库单独测试Web层是否正常。如果Web层没问题再逐步引入数据源配置这样可以快速定位是配置问题还是代码问题。问题2Vue3安装依赖时提示“npm ERR! ERESOLVE unable to resolve dependency tree”这个问题大多是依赖版本冲突导致的。解决方案有两种其一在安装命令后面加--legacy-peer-deps参数跳过节点头校验其二升级npm版本到7以上的同时手动拉齐Vue3生态核心包的版本。实际项目中我推荐第二种因为第一种虽然能装成功但隐藏的版本冲突日后可能会引发运行时错误。问题3IDEA中运行SpringBoot时控制台中文乱码在Settings - Editor - File Encodings里把Global Encoding、Project Encoding、Properties Files三项都改为UTF-8。同时在启动配置的VM options里加一句-Dfile.encodingUTF-8。这两步做完再重启基本能解决90%的乱码问题。5.2 前后端联调阶段的报错排查问题4前端请求接口返回404先确认后端服务是否启动成功再检查请求路径是否匹配。比如后端Controller里定义的映射是RequestMapping(/api/books)前端请求的URL就必须是/api/books。这里有一个很容易忽略的点如果使用了Vite代理代理配置里的/api前缀转发规则如果是target path而后端也是以/api开头的路径那么最终请求路径是正确的但如果后端Controller的路径没有加/api前缀只是/books那么代理配置就需要做路径重写。这个规则理不清就很容易出现404。问题5前端请求报403 Forbidden大部分情况是跨域预检请求OPTIONS没有被后端拦截器放行。我拦截器里通常这样处理if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; }在preHandle方法开头直接放行OPTIONS请求然后再做JWT校验能有效避免跨域场景下的403问题。问题6MyBatis报“Invalid bound statement (not found)”这个错误99%是Mapper接口和XML文件没有绑定成功。检查以下几点XML文件的namespace是否和Mapper接口的完整类名一致XML文件中select标签的id是否和Mapper接口方法名一致XML文件是否放在resources目录下的正确包路径如果用了MyBatis-Plus检查application.yml中是否有指定mapper-locations配置。mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml5.3 上线部署阶段的运维经验这套系统我最终是部署在一台2核4G的云服务器上的配置不算高但应付图书馆这种量级的并发完全够用。部署架构很简单Nginx做前端静态资源的托管和反向代理后端以jar包形式通过systemd守护运行MySQL和Redis直接装在服务器上。前后端分离的生产部署方式有几个要点值得记一下前端构建前需要把代码里的API请求地址环境变量化。我在项目根目录建了.env.production文件里面写VITE_API_BASE_URL/api在Vite配置中用envPrefix来识别。构建命令执行npm run build构建产物在dist目录把dist目录里所有文件上传到服务器的/var/www/library目录。Nginx配置最关键的部分就是两个静态文件路径和代理转发。完整的最小配置如下server { listen 80; server_name your-domain.com; root /var/www/library; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }注意try_files $uri $uri/ /index.html;这一行必须加上否则前端路由使用的history模式在刷新页面时会404。这也是很多新手部署完访问首页没问题但一刷新子页面就报错的原因。后端jar包的systemd服务配置如下[Unit] DescriptionLibrary Management System Afternetwork.target [Service] Userroot WorkingDirectory/opt/library ExecStart/usr/local/java/bin/java -Xms512m -Xmx1024m -jar /opt/library/library-server.jar SuccessExitStatus143 Restartalways RestartSec10 [Install] WantedBymulti-user.targetSuccessExitStatus143这个配置很关键因为在systemd停止Java进程时JVM收到SIGTERM信号会以143退出如果不声明这个为正常退出码systemd会认为服务异常终止并触发重启导致你明明执行了systemctl stop服务又很快自己拉起来了。上线后进行压测时我观察到这个配置下的QPS大约能到800左右图书查询接口在1000并发时响应时间仍然在80ms以内。MySQL的慢查询日志配置打开后我发现高频的模糊搜索接口因为LIKE %keyword%无法走索引查询耗时偏高。优化方案是引入全文索引但对目前的业务量来说并不算特别紧迫的需求。5.4 面试中经常被问到的问题基于这个项目面试官最爱问的问题集中在以下几个方面提前准备好回答思路面试时会自信很多。第一个问题为什么选择SpringBootVue3这套技术栈回答思路可以从“生态成熟度”和“开发效率”两个维度展开。SpringBoot简化了Spring的配置复杂度约定大于配置的理念让项目从零到可运行只需要几分钟Vue3的Composition API让组件逻辑复用变得简单而且TypeScript支持越来越好适合中大型前端项目。再补充一点这两个框架学习曲线相对平缓社区资源丰富遇到问题能快速找到解决方案。第二个问题项目的权限控制是怎么实现的这个问题答得好不好直接体现你是否有实践经验。先讲后端拦截器校验JWT令牌中的角色信息再讲前端路由守卫配合做页面级控制最后强调业务接口层面的二次校验。如果面试官继续追问“如果有一个普通读者绕过前端直接调管理员接口怎么办”你就可以底气十足地回答后端拦截器会对/api/admin/**路径做角色校验非ADMIN角色直接返回401。这个环节是展示你对前后端分离安全模型理解深度的大好机会。第三个问题高并发场景下怎么保证图书库存不超卖我在这篇博文前面已经详细讲过解决方案通过数据库层面的乐观锁在更新时用WHERE available_count 0条件判断而不是先查询再更新。如果面试官继续问“那如果请求量更大怎么办”可以提一下Redis分布式锁或者ZooKeeper实现分布式锁的方案顺便拿出项目里的预约限流逻辑作为实践支撑面试官会认为你是真的做过并发控制而不是只背过八股文。第四个问题项目里有没有用过索引怎么设计索引这个项目的高频查询场景是图书模糊搜索和借阅记录查询。我针对这两个场景做了索引优化图书表的title、author字段加普通索引因为模糊查询LIKE keyword%可以走索引借阅记录表的user_id加索引方便按用户维度查询历史记录borrow_time字段加索引支持按时间范围查询报表。但要注意索引不是越多越好——索引会占用存储空间还会拖慢INSERT/UPDATE/DELETE的性能需要在读写之间找一个平衡点。6. 项目扩展与个人经验总结这套系统如果只是停留在课程设计或结业作业的层面那确实有些浪费了。我在实际开发完之后又给它加了不少扩展功能这里顺便做个分享。第一个扩展是引入Redis做验证码存储和高频访问控制。登录接口增加验证码校验验证码的值存储在Redis中有效时间5分钟。同时利用Redis做接口频控同一个IP在1分钟内最多只能请求10次登录接口超过就拒绝。这个功能虽然不算复杂但让系统的健壮性提升了一个档次也让我在后来的面试中多了一个可以谈的技术亮点。第二个扩展是图书推荐功能。我在“借阅排行”基础上根据读者历史借阅记录中的分类分布做一个简单的协同过滤推荐——把高频分类的未读图书优先展示在首页。这个功能用SQL就能计算不需要专门引入推荐算法框架但对用户体验的提升很明显。第三个建议是补一套完整的单元测试。我当时给核心的借阅服务写出了覆盖全部业务分支的JUnit测试用例把超期罚金计算、预约冲突检测这些容易出错的逻辑跑得明明白白。这部分工作看似增加工作量但后续做功能变更时带给我的信心是无可替代的——改完代码跑一遍测试如果全绿就可以放心提交了。最后说一点个人体会。我从搭建这套系统的过程中最深的感觉是技术本身并不难难的是把每个模块之间的耦合关系理清楚。一开始我也踩过不少坑比如前端的接口请求路径和后端RestController的路径没对齐导致联调时浪费了大半天再比如图书状态流转时一开始没设计状态机导致某处逻辑分支遗漏直到测试用例跑出异常才修补完整。这些经历让我明白了架构设计的前置思考有多重要——你现在偷懒没有定义清楚的状态和边界后面一定会花更多时间来修补。如果你也在做类似的图书馆管理系统或者正在犹豫自己的毕设课题我的建议是先把业务流程图画清楚把数据表设计好再动手写代码。好的数据库设计能承载业务的扩展需求好的接口设计能减少前后端扯皮好的代码结构能支撑后来的维护者顺畅接手。技术圈里有一句老话叫“先跑起来再优化”但对于一个管理系统类项目我更愿意说“先想明白再做出来”。希望这篇博客的分享能帮你少走一些弯路顺利把项目做出来。
