图书管理系统开发实战：从SpringBoot表设计到部署上线全流程

一个东西能把管理员、读者、图书、借归还这几件事说清楚，还能在这个基础上扩展出预约、统计分析、导入导出功能，那它就是图书管理系统。这类项目几乎每年都出现在毕业设计和课程设计的备选列表里，2026年这个选题依然热门。原因很简单：业务模型足够经典，技术栈足够主流，做成什么样都有话可说。

我用SpringBoot + MyBatis-Plus + MySQL这套组合做过一个完整版本，前端用的Vue3 + Element Plus，前后端分开部署。如果你正准备做类似的课题，或者只是想把“管理系统”这类项目彻底吃透，这篇文章把我从需求分析、表设计、后端接口，到权限控制、部署上线的整个过程和踩过的坑都整理出来了。不管你是要直接参考复现，还是想找做系统设计的思路，都值得花几分钟看完。

1. 项目定位与整体方案拆解

1.1 图书管理系统的核心需求是什么

别看图书管理系统叫起来很简单，它本质上是一个“多角色 + 核心业务流 + 数据管理”的综合型系统。拆成业务语言来说，就三件事：

第一，图书的增删改查和分类管理。这对应的是一个常规的CRUD模块，但要注意它不仅仅是单表操作，还涉及到图书封面、ISBN、库存数量、架位号、价格、出版社等字段，属于典型的信息管理场景。

第二，读者和借还书业务流程。这是整个系统最重要的部分，也是评委老师最爱问的部分。借书不是简单往表里插一条记录，它至少要干三件事：检查这本书还有没有库存、判断当前读者有没有借阅上限或者未还图书、扣减图书库存并生成借阅记录；还书则是反向操作，更新借阅状态、释放库存，同时可能涉及到逾期计算。

第三，管理员和读者两种角色的权限区分。管理员能管理图书、管理用户、查看所有借阅记录；读者只能浏览图书、借书、还书、查看自己的借阅历史。权限控制做得好不好，直接决定了系统架构的层次。

如果你把这三部分做扎实，整个系统的主体就已经完成。预约、线上续借、图书评论、数据统计这些，属于锦上添花的功能，可以在主体完成之后再往里面加。

1.2 为什么用SpringBoot而不是SSH或者Servlet

现在做管理系统，技术选型基本不用纠结，SpringBoot就是最适合的答案。原因很简单：

SpringBoot把Spring繁琐的配置大量自动化了。以前用Spring + SpringMVC做项目，光一个XML配置文件就够研究一两天，现在一个@SpringBootApplication注解就能把项目跑起来。它内置了Tomcat，打成Jar包直接运行，不需要额外配置外部容器。对我们的课题来说，省下来的时间可以花在业务逻辑上，而不是环境搭建上。

持久层我推荐MyBatis-Plus。传统的MyBatis需要手写大量SQL，XML配置也繁琐，而MyBatis-Plus在保留MyBatis灵活性的基础上，提供了内置的通用Mapper和条件构造器，单表CRUD基本不用写SQL，代码量可以压缩三分之一左右。最关键的是，你用MyBatis-Plus写出来的代码，答辩时特别好解释：哪一段是框架自动生成的，哪一段是你自己写的业务SQL，一目了然。

数据库用MySQL 8.0，这也是当前最主流的选择。缓存可以选Redis做登录态的存储或热门图书数据的缓存，但如果是入门版本的毕业设计，先不加Redis也完全没问题，把核心借还流程跑通更重要。

下面是我当时的技术栈表格，可以直接参考：

这里提醒一句：如果你之前没接触过Spring Security，第一次整合比如登录认证、JWT生成、拦截器这些会有一点绕。不过现在的图书管理系统大家基本都用这套方案，网上的成熟案例非常多，照着走一遍流程，原理就清楚了。

1.3 功能模块划分与优先级排序

我把系统拆成下面几个模块，按优先级从高到低排列：

• 用户模块：登录、注册、退出，管理员和读者两种角色。
• 图书模块：图书列表查询、条件检索、新增图书、编辑图书、删除图书、图书分类管理。
• 借阅模块：借书、还书、借阅记录查询、我的借阅列表。
• 数据看板：首页统计图书总量、在借数量、读者总数、逾期数量；用ECharts画一个最近半年的借阅趋势图。
• 扩展功能：图书封面上传、Excel批量导入图书、逾期账单统计。

