企业官网建设流程全解析

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> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-impl</artifactId> <version>0.11.5</version> <scope>runtime</scope> </dependency>

2.2 统一返回结果与全局异常处理

接口返回格式统一这件事，看起来是小事，实际对前后端联调的效率影响非常大。我见过太多项目，一个接口返回{code:200, data:{...}}，另一个接口又直接返回裸数据，前端每次都要针对不同接口写不同的解析逻辑，维护成本极高。

这套系统定义了一个统一的Result<T>类：

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.setCode(code); result.setMessage(message); return result; } }

有了这个基础之后，全局异常处理就顺理成章了。用@RestControllerAdvice注解拦截所有Controller层抛出的异常，业务异常（比如预约已满、图书不存在）统一返回code=500，参数校验失败返回code=400，未登录或Token过期返回code=401。前端Axios封装里只需要判断code字段，code===200就走成功逻辑，否则弹出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=文学&pageNum=1&pageSize=10

这个接口的后台逻辑用到了MyBatis的动态SQL。传入的关键字可能匹配书名、作者、ISBN中任意一项，类别是可选参数。如果使用MyBatis-Plus，可以封装一个LambdaQueryWrapper来处理；但为了让你了解底层机制，我手写了一段XML映射：

<select id="searchBooks" resultType="com.library.entity.Book"> SELECT * FROM book <where> <if test="keyword != null and keyword != ''"> AND (title LIKE CONCAT('%', #{keyword}, '%') OR author LIKE CONCAT('%', #{keyword}, '%') OR isbn LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="category != 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工程创建与核心依赖

前端部分用Vue3+vite构建，Node版本要求16以上。创建工程直接用命令：

npm create vite@latest library-web -- --template vue

为什么不用vue-cli？Vite的冷启动速度和热更新体验比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，两者端口不同，浏览器默认会拦截跨域请求。

解决方式有两种方案。第一种在后端配置CORS：

@Configuration 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、password（BCrypt加密后存储）、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 id="selectBorrowRanking" resultType="map"> 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 test="startDate != null"> AND br.borrow_time &gt;= #{startDate} </if> <if test="endDate != 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里就变成内连接了，统计结果会错。第二，>=和<=是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-server=utf8mb4 collation-server=utf8mb4_general_ci max_connections=200 default-storage-engine=INNODB

还有一点容易被忽略：MySQL 8.0默认的认证插件是caching_sha2_password，而SpringBoot的mysql-connector-java 8.x版本对此完全兼容，不需要额外处理。但如果你用的驱动版本是5.x，就会报“Public Key Retrieval is not allowed”的错误。解决方案是升级驱动到8.x，或是在jdbc连接串上加上allowPublicKeyRetrieval=true&useSSL=false。这个坑在网络上的提问频率极高，提前讲清楚能帮你省下半个小时的排查时间。

数据库连接池我用了HikariCP，这是SpringBoot 2.x之后默认集成的连接池，性能比Druid在纯读写场景下略好。配置如下：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/library_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: root123456 hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000

4.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 环境配置阶段的经典问题

问题1：SpringBoot项目启动报错“Failed to configure a DataSource”

这个错误90%的情况是application.yml文件里的数据源配置没有生效。常见原因有两个：一是配置文件名字写错，SpringBoot默认加载的是application.yml或application.properties，如果你创建的是application-dev.yml但没有在application.yml里激活该profile，配置就不会加载；二是yml文件的缩进格式错误，SpringBoot的配置解析对缩进非常敏感，少一个空格就会导致整个配置失效。

排查技巧：在启动类上加@SpringBootApplication后，可以先写一个简单的测试接口，不连接数据库单独测试Web层是否正常。如果Web层没问题，再逐步引入数据源配置，这样可以快速定位是配置问题还是代码问题。

问题2：Vue3安装依赖时提示“npm ERR! ERESOLVE unable to resolve dependency tree”

这个问题大多是依赖版本冲突导致的。解决方案有两种：其一在安装命令后面加--legacy-peer-deps参数，跳过节点头校验；其二升级npm版本到7以上的同时，手动拉齐Vue3生态核心包的版本。实际项目中我推荐第二种，因为第一种虽然能装成功，但隐藏的版本冲突日后可能会引发运行时错误。

问题3：IDEA中运行SpringBoot时控制台中文乱码

在Settings -> Editor -> File Encodings里把Global Encoding、Project Encoding、Properties Files三项都改为UTF-8。同时，在启动配置的VM options里加一句-Dfile.encoding=UTF-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问题。

问题6：MyBatis报“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/**/*.xml

5.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] Description=Library Management System After=network.target [Service] User=root WorkingDirectory=/opt/library ExecStart=/usr/local/java/bin/java -Xms512m -Xmx1024m -jar /opt/library/library-server.jar SuccessExitStatus=143 Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

SuccessExitStatus=143这个配置很关键，因为在systemd停止Java进程时，JVM收到SIGTERM信号会以143退出，如果不声明这个为正常退出码，systemd会认为服务异常终止并触发重启，导致你明明执行了systemctl stop，服务又很快自己拉起来了。

上线后进行压测时我观察到，这个配置下的QPS大约能到800左右，图书查询接口在1000并发时响应时间仍然在80ms以内。MySQL的慢查询日志配置打开后，我发现高频的模糊搜索接口因为LIKE '%keyword%'无法走索引，查询耗时偏高。优化方案是引入全文索引，但对目前的业务量来说，并不算特别紧迫的需求。

5.4 面试中经常被问到的问题

基于这个项目，面试官最爱问的问题集中在以下几个方面，提前准备好回答思路，面试时会自信很多。

第一个问题：为什么选择SpringBoot+Vue3这套技术栈？

回答思路可以从“生态成熟度”和“开发效率”两个维度展开。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的路径没对齐，导致联调时浪费了大半天；再比如图书状态流转时一开始没设计状态机，导致某处逻辑分支遗漏，直到测试用例跑出异常才修补完整。这些经历让我明白了架构设计的前置思考有多重要——你现在偷懒没有定义清楚的状态和边界，后面一定会花更多时间来修补。

如果你也在做类似的图书馆管理系统，或者正在犹豫自己的毕设课题，我的建议是先把业务流程图画清楚，把数据表设计好，再动手写代码。好的数据库设计能承载业务的扩展需求，好的接口设计能减少前后端扯皮，好的代码结构能支撑后来的维护者顺畅接手。技术圈里有一句老话叫“先跑起来再优化”，但对于一个管理系统类项目，我更愿意说“先想明白再做出来”。希望这篇博客的分享能帮你少走一些弯路，顺利把项目做出来。