Java毕设实战：基于Spring Boot+MyBatis-Plus的图书馆管理系统开发详解

1. 为什么图书馆管理系统是Java毕设的“满分选择”

每年到毕业设计选题季，总有不少学生来问我同一个问题：Java方向的毕设到底选什么题目既好过审、又有含金量，还不会把自己写秃？我的答案里一直有一个非常稳的选项——图书馆管理系统。它表面上看着“老套”，但这个题目实际上是Java Web方向的经典综合体，几乎把一个合格Java工程师日常要碰的东西全包含了。

图书馆管理系统，不管是本科毕业设计还是高职课程设计，核心需求都是相通的：图书的借阅、归还、续借以及基础信息管理。围绕这三个动作，你需要设计数据表、写后台逻辑、搭前端页面、处理异常情况。听起来不难，但真正写起来，从数据库设计到事务控制，每一步都有值得深挖的地方。而且这个选题有个天然优势——需求明确、场景贴近日常生活，导师容易理解，答辩时你讲起来也顺畅，不至于被问倒在一个连你自己都绕不明白的虚构业务上。

我见过太多人为了“显得高级”，选了电商系统、秒杀系统这种重并发、重分布式的题目，结果代码写了一堆，最后连最基本的下单流程都没跑通。图书馆管理系统则完全相反，它的复杂度刚好卡在一个健康的位置：B站、菜鸟教程、Github上的开源参考一抓一大把，你不需要从零造轮子，但又必须自己理解每一行代码才能应付导师的追问。如果你正在Java入门到进阶的路上，想找一个项目把Java基础、Spring Boot、MySQL、前端页面串起来完整做一遍，图书馆管理系统就是那个最合适的练手载体。

这篇文章会用一套完整的项目实操经验，把我从搭建项目骨架到完成答辩PPT期间踩过的坑、验证过的方案、核心代码的设计思路全部写出来。项目技术栈以Spring Boot + MyBatis-Plus + MySQL为主，前端采用Thymeleaf模板引擎直接渲染。想照抄作业的同学可以直接用，想理解原理的也能从里面读到设计取舍的逻辑。

2. 技术选型复盘：为什么我弃用了SSH，选择Spring Boot

2.1 新旧两代技术栈的权衡

如果你去百度搜图书馆管理系统，搜出来的老代码有一大半还是SSH（Struts2 + Spring + Hibernate）或者SSM（Spring MVC + Spring + MyBatis）的产物。这些项目源码的历史可以追溯到2015年前后，很多代码结构在今天看来相当痛苦：XML配置十几页、依赖冲突还经常出问题。有同学觉得自己能凭着这些老代码改一改交上去，但实际上参考老项目的成本远比参考新项目高，因为你要花大量时间在解决环境问题上，而不是在写业务逻辑上。

我最终选择Spring Boot 2.7.x作为基础框架，原因很简单：Spring Boot把过去需要手动配置的一大堆东西都自动装配好了，CRUD为主的图书馆管理系统用Spring Boot写，代码量能比SSM版本缩减至少三成。除此之外，Spring Boot的启动方式也特别适合答辩演示——一个main方法就能跑起来，不用去配置Tomcat，不会出现在导师电脑上部署半天起不来的尴尬场景。

持久层我选了MyBatis-Plus而不是原生MyBatis。这类管理系统的增删改查占了所有操作的八成以上，MyBatis-Plus提供的BaseMapper可以直接省掉单表CRUD的XML编写，分页插件也内置好了，对于图书馆这种单表操作居多的系统非常友好。当然，如果你对SQL比较熟悉，用原生MyBatis也行，只是工作量会明显增加。

前端我没有选择前后端分离，而是用了Thymeleaf服务端渲染。原因不是我不会Vue，而是对于图书馆管理系统这种重逻辑、轻交互的管理后台，服务端渲染能把代码架构大大简化。你不需要解决跨域问题，不需要设计前后端联调的接口文档，不用配Nginx，一个应用直接搞定。答辩的时候也更好解释：前端页面通过Thymeleaf语法从Controller的Model里取数据渲染，整条链路直观清晰。如果导师问“你为什么不前后端分离”，回答也很简单：项目定位是单体管理系统，服务端渲染已经能完全满足需求，避免过度设计。