模块规划阶段最容易犯的错误是一开始就把所有功能都铺开，结果数据库表设计得越来越大，开发到一半发现时间不够用。我的建议是：第一版只做登录、图书管理、借还书这三块，把主流程跑通之后，再按剩余时间逐项添加扩展功能。

2. 数据库设计：整个系统的地基

2.1 五张核心表搞定业务模型

图书管理系统虽然功能多，但核心数据模型其实很清晰。我最终采用了五张核心表加一张可选扩展表的设计方案：

第一张是用户表，字段包括主键ID、用户名、密码、真实姓名、联系电话、邮箱、角色、状态和创建时间。用户名要做唯一约束，密码字段不要存明文，存BCrypt加密后的密文。角色字段用一个小整数存，0表示管理员，1表示普通读者，避免直接用字符串导致数据冗余。

第二张是图书分类表，字段包括分类ID、分类名称、排序号、状态。分类表虽然简单，但一定要独立出来。如果你把分类名称直接写在图书表里，后期改分类名就要批量更新所有图书，而且没法统计每个分类的图书数量。

第三张是图书表，字段包括主键、图书名称、ISBN、作者、出版社、分类ID、价格、库存总量、当前可借数量、架位号、封面图URL、简介、状态（上架/下架）、创建时间和更新时间。有几个容易被忽略的细节：ISBN最好单独加一个唯一索引，因为同一本书的ISBN是唯一的；库存总量和可借数量要分开存，一个是入藏量，一个是当前剩余量，不要用同一个字段。

第四张是借阅记录表，字段包括主键、用户ID、图书ID、借书时间、应还时间、实际归还时间、借阅状态、是否续借。这张表是整个系统的核心，后续的逾期计算、历史记录、统计分析全部依赖它。

第五张是操作日志表，记录谁在什么时间做了什么操作，比如“用户张三借走了《SpringBoot实战》”。日志表对毕业答辩很有用，可以展示你的系统具备可追溯性。

如果扩展预约功能，可以再加一张预约表，包含预约人、图书ID、预约时间、预约状态这几个字段。不过这是二期需求，不建议第一版就做进去。

2.2 借阅记录的SQL设计与状态机管理

图书表、用户表、借阅记录表三者之间是经典的多对多关系，借阅记录表就是中间表，但它不是普通的关联表，它带状态、时间和业务规则，所以又被称为“有业务含义的关联实体”。表结构可以这样建：

CREATE TABLE borrow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', user_id BIGINT NOT NULL COMMENT '用户ID', book_id BIGINT NOT NULL COMMENT '图书ID', borrow_time DATETIME NOT NULL COMMENT '借书时间', due_time DATETIME NOT NULL COMMENT '应还时间', return_time DATETIME DEFAULT NULL COMMENT '实际归还时间', status TINYINT NOT NULL DEFAULT 1 COMMENT '1借阅中 2已归还 3已逾期归还', renew_count TINYINT NOT NULL DEFAULT 0 COMMENT '续借次数', create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, KEY idx_user_id (user_id), KEY idx_book_id (book_id), KEY idx_status (status) ) COMMENT='借阅记录表';

这里有两个设计要点值得展开。第一个是status字段要定义清楚状态流转：借书时插入记录，status=1；正常还书，status=2；如果读者在应还日期之后才还书，status=3，同时可以在业务层另外计算逾期天数。不要用字符串去存状态，更不要用中文存“已借出”“已归还”。整型状态配上注释文档，写代码时用状态常量类或枚举类去引用，既节省存储又避免脏数据。

第二个是索引设计。user_id和book_id必须建索引，因为“查某个人借了哪些书”“查某本书被谁借着”这两个查询会高频出现。如果没有索引，等借阅记录表数据量到了几万条，全表扫描就会明显变慢。status字段也建议加索引，因为后台经常要按状态筛选列表。due_time如果后续要做“逾期自动标记”的定时任务，加索引也会有帮助。

2.3 初始化数据怎么准备

数据库初始化这块，不同的持久层框架玩法不一样。如果你用JPA，SpringBoot可以直接配置数据库自动建表，但用MyBatis-Plus没有这个能力。那MyBatis-Plus项目里“表不存在自动建表”是怎么实现的？常见有三种方案，我按适用程度排序：

