简介这是一份围绕“基于Spring Boot和MySQL的在线图书管理系统”的课程设计文档面向具备Java与Web开发基础、希望完整实现前后端分离项目的开发者。文档沿项目开发顺序展开先进行需求分析区分管理员与读者两类角色梳理图书录入、借阅归还、个人信息管理等功能以及性能、界面要求随后讲解技术选型与架构设计给出MySQL中图书、读者、借阅记录三张核心表的完整建表结构涵盖图书ID、书名、作者、出版社、ISBN、库存数量读者信息及借阅日期等字段并展示Spring Boot后端从实体类、Repository、Service到Controller的完整代码示例前端则结合HTML/CSS、Bootstrap和JavaScript实现页面布局、表单表格与AJAX请求。资源为1个DOCX文档大小约18KB当前已有101人学习下载。文档中包含可直接参考的RESTful API增删改查示例及前端交互代码跟随案例动手实践可系统掌握从数据库设计到后端接口、再到前端联调的实现思路非常适合课程作业或入门级项目参考。1. 在线图书管理系统在做什么难点不在框架在借阅动作那一刻基于Spring Boot和MySQL的在线图书管理系统是Java后端方向最经典、也最容易被低估的一类项目。很多开发初学者一上来就先建工程、配依赖、写CRUD结果两三天后项目能跑却经不起任何一个人真正使用库存会变成负数同一本书被两个用户同时借走超期罚款算出来是负的改个密码把别人的会话顶掉。真正让这个系统有价值的不是Spring Boot的自动装配也不是MySQL的建表语句而是借书、还书这两个动作背后的事务边界与并发控制。这篇笔记会从数据模型开始把核心接口、库存扣减方案和上线前的高频问题依次讲透适合正在做课程设计、想把它扩展成作品集的开发者也适合第一次完整搭建后端系统、想要一份可复现路径的从业者。2. 把数据模型先立住六张核心表与字段设计的取舍2.1 图书、用户、分类三张主表的落库方式图书管理系统的数据模型通常从三张主表开始图书表、用户表、分类表。分类与图书的关系大概率是一对多图书表的分类字段存分类表主键用户表则分两种角色管理员与普通读者我习惯用一个小整型字段区分而不是拆两套表。拆两套表的代价在后续借阅记录关联用户时会成倍放大查询要union权限判断要重复写收益却很小。下面是图书表最常见的设计按我自己的落地习惯字段名用下划线风格方便直接映射到实体属性CREATE TABLE book ( id BIGINT AUTO_INCREMENT PRIMARY KEY, isbn VARCHAR(32) NOT NULL COMMENT 国际标准书号, title VARCHAR(128) NOT NULL COMMENT 书名, author VARCHAR(64) NOT NULL COMMENT 作者, category_id BIGINT NOT NULL COMMENT 分类ID, publisher VARCHAR(128) DEFAULT NULL, publish_date DATE DEFAULT NULL, stock_count INT NOT NULL DEFAULT 1 COMMENT 可借库存, total_count INT NOT NULL DEFAULT 1 COMMENT 馆藏总量, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_book_isbn (isbn), KEY idx_book_category (category_id), KEY idx_book_title (title) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有两个字段值得单独说明。stock_count与total_count必须拆开总馆藏量是常量可借库存是随借还动作动态变化的变量每次借阅扣减的都是stock_count还书时加回。如果只存一个数量字段后续做图书下架、盘点、丢失报损时完全没有回旋余地。isbn字段我加了普通索引但并没有建唯一索引原因放在后面的避坑章节细说很多项目在这里翻过车。用户表相对简单核心字段就是用户名、密码密文、角色、状态和联系方式。密码密文用BCrypt生成不要用MD5加盐这种已经被破解过很多轮的方案。角色字段用TINYINT1表示管理员2表示普通读者。分类表只需要id、category_name和parent_id三级字段支持二级分类足够再深就会让前端菜单和查询条件都变得复杂。2.2 借阅记录与罚款记录为什么必须拆成两张表很多初版设计会把借阅记录、还书时间、罚款金额全部塞进一张表查起来确实方便但一到真实业务就撑不住。借阅记录表与罚款表必须拆开因为这两个生命周期完全不同一条借阅记录只有一次借出、一次归还而一条罚款可以多次部分缴纳、减免、甚至申诉复核。两者是一对多的关系改装在一张表里每次部分缴费都要更新主记录历史痕迹就丢了。借阅记录表的参考建表语句如下CREATE TABLE borrow_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL COMMENT 借阅人, book_id BIGINT NOT NULL COMMENT 图书, borrow_time DATETIME NOT NULL COMMENT 借出时间, due_time DATETIME NOT NULL COMMENT 应还时间, return_time DATETIME DEFAULT NULL COMMENT 实际归还时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 0借阅中 1已归还 2逾期已还, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_borrow_user (user_id), KEY idx_borrow_book (book_id), KEY idx_borrow_status (status), CONSTRAINT uk_borrow_active UNIQUE (user_id, book_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;due_time由borrow_time加上借阅规则里的最大借期计算得出不要在代码里硬编码天数应该做成系统参数表或者配置项。status字段的三态设计是这表的灵魂判断一本书是否可借、一个用户是否超期未还都优先走这个字段而不是去比对时间。uk_borrow_active这个联合唯一索引直接限制同一个用户对同一本书不能存在两条借阅中的记录是并发下防止重复借阅的最后一道数据库防线这个点在第5章会展开讲。罚款表独立设计时记录的是哪条借阅记录产生了罚款、罚款金额、已缴金额、减免金额与状态。计算逾期罚款的动作应当发生在还书那一刻而不是定时任务扫表因为用户在还书前可能自己续借续借成功后会生成新的due_time提前算好的罚款就变成脏数据。2.3 给表上索引前要想明白的三个场景索引不是越多越好尤其是图书管理系统这种读写比不极端、数据量在十万级到百万级之间的场景。我一般只围绕三个场景加索引按分类浏览图书、按关键字搜书名、按用户查借阅记录。对应到表上就是book.category_id、book.title、borrow_record.user_id再加复合索引(user_id, status)来支撑「某用户当前借了哪些书」的查询。主键之外的索引每多一个写入时的维护成本就多一分。图书表没必要给publisher单独加索引出版社的等值查询量太低罚款表没有必要给amount加索引范围统计走全表扫描在十万级数据量下并不会成为瓶颈。我见过不少项目在每张表上堆七八个索引结果借还书高频写入时磁盘IO明显上涨排查半天才发现是冗余索引拖慢了更新性能。这里还要注意字符集与排序规则的一致性。库、表、字段统一utf8mb4与utf8mb4_unicode_ci避免两张表join时排序规则冲突报错。MySQL 8.0默认字符集已经是utf8mb4但老库迁移过来时经常残留latin1联表查询中文条件时会出现查不到数据的情况这类问题不容易一眼看出原因我在第5章会给排查路径。提示建表时顺手把update_time配置为ON UPDATE CURRENT_TIMESTAMP后面排查脏数据时可以少做很多猜测这个字段在接口联调阶段会反复用到。3. 分层骨架与核心接口把借书还书流程跑通的代码落地3.1 项目分层与依赖Controller / Service / Mapper 怎么分工在讲具体代码之前先把分层结构说清楚。常见的做法是严格五层Controller负责参数接收与结果包装Service负责业务规则与事务Mapper负责SQL与数据库交互DTO负责跨层传参VO负责给前端展示。DTO与VO的拆分容易被认为是过度设计但在图书管理系统里很快能体现价值图书实体的stock_count是内部字段接口返回给前端时不应该带而前端需要的借阅状态、逾期天数在实体里不存在必须由Service组装后写入VO。依赖选择上没有标准答案我只讲自己最顺手的组合Spring Boot 3.x配合MyBatis-Plus做数据访问JWT做无状态登录认证密码加密用spring-security-crypto里的BCrypt。不用Spring Security全家桶是因为这个项目的权限模型只有两个角色一个拦截器加注解就够没必要引入厚重的安全框架把登录流程复杂化。分层之后的目录结构大致是下面这个样子src/main/java/com/example/lib ├── controller # 接受HTTP请求做参数校验 ├── service # 业务规则、事务控制 ├── mapper # MyBatis-Plus接口或自定义SQL ├── entity # 与数据库表一一对应的实体 ├── dto # 入参对象 ├── vo # 出参对象 ├── config # 拦截器、跨域、Web配置 └── common # 统一返回体、异常、工具类这个结构的要求是单向依赖Controller可以依赖ServiceService依赖MapperEntity只在Service与Mapper之间传递Controller里不要出现Entity。很多翻车现场就是因为Controller直接操作Entity导致前端传进来一个stock_count字段把库存改成了负数这种安全漏洞在分层不严格的项目里太常见了。3.2 图书登记与分页查询的接口实现图书登记的核心动作是组装Book实体做唯一性校验后执行插入。校验逻辑不能用selectById因为ISBN才是业务上的唯一键。先按ISBN查一次库存在就返回冲突提示不存在再走插入。查询与插入之间虽然有并发窗口但在图书登记这种低频操作下数据库唯一索引兜底已经足够后面借阅场景才需要更严格的并发控制。分页查询是每个后台列表页的地基MyBatis-Plus提供了分页插件核心代码如下GetMapping(/books) public ResultIPageBookVO pageBooks(RequestParam(defaultValue 1) int page, RequestParam(defaultValue 10) int size, RequestParam(required false) String keyword, RequestParam(required false) Long categoryId) { PageBook bookPage new Page(page, size); LambdaQueryWrapperBook wrapper new LambdaQueryWrapper(); if (StringUtils.hasText(keyword)) { wrapper.like(Book::getTitle, keyword).or().like(Book::getAuthor, keyword); } if (categoryId ! null) { wrapper.eq(Book::getCategoryId, categoryId); } wrapper.orderByDesc(Book::getCreateTime); IPageBook result bookMapper.selectPage(bookPage, wrapper); return Result.ok(convertToVO(result)); }这段逻辑要说明两个参数。page和size直接由前端传入size必须设置上限比如最大100条防止有人一次性拉全表数据拖垮数据库。keyword的模糊查询我用的是like它在百万级数据量下会放弃索引走全表扫描如果图书表数据量大更稳妥的做法是引入全文索引或者搜索引擎这一点放到第6章展开。分页查询的返回值为什么要转成VO因为实体里的stockCount和totalCount是内部库存信息普通读者端不需要看到损耗逻辑另一方面前端需要展示的categoryName来自分类表Service层在转换时批量查出分类映射填入VO即可避免在循环里逐条查询数据库这会触发典型的N1问题。3.3 借书还书流程事务边界应该画在哪借书是整个系统里事务边界最典型的一段代码。一次借书动作至少包含三处数据变更扣减图书库存、写入借阅记录、检查用户当前借阅数量是否超过上限。这三处必须处在同一个事务里任何一步失败都要全部回滚不然就会出现库存扣了但借阅记录没生成或者借阅记录生成了但库存没扣的中间状态。放一段核心实现注意事务注解的位置Service public class BorrowService { Transactional(rollbackFor Exception.class) public Long borrowBook(Long userId, Long bookId) { // 1. 校验用户是否存在、状态是否正常 User user userMapper.selectById(userId); if (user null || user.getStatus() ! 1) { throw new BizException(用户不存在或已被禁用); } // 2. 锁定图书行并检查可借库存 Book book bookMapper.selectByIdForUpdate(bookId); if (book null || book.getStockCount() 0) { throw new BizException(图书不存在或库存不足); } // 3. 检查该用户借阅中数量是否达到上限 Long activeCount borrowRecordMapper.selectCount( new LambdaQueryWrapperBorrowRecord() .eq(BorrowRecord::getUserId, userId) .eq(BorrowRecord::getStatus, 0)); if (activeCount maxBorrowLimit) { throw new BizException(已达到最大借阅数量); } // 4. 扣库存、生成借阅记录 bookMapper.reduceStock(bookId); BorrowRecord record new BorrowRecord(); record.setUserId(userId); record.setBookId(bookId); record.setBorrowTime(new Date()); record.setDueTime(DateUtils.addDays(new Date(), borrowDays)); record.setStatus(0); borrowRecordMapper.insert(record); return record.getId(); } }事务注解用rollbackFor Exception.class而不是默认的RuntimeException是为了把BizException这类自定义业务异常也纳入回滚范围这是一个新手最容易踩的洞。代码里的selectByIdForUpdate是悲观锁的核心它会在事务内锁定这条图书记录直到事务提交才释放步骤4的扣库存必须与步骤2处在同一个事务里锁才有效果。3.4 JWT登录与权限拦截的最小实现登录接口的逻辑分三步接收用户名密码、校验BCrypt密文、签发JWT。签发时不把敏感信息塞进token只放userId和role过期时间我习惯设成2小时管理员端的后台操作频繁过短会让用户反复登录过长又会放大token泄露的风险。图书管理系统的安全等级不需要做到银行级别两小时是体验与安全之间比较平衡的取值。登录后的权限控制用一个拦截器加自定义注解即可。拦截器负责解析token、把当前用户信息放入ThreadLocal注解RequireRole(admin)标记在需要管理员权限的接口上由另一个拦截器检查role是否匹配。放一个简化版的拦截器实现Component public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录与图书查询等公开接口 if (handler instanceof HandlerMethod) { HandlerMethod hm (HandlerMethod) handler; if (hm.hasMethodAnnotation(PublicApi.class)) { return true; } } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BizException(未登录或token缺失); } // 解析token失败或过期时抛出未授权异常 LoginUser loginUser JwtUtil.parseToken(token.replace(Bearer , )); UserContext.set(loginUser); return true; } }这段代码里有三个实用细节。第一PublicApi注解用于标记公开接口避免在拦截器里写大量路径白名单第二Authorization头必须是Bearer前缀加上token前端与后端约定一致解析时统一去掉前缀第三UserContext.set把用户信息放进ThreadLocal后续Service层通过UserContext.get()获得当前用户而不用在Controller里手动传参。别忘了在afterCompletion里清理ThreadLocal否则线程池复用线程时会出现串号这个问题在避坑章节还会提到。提示JWT解析依赖一个可靠且同源的密钥生产环境用AES或RSA生成密钥对不要直接写死在代码里。开发环境可以放配置文件上线前替换成环境变量注入。4. 并发场景下的库存扣减三种方案怎么选4.1 先查后扣为什么会在并发下翻车借书接口看起来逻辑完整但一旦拆到并发场景就暴露问题。两个用户同时发起对同一本书的借阅请求两个线程都执行了stockCount 0的检查都发现库存还剩1本然后各自执行扣减最终库存变成-1这就是典型先查后扣导致的超借。问题的根源不是SQL写错而是检查与扣减之间不是一个原子操作任何一个并发系统都会遇到类似的竞态。解决这个问题的常规手段有三条路数据库悲观锁、数据库乐观锁、应用层分布式锁。对图书管理系统这种单体应用、单库MySQL的规格前两种足够分布式锁只有在系统拆成多实例部署后才有必要引入我不建议初学者一上来就上Redis分布式锁环境复杂度会盖过业务本身。4.2 悲观锁在事务内的写法与边界悲观锁的本质是让数据库在查询时就对该行数据加锁其他事务必须等当前事务提交后才能操作同一行。代码上就是前面提到的selectByIdForUpdate对应的Mapper SQL如下SELECT * FROM book WHERE id #{bookId} FOR UPDATE;把这条SQL放在事务内执行后两个并发请求对同一本书执行查询时后到的那一个会被阻塞直到前一个事务提交或者回滚。阻塞时间通常只有几十毫秒对图书借阅这种低频操作来说完全可接受。悲观锁的边界在于锁的生命周期必须通过Transactional控制锁定的行必须在同一个事务内完成后续的库存扣减否则线程在事务提交前就把锁释放了等于没锁。使用FOR UPDATE时还要注意两点。第一务必带主键或唯一索引条件WHERE条件不能命中索引InnoDB会对全表加锁整个表的写入都会被堵死。第二锁与连接池相关长事务会长时间占用数据库连接如果业务里没有慢SQL借还书接口的事务时长通常能控制在百毫秒内不会有连接耗尽的风险。如果事务里还混了远程调用或文件上传那才是真正的隐患这类耗时操作要挪到事务外执行。4.3 乐观锁与重试库存操作的另一种解法乐观锁不阻塞数据库操作而是通过版本号在更新时校验数据是否被改过。库存表增加一个version字段每次更新时把版本号作为条件一起带上Update(UPDATE book SET stock_count stock_count - 1, version version 1 WHERE id #{bookId} AND stock_count 0 AND version #{version}) int reduceStockByVersion(Param(bookId) Long bookId, Param(version) Integer version);这条SQL的妙处在于把校验和扣减合并成一个原子操作。stock_count 0直接保证了不会扣成负数version #{version}保证扣减前数据没有被其他事务改过。若更新影响行数为0代码需要重试或者直接返回库存不足重试逻辑一般由Service层循环控制重试次数与间隔可以配置常见的做法是3次、间隔50毫秒。乐观锁与实际业务的匹配度要看冲突频率。图书管理系统的场景里同一本热门书被并发借阅的概率并不高乐观锁的冲突率很低性能优于悲观锁课程设计或演示项目中也更推荐乐观锁因为不需要理解事务、锁粒度和连接池之间的关系。但要注意乐观锁要求表结构里多加version字段还书逻辑同样要走版本号校验否则就出现一边加版本、一边不加版本的情况锁失去意义。悲观锁与乐观锁的最终选择我的习惯是单体项目、并发峰值肉眼可见、愿意接受短暂阻塞用悲观锁数据规模不大但希望代码可读性好、未来可能迁移到多实例用乐观锁。两种方案在图书管理系统里都能撑住数万日活真正的翻车点从来不在锁选型而在于事务边界没有画对。5. 从开发到上线的五个高频坑与排查路径5.1 同一本书被借出两次联合唯一索引没建现象后台借阅记录里出现同一个用户对同一本书的两条借阅中记录库存与记录对不上。原因代码里只检查了「该用户是否已借阅这本书」但检查与插入之间没有数据库层面的约束并发请求同时通过检查。解决给borrow_record表加上(user_id, book_id, status)联合唯一索引让数据库成为最后一层防线插入时捕获唯一键冲突异常转成友好提示「不可重复借阅同一本书」。我在第2章建表时预留了这个索引就是为这里兜底。5.2 事务没生效库存扣了记录没生成现象接口报错后图书库存减少了但借阅记录不存在数据对不上账。原因Transactional注解标在了private方法上或者Service内部同类调用例如this.borrowBook()Spring的代理机制只在外部调用时生效同类调用会直接绕过代理事务注解形同虚设。解决事务注解必须放在public方法上且必须通过注入的Service对象调用不能在类内部用this调用如果确实需要同类调用把内部逻辑拆到另一个Service实现类中或者在配置文件里开启self-invocation支持后者副作用较多我一般不做推荐。5.3 MySQL连接池被慢查询拖垮现象系统运行一段时间后接口响应越来越慢日志里出现Connection is not available, request timed out。原因某条慢SQL占用连接时间过长连接池所有连接都被占满后续请求排队等连接最终超时。排查路径是打开MySQL慢查询日志定位最耗时的SQL。常见元凶是按isbn的模糊查询未加索引、分页查询offset过深、列表页一次性加载全部数据。解决为高频查询补索引分页改成id游标方式后台列表接口强制分页并限制单页最大行数同时对慢查询建立日常监控。5.4 时间字段的时区偏差逾期罚款算错一天现象还书时计算逾期天数结果总是比真实天数少8小时或差一天。原因MySQL连接参数未设置serverTimezone数据库与服务器所在时区不一致DATETIME类型在存储和读取时发生偏移。解决在JDBC连接串上明确指定时区例如serverTimezoneAsia/Shanghai数据库连接初始化后用一条SELECT NOW()验证时间与系统时间是否一致此外所有时间字段统一用DATETIME不要混用TIMESTAMP与DATETIME二者的时区处理规则并不相同。5.5 部署上线后登录状态串号现象A用户登录后B用户刷新页面发现自己进入了A的账号浏览器里没有任何异常。结合No significant connection to the viewers query.原因用的是JWT不涉及Session。真实场景里串号的常见来源是ThreadLocal的UserContext没有在请求结束后清理Tomcat的线程池把处理完A请求的线程复用来处理B请求残留的用户信息被B读到了。解决在拦截器的afterCompletion方法中显式调用UserContext.clear()每次请求结束都必须清空不能依赖GC同时在preHandle开始时先做一次清理双保险。注意以上五条坑前两条属于「并发/事务边界」问题后三条属于「环境/运行时」问题。前两条在开发环境下几乎无法复现需要压测工具制造并发请求才能暴露后三条在上线前通过模拟真实时间、真实流量就能提前暴露。做模拟项目X时至少要在部署环境里跑一遍5万条图书数据的导入和100并发请求的借还书压测。6. 从能跑到能扛压测、索引与缓存的三步进阶6.1 用数据量说话百万级数据下的分页与索引验证如果只停留在功能跑通这个系统的上限一眼就能看到。我用模拟项目X做过一次极限验证导入了80万条图书记录、10万条用户记录、200万条借阅记录。此时原本的模糊查询、深分页、多表联查都开始肉眼可见地变慢这正好是检验表结构与SQL设计的试金石。步骤如下。第一步生成压测数据脚本连续向book表批量插入数据。第二步执行高成本查询并观察执行计划重点看possible_keys与key是否一致type是否为ref或range出现ALL全表扫描就要加索引。第三步将普通分页改为基于游标的方式例如WHERE id lastId ORDER BY id DESC LIMIT 20这在深分页场景下的性能提升是数量级的。第四步对真实查询建立复合索引例如(category_id, status, create_time)让列表页一次索引扫描直接命中而无需回表。6.2 引入Redis缓存热点分类与图书详情图书管理系统的读写特点很明确图书详情的读请求远高于借还书的写请求。给图书详情加缓存是性价比最高的一项优化缓存策略我习惯这样设计首次查询图书详情时从MySQL加载并写入Redis过期时间设为30分钟图书库存扣减成功时删除或更新对应的缓存条目。如果担心瞬时高并发击穿缓存可以把缓存的双删策略做成延迟双删即在业务更新数据库后先删除缓存隔几百毫秒再删一次避免并发场景下旧数据被重新写回缓存。Redis在课程设计级别的项目中坚持「局部引入」即可不需要把整个系统改造成缓存架构。缓存覆盖范围只限定在图书详情、分类列表、首页热门推荐这三个高频读场景借阅记录、罚款记录这些统计类接口保持直接读库因为它们的查询模式是带用户维度的缓存命中率低反而增加一致性维护成本。6.3 接口验证的最终清单与上线习惯我在每个图书管理系统上线前都会走一遍下面的验证清单登录与权限是否覆盖所有写接口借阅时并发100请求压测是否出现库存为负数还书时逾期罚款计算与人工核算是否一致数据库连接串时区与服务器时区是否一致日志中是否存在慢查询告警管理端的分页接口是否带最大上限。我自己在这类项目上最深刻的教训是把大量精力花在编写新功能上却没有第一时间给自己的接口写自动化验证。等到联调阶段被反复打回才回头补测试。现在我的习惯是每写一个核心接口就同步落一个接口级验证用例数据库用测试库灌入固定数据跑一遍断言即通过。这个习惯让后续每一次重构都敢动手不至于打开一个模块就担心弄坏另一个模块。有了这套验证与上线习惯这个基于Spring Boot和MySQL的在线图书管理系统才真正具备了拿得出手的价值数据模型能支撑并发与扩展核心接口有事务与锁保护线上问题有清晰的排查路径。希望帮到你。本文还有配套的精品资源点击获取