2.2 数据库选型：MySQL为什么够用

数据库方面，我用的是MySQL 8.0。很多人在毕设选题时纠结要不要上Oracle或者SQL Server，我的看法是毕业设计阶段MySQL完全够用，而且够你用得很舒服。MySQL 8.0安装简单，图形化工具Navicat或者DBeaver都能连，遇到问题网上解决方案一搜一大片，这些隐性成本对于赶毕设的学生来说比数据库本身的功能特性重要得多。

有人可能会问，MySQL的存储过程、触发器这些要不要用？我的建议是：能不用就不用。图书馆管理系统的并发量和数据量都很小，用代码层面的事务控制（@Transactional注解）完全可以保证数据一致性，比触发器更好调试，也更符合现在企业开发的主流习惯。触发器写起来一时爽，调试起来火葬场，毕业答辩又不是生产环境，没必要追求数据库的高级特性，把代码写清楚才是得分点。

3. 系统功能拆解：三个核心模块和一个隐藏考点

3.1 图书管理模块：不仅仅是增删改查

图书管理模块是整个系统的数据基础，涉及的功能包括图书的新增、修改、删除、条件查询和分页展示。单看功能点很简单，但实现时有一个非常关键的设计决策：图书的唯一标识是用ISBN还是自增ID？

我用的是“自增ID主键 + ISBN唯一索引”的组合方案。ISBN（国际标准书号）虽然具有唯一性，但它可能会因为录入错误而需要修改，而且相同书名的不同版本ISBN不同，拿它当主键会在关联借阅记录时造成麻烦。自增ID作为主键性能好、逻辑简单，ISBN加唯一索引可以防止重复录入。这个设计在答辩时提出来，导师会认为你真的思考过表结构设计，而不仅仅是照着教程敲了一遍。

图书的查询功能也要做足。单表查询的时候，书名模糊查询、ISBN精确查询、分类下拉筛选、出版社模糊查询、以及上下架状态筛选，这五个条件至少要实现两到三个的组合查询。不要把查询条件写死成只能查一个字段，组合查询在答辩演示时更能展示功能的完整性。分页组件我给的是每页10条，这个数量在演示的时候刚刚好，太长了一页放不下，太短了翻页太频繁。

还有一个容易忽略的细节：图书封面。本地图片上传涉及到文件存储路径的问题，部署环境一变图片就丢，处理起来很麻烦。我最终的做法是封面图存一个外链URL，系统里内置一批默认封面地址，上传功能只做可选扩展不要求必须实现。这样既不影响主体功能，又避免了大量文件上传下载的代码负担。如果你确实需要本地存储图片，记得把文件路径配置放到application.yml里，不要写死在代码中。

3.2 借阅与归还模块：全项目最核心的“硬骨头”

借阅与归还模块是整个系统中业务逻辑最重的部分，也是答辩时最容易出彩、也最容易翻车的地方。借书的流程看起来简单：用户点击借书，系统扣减库存，生成借阅记录。但你需要考虑下面这几种边界情况：读者已经借满了5本书还能不能继续借？这本书的可借库存是否为0？该读者是否还有逾期未还的图书？这些约束条件写在哪里，决定了你代码的质量档次。

我的做法是把借书校验逻辑封装成一个独立方法，由借阅服务统一调用。校验顺序依次是：读者是否存在并处于正常状态、图书是否存在并处于上架状态、可借库存是否大于0、读者当前借阅数量是否达到上限、读者是否有逾期未还的图书。校验全部通过后，在一个事务内同时做两件事：图书表的stock字段减1，借阅记录表插入一条状态为“借出”的记录。注意这里必须加@Transactional注解，否则第二步失败时第一步的库存扣减不会被回滚，就会出现库存和实际借阅记录对不上的数据错误。

还书流程相对简单一些，逻辑是：根据借阅记录ID找到记录，校验其状态确实是“借出”，然后更新图书库存加1，更新借阅记录的状态为“已还”，同时计算并记录实际归还日期和应还日期之间的天数差，如果逾期则计算逾期费用并标记在记录上。这个模块我用一个表格来总结状态变化逻辑：