第一种是直接用数据库客户端执行SQL脚本。在项目resources目录下放一个init.sql，把所有建表语句和初始数据（比如预设管理员账号、分类数据）写好，本地开发时手动执行一次，或者通过连接数据库的命令执行。这种方式最直观，也最容易控制，毕业设计完全够用。

第二种是使用SpringBoot的spring.sql.init配置，在application.yml里配置schema.sql和data.sql让容器启动时自动执行。这个方案有一个坑：SpringBoot 2.5以上版本默认只对嵌入式数据库执行初始化脚本，对MySQL需要用spring.sql.init.mode=always强制开启。另外如果脚本里写了CREATE TABLE IF NOT EXISTS，重启项目时不会有问题，但也要小心重复执行脚本导致主键冲突或重复数据。

第三种是使用Flyway或Liquibase做版本化迁移。这是企业级项目的标准做法，脚本会带上版本号如V1__init.sql、V2__add_table.sql，Flyway自动记录哪些版本执行过。好处是团队协作或多环境部署时特别安全，坏处是学习成本高一点，对课题来说略有一种“杀鸡用牛刀”的感觉。

我建议直接用第一种加第二种结合：开发阶段手动执行一次init.sql，等要部署到服务器或者演示环境时，再把spring.sql.init配置打开，保证新环境启动后自动就有表和数据。这样既有控制力，又省去了手动重复配置的麻烦。

3. 后端代码结构：如何写出好讲好维护的工程

3.1 包结构与分层设计

管理系统的后端代码不建议全堆在一个Controller里。一个好的分包结构，不仅方便自身开发，答辩讲解时也显得有条理。你可以参考下面这个标准布局：

com.example.library ├── common │ ├── Result.java // 统一返回结果 │ ├── PageResult.java // 分页统一返回 │ └── GlobalExceptionHandler.java // 全局异常处理 ├── config │ ├── MybatisPlusConfig.java // 分页插件配置 │ ├── WebMvcConfig.java // 拦截器与静态资源配置 │ └── JwtInterceptor.java // JWT过滤器/拦截器 ├── controller │ ├── BookController.java │ ├── BorrowRecordController.java │ ├── UserController.java │ └── DashboardController.java ├── service │ ├── BookService.java │ ├── BorrowRecordService.java │ └── impl │ ├── BookServiceImpl.java │ └── BorrowRecordServiceImpl.java ├── mapper │ ├── BookMapper.java │ ├── BorrowRecordMapper.java │ └── UserMapper.java ├── entity │ ├── Book.java │ ├── User.java │ └── BorrowRecord.java ├── dto │ ├── LoginDTO.java │ ├── BorrowDTO.java │ └── BookQueryDTO.java └── vo ├── BookVO.java └── BorrowRecordVO.java

从Controller到Service到Mapper，每一层职责要清晰。Controller只做参数接收和结果封装，Service做业务逻辑，Mapper做数据库交互。你要想清楚每个方法的意图。

实体类entity对应数据库表结构，dto是接收前端参数的封装对象，vo是返回给前端的数据封装。三者不要混用。比如前端登录传过来的是用户名、密码，你用一个LoginDTO接收，返回给前端的是用户基本信息加Token，再用一个LoginVO封装，这样不同阶段的数据就清楚地分开了。

实体类字段推荐用Lombok的@Data注解来减少冗长的GetSet方法，代码量能少一大截。不过要注意一个问题：Lombok和JDK版本存在兼容性，如果你用JDK 21而Lombok版本太老，编译会直接报错。我当时就踩了Lombok版本和JDK不匹配的坑，最后把Lombok升级到最新版本才编译通过。

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

写接口的时候，一定要设计一套统一的返回格式，否则前后端联调会被各种乱七八糟的返回结构折磨到崩溃。我的做法是定义一个Result<T>通用返回类：