3.3 统计与展示：借阅排行榜是最容易被低估的加分项

很多同学做图书馆管理系统，做到借阅和归还功能能跑通就收手了，觉得统计报表这种模块属于花架子。但根据我多年帮人改项目的经验，一个带图表统计的页面，在答辩时的加分效果非常明显。它向导师传递了一个信号：你不只是会写增删改查，你还关注了数据展示维度。

我实现了一个简单的“借阅排行”页面，用条形图展示借阅量最高的前10本图书，旁边再放一个饼图展示各分类的借阅占比。前端图表库我选择的是ECharts，用CDN方式引入，不需要npm打包，Thymeleaf模板里直接初始化折线图即可。后端只需要提供一个统计接口，SQL用GROUP BY + ORDER BY + LIMIT就能查出来。代码量不大，但页面视觉效果非常直观，演示时用户一看就知道这个系统是“活”的。

除了图表统计，还可以做一个简单的“图书库存预警”功能：当某本图书的可借库存低于5本时，在书库列表页用红色字体或高亮背景标注。这个功能也是纯SQL查询加一个条件判断的事，实现成本极低，但是在答辩时能体现你对实际业务场景的考虑——图书馆管理员确实需要知道哪些书快被借完了。

3.4 权限控制：一个过滤器搞定的事，别写复杂了

图书馆管理系统的用户角色一般分为管理员和普通读者两种。管理员可以操作所有功能，读者只能查询图书和查看自己的借阅记录。这个权限模型的实现方式有很多，最简单的方案是在登录成功后把用户角色存到Session中，再写一个HandlerInterceptor拦截器对非登录请求做校验。

我在项目中采用了拦截器加注解的方式。自定义一个@AdminOnly注解，标注在管理端操作的Controller方法上，拦截器通过反射判断当前请求的HandlerMethod是否有这个注解，如果有就检查当前Session中的用户角色是否为管理员，不是就跳转到403页面。这种方式比在每一个方法里手动判断角色要优雅得多，导师问起来你也有得讲。

密码存储方面，千万不要明文存。我用的是Spring Security Crypto包里的BCryptPasswordEncoder对用户密码做哈希处理。虽然图书馆管理系统的安全性要求没那么高，但密码加密存储是一个“职业习惯”的体现，哪怕它只花你十行代码，答辩效果却不一样。注册功能如果不需要，可以直接预置几个测试账号，一个管理员账号和一个读者账号，方便演示时直接切换角色。

4. 数据库设计实战：五张表搞定全部逻辑

4.1 核心表结构设计

图书馆管理系统的数据库表可以精简到五张：管理员表（admin）、读者表（reader）、图书表（book）、图书分类表（category）、借阅记录表（borrow_record）。每张表的字段设计要克制，不必要的字段不要加，但核心业务字段一个也不能少。这里我直接给出每一张表的核心建表SQL，方便你照着落库。

图书表是系统的核心资产表，字段设计如下：主键id、书名book_name、作者author、出版社publisher、ISBN编号isbn、分类id category_id、总库存total_stock、可借库存available_stock、上架状态status、封面图url、创建时间create_time。其中可借库存和总库存是分开设计的，这是借阅功能能正确运转的关键。borrow_record表里的书id关联book表。图书表SQL的核心部分：