@Data public class Result<T> { private Integer code; // 1成功 0业务失败 500系统异常 private String message; // 提示信息 private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(1); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(0); result.setMessage(message); return result; } }

接口返回值统一是Result，前端只看code判断成功失败，只取data渲染数据。这样不管后面加多少接口，前端封装的request工具一次写完，后续接口全是复制粘贴。

GlobalExceptionHandler也非常关键。如果不做全局异常处理，数据库抛一个异常就直接返回一大段英文堆栈信息给前端，观感非常差。用@RestControllerAdvice配合@ExceptionHandler统一捕获业务异常和未知异常，业务上主动抛一个自定义的BusinessException，全局处理器统一返回友好提示，这样日常开发每个接口都不用写Try-Catch。

这部分是答辩时最容易被加分的地方，后面可以在PPT里单独写一页“系统统一异常处理机制”，这也是企业开发的标准做法。

3.3 图书模块的核心接口实现

图书模块本质是一张表的CRUD，直接使用MyBatis-Plus的核心方法。相关的分页查询是最常用的一个接口。我推荐用MyBatis-Plus的分页插件，首先在配置类里注册拦截器：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

然后在Service层调：

public PageResult<BookVO> getBookList(BookQueryDTO query) { Page<Book> page = new Page<>(query.getPageNum(), query.getPageSize()); LambdaQueryWrapper<Book> wrapper = new LambdaQueryWrapper<>(); // 条件拼接 wrapper.like(StringUtils.hasText(query.getBookName()), Book::getBookName, query.getBookName()) .eq(query.getCategoryId() != null, Book::getCategoryId, query.getCategoryId()) .eq(query.getStatus() != null, Book::getStatus, query.getStatus()) .orderByDesc(Book::getCreateTime); Page<Book> result = bookMapper.selectPage(page, wrapper); // 再转成VO，补充分类名称等联动信息 return PageResult.of(result); }

这里一个实用的小技巧是：条件构造成员用LambdaQueryWrapper而不是普通的QueryWrapper。LambdaQueryWrapper通过方法引用Book::getBookName指向字段，不怕前端传参把数据库里没有的字段塞进来导致运行报错。字段名重构的时候IDE也会联动提醒，不会出现“改了一个字段名忘了改对应字符串”的低级错误。

图书删除也要单独说一句。如果系统里已经存在这本书的借阅记录，直接执行物理删除会造成借阅记录表里的外键孤立。所以图书删除要做一个前置检查：查一下borrow_record表里有没有这本书且状态为借阅中的记录。如果有，要么提示“有未归还记录，无法删除”，要么把图书标记为“已下架”，这也是真实业务系统中通用的处理方式。侧面体现出你对业务完整性有考虑。

3.4 借书和还书的业务逻辑设计

借书和还书是管理系统里面最有技术含量的地方，也是你回答“项目难点”时最该准备的部分。

借书整个流程可以划分成四步：校验读者状态、校验图书是否存在且可借、扣减库存、生成借阅记录。前面两步是条件判断，后面两步是数据变更。伪代码逻辑是这样的：

@Transactional(rollbackFor = Exception.class) public void borrowBook(BorrowDTO dto) { // 1. 校验读者 User user = userMapper.selectById(dto.getUserId()); if (user == null || user.getStatus() == 0) { throw new BusinessException("读者不存在或已被禁用"); } // 2. 检查图书 Book book = bookMapper.selectById(dto.getBookId()); if (book == null || book.getStatus() == 0) { throw new BusinessException("图书不存在或已下架"); } if (book.getRemaining() <= 0) { throw new BusinessException("图书库存不足"); } // 3. 扣减库存并更新 book.setRemaining(book.getRemaining() - 1); bookMapper.updateById(book); // 4. 生成借阅记录 BorrowRecord record = new BorrowRecord(); record.setUserId(dto.getUserId()); record.setBookId(dto.getBookId()); record.setBorrowTime(LocalDateTime.now()); // 默认借阅周期30天，可做成系统参数 record.setDueTime(LocalDateTime.now().plusDays(30)); record.setStatus(1); borrowRecordMapper.insert(record); }

这个方法上必须加@Transactional注解，否则等第四步插记录成功、第三步更新库存失败的时候，数据库就出现了“库存没减但借阅记录存在”的脏数据。借阅周期比如30天，最好做成系统配置，不要写死。后续想调整成60天，只需要改配置，不用重新发代码。

还书流程就是反向操作，但也有细节要注意：

@Transactional(rollbackFor = Exception.class) public void returnBook(Long recordId) { BorrowRecord record = borrowRecordMapper.selectById(recordId); if (record == null) { throw new BusinessException("借阅记录不存在"); } if (record.getStatus() != 1) { throw new BusinessException("该记录不是借阅中状态，无法归还"); } // 计算是否逾期 LocalDateTime now = LocalDateTime.now(); if (now.isAfter(record.getDueTime())) { long overdueDays = ChronoUnit.DAYS.between(record.getDueTime(), now); record.setStatus(3); // 逾期归还 // 可以记录逾期天数、处罚金额等 } else { record.setStatus(2); // 正常归还 } record.setReturnTime(now); borrowRecordMapper.updateById(record); // 回补库存 Book book = bookMapper.selectById(record.getBookId()); book.setRemaining(book.getRemaining() + 1); bookMapper.updateById(book); }

这里还隐藏着一个并发问题：如果两个读者同时借同一本只剩最后一本的图书，两个请求同时读到remaining=1，都判断“库存充足”，然后都执行扣减，最终库存变成-1，借阅记录却生成了两条。这个问题在答辩时容易拿高分，说明你思考过边界场景。解决思路有两个层面：简单一点的解决方式是使用数据库的行锁，查询图书时加SELECT ... FOR UPDATE，把这一行锁住，另一个请求只能等待；复杂一点可以用乐观锁，在图书表加一个version版本号字段，更新时校验版本号是否变化。对大多数图书管理系统来说，SELECT ... FOR UPDATE更直接有效，代码改动也小。

3.5 登录认证与权限控制

用户认证和权限控制我推荐Spring Security + JWT这套组合。核心逻辑是：登录接口校验用户名密码，成功后生成一个带有用户ID和角色的JWT令牌返回给前端。前端后续请求带上Authorization: Bearer <token>，后端通过过滤器解析令牌，从令牌中获取用户信息。

Spring Security虽然配置略繁琐，但它对安全细节的处理比手写拦截器靠谱得多。你只需要重点改两个地方：SecurityFilterChain配置类，把登录接口放行，其余接口设为需要认证，同时关闭CSRF保护以适配前后端分离。

角色权限通过@PreAuthorize("hasRole('ADMIN')")注解加在管理员接口上。这样普通读者的Token即使拿到接口地址，也无法调用管理端接口，权限边界就分开了。

关于密码存储多说一句：一定不要存明文。用BCryptPasswordEncoder加密存储，即使数据库被人拖走，密码也无法直接反解。用户表里保存的是一长串以$2a$开头的BCrypt密文，登录时用passwordEncoder.matches()比较明文和密文是否匹配。这个细节写到论文里就是“系统安全性设计”部分的素材。

4. 前端页面与接口交互细节

4.1 前后端分离方案的优势与成本

前后端分离是现在管理系统的主流做法。前端用Vue3 + Vite构建，UI组件库选Element Plus，HTTP请求用Axios封装。相比传统的服务端渲染模板，前后端分离的代码组织更清晰，前端专注于页面渲染，后端专注于接口，两边可以并行开发，最终联调阶段再打通。

但要诚实地告诉你，前后端分离也带来了一些额外工作。本地开发时必须处理跨域问题，最简单的是在SpringBoot配置类里加一个CorsFilter或在启动类加@CrossOrigin。生产部署时前端打包成静态文件，由Nginx托管，Nginx再反向代理到后端接口地址。这些步骤并不复杂，但确实需要单独花时间去了解，如果你之前只接触过单体项目。

如果时间特别紧张，也可以直接用Thymeleaf模板，后端渲染页面，省去跨域和前端工程化配置的麻烦。但从学习价值和系统展示效果来看，前后端分离更能体现完整的工程化流程，如果你有时间，我建议选这条更“值”的路线。

4.2 接口文档统一管理与关键接口列表

接口文档不要手写，直接集成Knife4j。它是Swagger的增强版，UI漂亮，支持离线文档导出，最关键的是能在浏览器里直接调试接口。你后端把每个API配上@ApiOperation注解，文档就自动生成，演示项目时现场点几下就能调接口给评委看，比对着PPT念有说服力得多。

核心接口我整理了一张清单，可以直接照抄这个规划：

借还书接口还有一个细节：借书的接口路径是/api/borrow/borrow，虽然看上去有点重复，但意思很清楚。也可以改成/api/borrow用POST调用、/api/return用POST调用，两种都行。保持接口语义清晰，不要搞适配多种操作的大杂烩接口，那是反面教材。

4.3 前端页面布局与核心交互

前端页面整体规划，左侧是导航菜单，右侧是内容区，顶部是用户信息。角色不同，左侧菜单成员不同：管理员能看到图书管理、分类管理、借阅记录、读者管理、数据统计；读者只能看到图书浏览、我的借阅、个人中心。

图书列表页用表格展示封面、书名、作者、分类、出版社、库存、状态，顶部放搜索条件，包括书名输入框、分类下拉框、状态下拉框，配合“搜索”“重置”按钮。这个页面用Element Plus的el-table加el-pagination，后端返回分页数据，前端点击页码重新请求接口，不要做前端假分页。关于分页，我习惯后端返回total总数加records列表，前端根据total计算总页数。

借书操作入口是从图书详情页点“借阅”按钮，弹窗确认当前图书的基本信息、应还时间，再调用借书接口。返回成功就刷新列表，库存减一。这种交互逻辑要写清楚，否则演示时容易漏掉反馈。

图表统计页用ECharts接入后端统计接口。后端统计每月借阅量可以这样实现：写一条SQL按月份分组统计borrow_record里的borrow_time，再把结果封装成折线图需要的字段格式。ECharts本身对后端返回的数据格式没有要求，你只需要在JavaScript层组装就行。

5. 开发路上高频踩坑与排查经验

5.1 版本兼容性问题

SpringBoot的版本坑是我遇到最多的。如果你用SpringBoot 3.x，JDK最低要求是17，很多旧教程的代码直接用不了。我的建议很简单：如果你是做毕业设计或者课程设计，老老实实用SpringBoot 2.7.x + JDK 1.8或者JDK 11，这个组合经过大量项目验证，教程多、报错少、排坑容易。SpringBoot 3.x目前虽然已经是主流，但如果你不熟悉JDK 17的新特性，遇到一些API变化会花时间找资料。

另外MyBatis-Plus和SpringBoot也需要注意版本匹配。旧版MyBatis-Plus可能还没适配新版本SpringBoot，启动时会报Invalid bean definition之类的错误。碰到这种问题，先去查MyBatis-Plus的官网版本兼容说明，不要上来就各种查数据库配置。

5.2 自动建表为什么没生效

有同学用MyBatis-Plus，还按照JPA的习惯在配置文件里写jpa.hibernate.ddl-auto=update，结果项目启动后数据库里一张表都没有，百思不得其解。原因前面已经说过：这个配置是JPA专属的，MyBatis-Plus根本不读取它。

用MyBatis-Plus的正确建表路线就是三条：手动执行SQL脚本，用spring.sql.init配置启动时执行，或者接Flyway。最常见的做法是第一种。如果你想要一劳永逸、演示环境也不用手动操作的方案，推荐写一个配置类，在项目启动完成后执行一次ResourceDatabasePopulator，读取classpath:sql/init.sql自动执行，同时做好“幂等”判断——表已经存在就跳过。这也是“当表不存在自动建表”的通用实现思路。

5.3 中文乱码问题

中文乱码在管理系统中几乎必现一次，通常在两个位置：数据库存入的中文变?，或者接口返回的JSON中文乱码。

数据库乱码大部分是连接配置缺了characterEncoding=utf8。在application.yml的数据库连接URL上，一定要写出完整的参数组合：

url: jdbc:mysql://localhost:3306/library_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

serverTimezone也要注意，MySQL 8.0之后不指定时区会报错或者时间错乱，统一配置成Asia/Shanghai。接口返回乱码则大概率是SpringBoot的序列化配置问题，在配置文件中加上server.servlet.encoding.force=true基本就解决了。

5.4 分页和日期格式的坑

分页有个经常被忽略的问题：前端传pageNum从1开始，后端的Page也是从1开始，但有一堆人习惯从0开始，结果第一页数据总是对不上。前后端联调前，先在接口文档里写明“当前页码从1开始”，这个约定比后期调试省力得多。

日期格式的坑主要在JSON序列化。后端返回LocalDateTime类型时，前端拿到的可能是2026-06-01T10:30:00或者一串时间戳，需要用@JsonFormat注解统一格式化：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") private LocalDateTime borrowTime;

更保险的做法是在配置文件里定义全局的日期格式化，这样所有实体类的日期字段都不用写重复注解。

5.5 配置文件敏感信息泄露

管理系统虽然不涉及支付，但数据库密码、密钥这类配置写进application.yml也是安全隐患，而且像heapdump文件泄露这类安全事件，这几年已经是企业面试的高频词汇。我这个项目里把数据库密码和JWT密钥单独放到一个application-secret.yml，并在生产环境用Jasypt加密配置值。Jasypt集成很简单，一个依赖加一个注解，配置项改成ENC(密文)格式，启动时传入解密密码即可。这个点写进系统设计文档会显得你既有安全意识又有实战经验。

5.6 部署上线流程

项目本地能跑只是第一步，部署到服务器才算真正完整。我的部署方式是：后端用Maven打成Jar包，服务器上安装JDK（版本与本机一致），运行java -jar library-system.jar；前端用npm run build打成静态文件，Nginx配置中把根目录指向dist，接口路径通过/api前缀反向代理到后端端口。

server { listen 443 ssl; server_name your-domain.com; root /opt/library-frontend/dist; index 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; } }

如果你有Docker基础，也可以将后端打成Docker镜像，用docker-compose一次性启动MySQL和SpringBoot容器。这一步属于加分项，但对管理系统来说不是必须。先把Jar包和Nginx跑通，再考虑容器化也不晚。

6. 从课题到成品：加分功能与经验沉淀

6.1 投入少收益高的三个扩展功能

基础功能全部完成后，如果你还有精力，我非常推荐加下面几个功能。它们不但代码量不大，而且每一个都能在答辩时作为“项目亮点”讲：

第一个是Excel批量导入图书。管理员准备好一个固定模板的Excel，上传后后端用EasyExcel解析，逐行校验字段，然后批量插入。没有EasyExcel的时候，POI导入导出要写巨多代码，EasyExcel把这工作量降了一个数量级。这个功能可以体现出你对真实业务场景的理解。

第二个是预约借阅和续借功能。读者看到某本书全部被借走时，可以点击“预约”，等有人还书后系统按预约顺序通知读者；续借则是在应还时间前7天内可申请，每次续借30天，最多续借一次。这两个小功能在字段上只增加一个预约表，加上借阅记录表里加一个renew_count字段，但业务逻辑丰富度立刻上一个台阶。

第三个是数据统计看板。首页加一个ECharts折线图展示近12个月借阅趋势，加一个饼图展示分类借阅占比。后端用SQL做GROUP BY聚合查询，前端拿到数据直接渲染。视觉效果非常好，拍照放论文里也特别撑场面。

6.2 文档与答辩准备的实用建议

做技术项目的人很容易忽略一件事：代码写完了，文档却跟不上。而毕业设计最终评分时，论文和答辩表现占的比例往往比代码本身还高。

论文写作时，需求分析章节就按“业务背景、系统角色、功能需求、非功能需求”四块写，功能需求直接对应本篇文章第1.3节的功能清单。数据库设计章节要画ER图，把表关系讲清楚。系统实现章节按模块分类，每个模块配“核心代码 + 运行截图 + 业务逻辑说明”。测试章节写测试用例表格，覆盖借书、还书、异常输入、权限校验等场景。

答辩前一定要把“借书并发库存问题”“为什么选MyBatis-Plus”“JWT的Token过期如何续期”这几个问题提前想好答案。不是我吓唬你，评委老师最常问的就是这类的“为什么不用X而选Y”和“如果遇到某异常怎么办”的问题。你只要把第3章节的借还业务逻辑和事务处理讲清楚，这些提问基本都能接住。

6.3 我做完这个项目后最深的体会

做管理系统最忌一上来就写代码。我第一版就是直接建项目，边写边想表结构，结果做到一半发现自己把图书分类直接写进了图书表，导致后面想做一个分类下拉统计，还得回头改表改代码。后来每次做新项目，我都强制自己先画清楚三张图：业务流程图、功能结构图、ER实体关系图。图画完，开发就变成填空题了。

还有一个对新手很贴心建议：每天至少提交一次代码到Git仓库。哪怕只改了一个文件，也要养成提交习惯。别小看这个动作，我有一次把借书逻辑改崩了，回退全靠git。如果当时没提交，就要手动回忆改过哪些地方，对比差异会非常痛苦。

图书管理系统的技术难度其实中等偏上一点点，它不像电商系统那样有大流量、高并发、分布式事务，但它把一个典型信息管理系统应该有的要素都覆盖了：多角色权限、复杂业务状态流转、数据关系建模、前后端交互。认真做完一遍，你对SpringBoot的掌握一定不是“能跑HelloWorld”的程度，而是能独立从零做一个可上线项目的水平。

如果你正在准备2026年的课题，或者已经动手做到一半卡住了，这篇内容里的表结构、代码逻辑和避坑点，是我真实实践后的沉淀，希望能让你少走一些弯路。