sql复制CREATE TABLE `book` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键',
  `book_name` varchar(100) NOT NULL COMMENT '书名',
  `author` varchar(50) DEFAULT NULL COMMENT '作者',
  `publisher` varchar(100) DEFAULT NULL COMMENT '出版社',
  `isbn` varchar(20) DEFAULT NULL COMMENT 'ISBN编号',
  `category_id` bigint DEFAULT NULL COMMENT '分类ID',
  `total_stock` int DEFAULT '0' COMMENT '总库存',
  `available_stock` int DEFAULT '0' COMMENT '可借库存',
  `status` tinyint DEFAULT '1' COMMENT '状态：1上架 0下架',
  `cover_url` varchar(255) DEFAULT NULL COMMENT '封面图片',
  `create_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_isbn` (`isbn`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='图书表';

借阅记录表是整个系统中最忙的一张表，每次借书和还书都会在这张表里插入和更新记录。字段设计上，除了关联外部表的reader_id和book_id，还需要记录借出时间borrow_time、应还时间due_time、实际归还时间return_time以及状态status。status字段用整型表示：0待还、1已还、2已续借。应还时间我默认设置为借出时间加30天，这个天数可以抽成配置项，答辩时可以主动提一句“借阅天数通过配置项控制，方便管理员调整”。

4.2 表关系与索引规划

五张表的关系可以这样理解：读者和图书之间是多对多的关系，一个读者可以借多本书，一本书可以被多个读者借阅，而借阅记录表正是连接它们的关系表。管理员和图书之间没有直接关系，管理员是操作者。图书和分类之间是多对一的关系，一本书只能属于一个分类。

索引规划方面我在实际开发中做了一个重要决策：给borrow_record表的reader_id和status字段创建了联合索引。原因是读者个人借阅历史页面最常用的查询条件是“某个读者的所有未还记录”，这个联合索引可以直接命中，不用全表扫描。对于毕设级的数据量来说索引优化看着是小题大做，但你在答辩时说出这条设计理由，体现的是数据库优化意识。

4.3 事务边界：保证库存和记录的一致性

借书操作涉及两步写库：扣减book表的available_stock，同时向borrow_record插入记录。这两个操作必须放在同一个数据库事务中。我在工程里写了多个实现版本，最终采用了最稳妥的写法：在业务Service方法上标注@Transactional，利用Spring的声明式事务管理。

这里有一个容易踩的坑：由于我用的MyBatis-Plus，默认的事务管理器会自动配置好，所以@Transactional注解是可以直接生效的。但如果有人用ShardingSphere或者多数据源配置，就需要注意事务管理器是否被多个数据源覆盖。另外，事务的传播行为默认是REQUIRED，这在这个项目里已经完全够用。我们不需要嵌套事务或者独立事务，保持简单就是最大的可靠。

关于并发场景，图书馆管理系统的并发量很低，但代码层面仍然要做一道防线：借书时先执行UPDATE book SET available_stock = available_stock - 1 WHERE id = ? AND available_stock > 0，然后判断受影响行数。如果受影响行数为0，说明库存已经不足，直接抛出业务异常拒绝借书。这种“乐观锁”思路比先查后改更安全，因为即使在极端并发下，数据库的行锁也能保证不会出现超借的情况。

5. 核心代码走读：借书、还书与超期计算

5.1 借书流程的核心实现

借书操作的Service层代码是整个项目中最值得仔仔细细研究的一段。我先把完整流程用文字拆开：第一步，接收前端传来的readerId和bookId；第二步，依次执行校验逻辑；第三步，做库存的原子扣减；第四步，生成借阅记录；第五步，返回借阅成功的图书信息。任何一步抛出异常，事务回滚，所有数据保持不变。

从 Controller 到 Service 的调用路径，我贴一段核心代码说明设计思路：

java复制@Transactional(rollbackFor = Exception.class)
public BorrowResult borrowBook(Long readerId, Long bookId) {
    // 1. 校验读者状态
    Reader reader = readerMapper.selectById(readerId);
    if (reader == null) {
        throw new BizException("读者不存在");
    }
    
    // 2. 校验图书状态
    Book book = bookMapper.selectById(bookId);
    if (book == null || book.getStatus() == 0) {
        throw new BizException("图书不存在或已下架");
    }
    
    // 3. 查询该读者未还的借阅记录数量
    Long borrowCount = borrowRecordMapper.selectCount(
        new LambdaQueryWrapper<BorrowRecord>()
            .eq(BorrowRecord::getReaderId, readerId)
            .eq(BorrowRecord::getStatus, 0));
    if (borrowCount >= MAX_BORROW_COUNT) {
        throw new BizException("该读者已达到最大借阅数量");
    }
    
    // 4. 原子扣减库存
    int updateRows = bookMapper.deductStock(bookId);
    if (updateRows == 0) {
        throw new BizException("图书库存不足");
    }
    
    // 5. 生成借阅记录
    BorrowRecord record = new BorrowRecord();
    record.setReaderId(readerId);
    record.setBookId(bookId);
    record.setBorrowTime(new Date());
    record.setDueTime(DateUtils.addDays(new Date(), LOAN_DAYS));
    record.setStatus(0);
    borrowRecordMapper.insert(record);
    
    return new BorrowResult(book.getBookName(), record.getDueTime());
}

这里的deductStock方法对应SQL为UPDATE book SET available_stock = available_stock - 1 WHERE id = #{bookId} AND available_stock > 0。之所以不用先SELECT再UPDATE，是为了避免两个操作之间的时间窗口内库存被并发修改，虽然毕设场景并发量很小，但养成好的编码习惯以后工作受益。

5.2 还书流程与超期费用算法

还书流程相对借书简单一些，但有个隐藏考点：超期天数怎么计算才准确。首先明确一点：不要用系统当前时间减去借出时间来计算是否超期，而要用预约的应还时间和真实还书时间做差值。逻辑上，应还时间是借出时就算好的30天后，还书时间就是执行还书操作那一刻。如果还书时间晚于应还时间，就说明超期了。

计算天数差我推荐用java.time包的LocalDate而不是老旧的SimpleDateFormat。LocalDate的between方法可以精确计算两个日期之间的天数差，处理跨月、跨年都没问题，而且不会出现SimpleDateFormat线程安全的问题。超期费用的计算规则我设置的是每超期一天收取0.5元，这个费率写死在配置变量中。费用只做记录，不做支付系统，毕设阶段不需要做得太复杂。

还书操作同样需要事务控制：更新借阅记录状态为已还，填写returnTime，然后把book表的available_stock加1。注意这里的加库存操作是简单的递增，不需要像借书时的条件更新，因为只要借阅记录是有效的，还书就一定能把库存加回去。

5.3 借阅记录的查询与分页

读者在前端看到的借阅记录列表，需要支持分页显示和状态筛选。MyBatis-Plus自带的分页插件对这个场景非常友好，我直接在Controller里构建一个LambdaQueryWrapper，按readerId和可选的状态参数过滤，然后调用selectPage方法。返回给前端的Page对象包含了总记录数、当前页数据、页码等信息，配合前端的分页导航组件就能实现完整的分页功能。

前端这里用Thymeleaf的th:each循环遍历列表，通过th:if判断每一条记录的状态值来显示不同的按钮：如果status为0，显示“还书”按钮；如果status为1，显示“已归还”标签并且不显示任何操作按钮。页面上还需要展示“应还日期”“超期天数”这些字段，方便管理员和读者一目了然地看到借阅情况。

6. 前端页面实现：Thymeleaf模板复用与交互细节

6.1 页面整体布局：后台管理框架的搭建

页面布局方面，我采用了一个非常标准的后台管理框架结构：顶部是系统的Logo和当前登录用户信息，左侧是导航菜单，右侧是内容区域。由于图书馆管理系统的功能模块不算太多，我直接把左侧菜单做成了固定列表项：图书管理、读者管理、借阅管理、统计报表、系统设置，点击之后通过URL切换右侧内容区。

在前后端不分离的设计下，布局复用靠的就是Thymeleaf的fragment片段。我把导航菜单和头部公共区域抽取到fragment中，每个页面通过th:replace引入，这样修改菜单只需要改一个文件，全站同步生效。这个技巧虽然基础，但答辩时如果你主动说明代码复用的思路，会显得你的工程意识比同龄人强。

菜单高亮也是一个细节活。我给每个菜单链接加了data-menu属性，在页面渲染时通过Thymeleaf的内联表达式对比当前URI和菜单的URI，匹配到就追加active样式类。这样做的好处是用户操作时有清晰的位置感知，不会在当前页面迷失方向。

6.2 列表页的筛选表单与Ajax交互

图书列表页是整个系统使用频率最高的页面，所以它的交互设计值得多花心思。我在图书列表页顶部设置了一行筛选条件：图书名称输入框、ISBN输入框、分类下拉框和查询按钮，下面的表格区域展示符合条件的记录。查询按钮点击后提交GET表单，将查询参数拼接到URL里，跳转到带参数的列表页。这种同步表单处理方式对服务端渲染的项目来说实现最简单。

不过更“现代”一点的方案是用Ajax局部刷新。如果你想在答辩时体现出你懂前后端数据交互，可以把列表查询改成Ajax方式：jQuery发起请求，后端返回JSON，前端JS拼接表格HTML。这样用户体验会更好，但代码复杂度也上一个台阶。我的建议是二选一，别两个都做，把其中一个做得足够流畅比两个都做但都很糙要有说服力。

图书的新增和编辑我合并到了同一个表单页面。点击“新增”按钮跳转到空表单，点击某行“编辑”按钮跳转到带参表单，Controller里根据参数是否存在来决定执行新增还是更新逻辑。表单校验用到了前端的HTML5 required属性和后端的字段判断双重校验，前后端都做校验是生产环境的基本习惯，答辩值得提。

6.3 弹窗确认与操作反馈

删除操作必须加确认弹窗，这个我深有体会。曾经有一次我不小心在演示时点了删除图书按钮，整本书的记录就这样没了，关键是样本数据不多，那一本还刚好是我准备重点展示的书。加一个confirm弹窗只需要一行代码，但能避免演示当场翻车。我的做法是给所有删除按钮绑定click事件，弹窗确认后再提交删除请求。

操作完成后的用户反馈也不能忽略。我选择用浏览器自带的alert弹窗展示“操作成功”或“操作失败”的提示信息，再加上页面重新加载后的数据变化，用户可以明确知道操作结果。更优雅的方案是用Toast轻提示组件，但需要额外引入前端库，根据你的时间预算自行选择就行。

7. 从获取源码到成功运行：调试排查全流程

7.1 拿到项目后的第一步：读README和配置检查

通过GitHub或者课程设计资源站下载的源码，很多时候是Java 8的老项目，而你自己电脑装的是Java 17，启动直接报错，这是最常见的碰壁场景。拿到源码第一步，先打开README文件或者pom.xml，确认项目要求的JDK版本、Maven版本和数据库版本。如果项目要求JDK 8，你的本机默认JDK是17，优先安装JDK 8并配置环境变量，而不是硬用什么“兼容模式”。

第二步是修改数据库配置。所有图书馆管理系统的源码里必然有一个application.yml或application.properties文件，里面有spring.datasource.url、username、password这些配置。把它们改成你自己本机的数据库地址、用户名和密码。特别注意数据库密码如果包含特殊字符，比如@、#、$等，需要做URL编码或者修改密码，否则连接会失败。

7.2 数据库初始化：SQL脚本的执行顺序

很多源码压缩包里都附带一个init.sql或者schema.sql，里面有建库建表和初始化数据的SQL。执行顺序有讲究：先创建数据库，再切换到这个数据库下执行建表语句，最后执行插入样例数据的语句。如果你用Navicat，直接打开SQL文件然后点运行即可，不要在一个默认数据库下直接执行，否则表可能建到了mysql库或者sys库里。

初始化数据中的管理员账号和读者账号，一般在SQL文件的最后几行，注意提前记下来。演示时导师问“怎么登录管理端”，你只回一句“账号admin密码admin123”就可以了。如果你改过密码，别轮到演示那天自己都忘了账号，提前记到便签上。

7.3 常见启动报错排查表

我把这个项目最容易出现的启动问题整理成了一张速查表，以下每一条都是我在实际帮人调试时真实遇到过的：

这里想额外说一点：遇到报错，先看控制台前几行，不要被最后十几行的堆栈吓倒。框架报错信息往往很长，真正的问题原因通常隐藏在第一个Caused by里。把Caused by后面的描述复制到搜索引擎里搜，绝大多数情况能找到答案，这也是程序员的核心技能。

7.4 调试定制服务该怎么用效果最好

标题里提到的调试定制服务，我从使用者的角度说一下如何让这类服务发挥最大价值。首先，不要一拿到代码就问“帮我跑起来”，先自己尝试按照README操作一遍。遇到问题把完整的报错信息、你的操作步骤、你的环境版本（JDK版本、Maven版本、MySQL版本）整理好一次性发给调试方，沟通效率会高很多。我见过的沟通失败案例，九成是信息不完整导致的来回拉扯。

其次，定制的需求要小而具体。一次提一个明确的功能点，比如“在图书列表页加一个按出版社筛选的下拉框”，比“帮我美化一下系统”更容易交付，也更容易确认改没改对。大而全的需求描述往往是踩坑的开始，对方理解偏了，你验收时也说不清楚哪里有问题。

8. 答辩准备：导师最常问的几个问题

8.1 关于系统设计的高频追问

答辩时导师一般不会让你把代码从头读一遍，而是围绕系统设计的核心决策来问问题。比如会问到：为什么选择MySQL做数据库？为什么不用SQL Server？这类问题在2.3节已经给出答案思路，核心是讲清楚MySQL对你这个规模的应用完全足够，且在开发调试上有明显优势。

还会问到：借阅记录和图书表的关联关系是怎么维护的？这个问题考察的就是外键和逻辑关联。我的实现里没有物理外键约束，而是通过业务代码保证逻辑引用的一致性。这样设计的考量是实际开发中物理外键会带来额外的维护成本，而逻辑外键配合事务控制完全能满足需求。你能把这个理由讲清楚，导师一般不会再追问。

8.2 演示时给导师留几个“可问点”

答辩演示有个技巧：故意在功能设计里留一些“可问点”——也就是你提前想好了答案的亮点，等导师问的时候从容回答。我的项目里就有这么几个预设话题。一个是为什么借阅天数设置成30天而不是其他值——答案是因为这是行业通用借阅周期，可以从系统中配置修改。另一个是可借库存为0时前端UI会有什么反馈——答案是该书的“借阅”按钮会被disabled，同时列表底色变灰。

我还特别喜欢在答辩时提到一个真实的使用场景：如果管理员删掉了一本正在借阅中的图书，系统会怎么处理？我的做法是物理删除只针对无人借阅记录关联的图书，一旦发现有关联的未还记录，则提示“该书尚有借阅记录未归还，禁止删除”。这个问题虽然不是必须实现的功能，但能体现你的思考深度。

8.3 如何应对“你的代码有什么不足”

导师最爱问的一个开放式问题就是：你觉得你这个系统的不足之处是什么？千万不要回答“没有不足”，也不要回答“就是不够完善”，这都等于把送分题变成了送命题。我的标准答案是：第一，当前系统的并发控制还比较基础，采用的是乐观锁思路，在高并发场景下可能还要结合分布式锁方案；第二，图书批量导入还没有实现，后续可以支持Excel导入；第三，数据统计图表目前只做了借阅排行和分类占比，后续可以扩展读者阅读趋势分析。

这三个“不足”每一个都对应一个技术方向，说出来显得你对未来优化有清晰的思考路径。而且这些也确实是我在真实开发中感觉可以继续完善的地方，不是刻意编的。记住，答辩不是证明你的系统完美无缺，而是证明你有发现问题并解决问题的能力。

9. 一些我在实际开发中总结的小技巧

图书馆管理系统虽然看起来“传统”，但在实际开发和调试过程中暴露的问题一点也不少。我在做这个项目的过程中最深刻的体会是：这类系统的坑往往不在高大上的分布式、消息队列，而就在最基础的CRUD边界处理上。一本书被借走以后库存有没有减？读者还了书之后状态有没有马上刷新？超期费用计算跨月的时候准不准？这些细节才是决定系统能不能真正用的关键。

最后分享一个很多人忽略的小技巧：在做系统演示之前，一定先把样例数据准备充足。不要只有两三本书塞在那里，排列出来页面空落落的，导师看了印象分会降低。我在项目里预置了20本左右的图书，覆盖5到6个分类，其中有一两本的名字特意做得有辨识度，比如《Java从入门到放弃》《图解算法》这样，演示的时候开个玩笑，气氛也能松弛一些。系统跑通了以后，自己把借、还、续借、查询、统计这几个主流程反复走几遍，把每一步的数据变化都在心里确认一遍，答辩的时候就不会被一点点小意外打得措手不及。