我在某社区做志愿活动的时候第一次看见了爱心书屋的运营现场。楼下那个旧书架摆了几百本捐赠书借阅信息全部记在纸质登记本上书的去向全凭志愿者脑补。后来我决定把整套流程数字化用SpringBoot搭了一个公益图书借阅平台把捐书、上架、借书、还书、逾期、捐赠公示全打通也正是毕设里常说的社区共享书屋数字化运营系统。这个题目看起来就是标准CRUD但真正做进去之后会发现状态流转、并发控制、事务边界、定时任务这些东西一个都躲不掉很值得写一篇完整实操记录。1. 爱心书屋的需求真相一本登记册暴露出的管理盲区我一开始和几个同学讨论题目时大家的第一反应都是借书还不简单建三张表用户表、图书表、借阅记录表剩下时间拿来刷题。但真去社区书屋蹲了两天现场想法立刻就变了。实体书和电商商品完全是两个物种每本书都有独立身份、有捐赠人、有架位、有磨损状态而且它的流转不是一次性买卖是借出去-还回来无限循环。登记册里那些涂改过期的记录背后全是业务漏洞。1.1 每本实体书都是一个独立的库存单元很多新手做图书系统时会把“书名”当成商品在图书表里放一个库存数量字段。这个思路放到共享书屋场景里是行不通的。捐赠者捐的是他手头那一本具体的书不是抽象的书名同一套《平凡的世界》可能有五个人各捐了一本这五本在架上就是五个独立个体各有各的架位码也各自有自己的状态。因为这一点book表设计成“一行代表一本实体书”是非常关键的决策。每本书的状态至少包括待审核、在库、借出、预占、下架、破损报废。字段设计大概是字段含义示例shelf_code架位编码A-03-02方便志愿者找书donor_id捐赠人用户ID用于捐赠公示溯源status当前图书状态ON_SHELF / LENT / RESERVEDversion乐观锁版本号并发更新时校验使用我见过有人把书的状态放在借阅记录里而不是图书身上带来的直接后果就是“查当前架上有什么书”这种基础功能都要join好几张表而且经常查出脏数据。书的状态必须属于书本身借阅记录只是它的流转日志。1.2 捐赠入库的审核与上架流程爱心书屋区别于普通书店的一个重要点就是书的来源是捐赠。捐书流程在纸质登记时代基本是“放下就走”但数字化之后至少要拆成提交、审核、上架三个环节。捐赠者在页面填写图书信息系统生成一条donation_record状态是待审核志愿者确认书籍品相、分类、录入架位码之后审核通过系统自动在book表里插入一条实体书记录同时把donation_record状态改成已上架。为什么要单独拆一张捐赠表而不直接把捐赠信息塞进book表因为审核过程中会有退回操作还要记录审核意见比如“品相太差不收”“少儿不宜不收”。这些信息属于捐赠流程本身不属于书的基本资料。多一张表换来的是流程可追溯。1.3 借阅规则要提前想清楚别在写代码时改来改去我在项目一开始就把借阅规则定成了可配置项放在sys_config表里而不是写死在代码里每个读者最多同时借2本默认借期30天可以续借1次续借15天逾期每天扣1个信用分信用分低于60分暂停借阅资格按时归还奖励1个信用分上限100分这些数字看着简单但它们会直接决定借还接口里有多少if判断、定时任务里怎么算逾期、积分模块怎么加减。后来社区志愿者跟我说想把可借本数改成3本管理员在后台配置页改个数字就生效不用重新部署这个细节在答辩时也很加分。2. 整体架构与数据模型给社区书屋设计一套可落地的状态机技术选型上我没有搞什么花活毕设项目讲究的是稳定、成熟、能说清楚。后端选了SpringBoot 2.7.xORM用的MyBatis-Plus数据库MySQL 8前端Vue3 Element Plus。Redis没做硬性依赖只把登录token随手放了进去这样就算学校服务器配置一般跑起来也不会有压力。Spring Security JWT做登录鉴权密码用BCrypt加密存储这些属于毕设项目的基础配置写进去基本不会出错。2.1 用状态机来管理图书和借阅记录而不是散落的if嵌套如果状态管理靠每个接口自己用if判断后期加一个“预约”功能时你会发现所有涉及状态的接口都要翻出来改一遍。我第一版就是这么干的结果改到吐。正确的做法是先定义清楚状态机然后在代码里用枚举或者常量表统一管理。图书状态流转待审核捐赠提交后的初始状态审核通过进入在库在库可被借阅也是归还后的默认落点借出被某位读者借走预占有读者预约了这本书归还后直接进入预约者名下不回到公共在库池下架/报废书籍损坏、丢失或管理员主动下架借阅记录状态流转对应的则是借阅中、已归还、已逾期、逾期已归还、违约。续借不算状态变化它只是把due_time往后推同时renew_count加1这一点很多人会误解成需要新状态。2.2 核心表结构设计整个系统我用到的关键表大概六张sys_user用户、book实体书、borrow_record借阅记录、donation_record捐赠记录、reserve_record预约记录、notice公告。业务查询高频集中在borrow_record和book上所以索引要提前留好。CREATE TABLE borrow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, book_id BIGINT NOT NULL, borrow_time DATETIME NOT NULL, due_time DATETIME NOT NULL, return_time DATETIME NULL, renew_count INT DEFAULT 0, status VARCHAR(20) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_status (user_id, status), INDEX idx_book_status (book_id, status) );这里特别要说明borrow_record里必须冗余user_id和book_id查询“某个读者当前借了哪几本”“某本书现在在谁手上”才能走索引快速返回。不要指望通过书的状态去join出历史记录查询性能会很差。2.3 为什么状态机设计比接口数量重要业务规则如果不集中管理借阅接口查一次状态、归还接口又查一次状态两边逻辑稍微不一致就会出现bug。比如借阅时允许借在库书归还时更新状态却忘了判断有没有人预约结果预约者永远等不到书。把状态机定义清楚之后所有状态迁移都收敛到几个统一方法里执行改规则只改一处。这个设计习惯对于毕设答辩来说是一个很拿得出手的亮点。3. 核心功能实现借阅、归还、续借背后的Java代码细节下面这部分我直接讲实现。先说明前端页面我不细讲核心价值都在后端的接口设计和数据一致性上。借阅流程做的不是“插入一条记录”这么简单它至少要完成五个步骤。3.1 借阅接口校验、加锁、写记录、改状态Transactional Override public Result borrow(Long userId, Long bookId) { User user userMapper.selectById(userId); if (user null || user.getStatus() ! 1) { return Result.fail(用户不存在或已被禁用); } if (user.getCredit() 60) { return Result.fail(信用分不足无法借阅); } long activeCount borrowRecordMapper.countActiveByUserId(userId); if (activeCount user.getMaxBorrowNum()) { return Result.fail(已达借阅上限); } // 注意这里使用了行锁 Book book bookMapper.selectByIdForUpdate(bookId); if (book null || !ON_SHELF.equals(book.getStatus())) { return Result.fail(当前书籍不可借阅); } BorrowRecord record new BorrowRecord(); record.setUserId(userId); record.setBookId(bookId); record.setBorrowTime(new Date()); record.setDueTime(DateUtil.offsetDay(new Date(), user.getBorrowDays())); record.setStatus(BORROWING); borrowRecordMapper.insert(record); bookMapper.updateStatus(bookId, LENT); return Result.ok(record); }selectByIdForUpdate是关键它会对book表中这一行数据加行级排他锁。两个用户同时借同一本书时后进入的事务必须等前一个事务提交或回滚才能读到最新状态这样就从数据库层面解决了超借问题。这里有个前提方法上必须有Transactional行锁要等事务提交才释放如果方法没有事务锁会在单条SQL执行完就释放等于白写。还有个小细节countActiveByUserId的SQL一定要加状态过滤只统计BORROWING和OVERDUE的记录如果统计里混进已归还记录借阅上限就形同虚设了。3.2 归还接口逾期计算与积分变动的联动归还时最核心的逻辑是算逾期天数。应还日期是6月1日实际还书是6月10日那就是逾期9天。按规则每天扣1分所以要扣9分。如果按时归还奖励1分。这个计算要在事务里跟状态更新一起完成避免出现记录状态改了但分没扣的情况。归还流程大致是根据recordId和userId查询借阅记录状态必须是BORROWING或OVERDUE计算逾期天数更新用户信用分公式为新积分 当前积分 - 逾期天数 按时奖励更新借阅记录状态为RETURNED、写入return_time判断该书有没有预约记录有则把book状态置为RESERVED并标记最早的预约人可借没有则置回ON_SHELF步骤5最容易被忽略。你想想一本预约状态的书如果被无脑放回在库池预约用户第一时间去借结果发现架上根本没有因为已经别人又被借走了这就是状态机不完整导致的线上bug。3.3 续借与预约两个容易出逻辑漏洞的点续借看起来只是把due_time往后挪但设防条件必须写全当前状态必须是BORROWING不能已逾期renew_count必须小于允许续借次数这本书当前不能有预约记录。三个条件全部满足才允许续借然后一次性更新due_time和renew_count别分成两次update减少中间态的暴露时间。预约功能则要保证同一用户对同一本书不能重复预约否则会占住队列位置。我用的reserve_record表每次插入前先查是否已有status为WAITING的记录。取预约用户时按照create_time升序排也就是先到先得。3.4 别小看索引借阅记录表会随着使用越来越臃肿书屋跑起来之后借还记录是只增不减的。就算只有几百个用户一年下来借阅记录也能轻松上万条。所以在设计表结构时就要把高频查询字段的索引建好。我不止一次见过因为没有索引首页“当前借出书籍列表”查询直接慢到秒级的情况。给borrow_record加上(user_id, status)联合索引给book加上status索引查询性能就能压到毫秒级这点成本几乎为零。4. 完成度与稳定性并发借阅、事务失效、定时任务三个实战坑这一节是全文最能帮你少走弯路的部分因为这些问题我在开发阶段全踩过。每一个坑的排查链路我都尽量复述出来比直接给结论有用得多。4.1 同一本书被两个人同时借走的并发问题第一版代码我没有加selectByIdForUpdate只做了“先查询status再插入记录再更新状态”的顺序操作。自测时一切正常因为单人操作根本不会触发并发直到我用两个浏览器同时登录测试才发现两个请求都读到了ON_SHELF状态都插入了borrow_record最后一本书被借给了两个人。排查链路是这样的先在MySQL日志里看两条请求的执行顺序确认没有等待锁的迹象再检查service方法上有没有Transactional确实有最后看SQL发现图书状态查询用的是普通selectById压根没走锁机制。根因清楚了修复就简单把查询改成SELECT ... FOR UPDATE再利用status条件做更新兜底UPDATE book SET status LENT WHERE id #{bookId} AND status ON_SHELF如果update返回影响行数为0说明这本书状态已经被别人改掉了事务直接回滚。行锁加条件更新双保险基本就不会出现超借了。4.2 Transactional不生效同类的内部方法调用这个坑更隐蔽。当时我把借阅和还书都放在同一个service类里为了复用逻辑直接在borrow方法里调用同类的另一个私有方法。结果测试时发现一旦内部方法抛异常前面的写操作居然没有回滚。后来查了Spring的文档才反应过来Transactional是基于AOP动态代理实现的通过this.xxx()调用的同类方法不会经过代理对象事务注解自然失效。这就是经典的自调用问题。解决方案有三种一是把被调用的方法拆到另一个service类里通过Spring注入后调用二是注入自身代理对象三是使用TransactionTemplate编程式事务。我最后选的是第三种因为它最直白让人一眼就能看出事务边界transactionTemplate.execute(status - { // 多个写操作 borrowRecordMapper.insert(record); bookMapper.updateStatus(bookId, LENT); return Boolean.TRUE; });这个教训我一直记着后来看项目代码时凡是事务失效问题第一反应就去查是不是同一个类内部调用。4.3 定时扫描逾期记录的幂等设计逾期判断不能只靠用户还书时触发万一有人几个月不还呢所以系统里加了一个每天凌晨2点执行的定时任务扫描所有BORROWING状态且due_time早于当前时间的记录把它们改成OVERDUE同时扣除信用分。这里最怕的是任务在扫描过程中重启导致同一条记录被处理两遍。我的处理方式是让状态更新本身带条件UPDATE borrow_record SET status OVERDUE WHERE id #{recordId} AND status BORROWING AND due_time NOW()update返回行数为1才执行扣分返回0说明已经被别的任务处理过了直接跳过。这种幂等写法比“先查再改”可靠得多即使定时任务重复执行也不会重复扣分。4.4 MyBatis-Plus默认行为带来的脏数据MyBatis-Plus确实好用但几个默认行为一定要提前知道。updateById默认不会更新null字段这本来是保护机制但如果你想主动把某个字段清空比如把图书的架位码置空直接传一个setShelfCode(null)根本不会生效。必须用UpdateWrapper显式set。另一个坑是TableField(fill FieldFill.INSERT)自动填充字段我在create_time上配置了自动填充结果业务代码里又手写了setCreateTime两边冲突日志里出现了奇怪的覆盖行为。后来统一原则填充字段只在元对象处理器里处理业务代码一律不碰。5. 社区运营视角从能借书到愿意持续用的数字细节很多人做管理系统止步于CRUD但爱心书屋这种公益项目真正考验人的是怎么让志愿者愿意用、让捐赠者信得过、让读者觉得方便。所以我在功能清单里额外加了几个运营向的模块。5.1 数据看板让志愿者一眼看清全局管理端首页我放了一个数据看板包括当前在库图书数量、借出数量、今日归还数、待审核捐赠数、预约未处理数下面再用ECharts画两张图近30天借阅趋势和分类借阅占比。热榜的实现很简单就是对借阅记录按图书ID分组统计SELECT b.id, b.title, COUNT(r.id) AS borrow_count FROM borrow_record r JOIN book b ON r.book_id b.id GROUP BY r.book_id ORDER BY borrow_count DESC LIMIT 10趋势图则用DATE_FORMAT(borrow_time, %Y-%m-%d)做分组统计。这些查询对MySQL来说都是毫秒级的但带来的运营价值却很大志愿者能看出哪个分类最受欢迎、最近活动效果怎么样而这些在纸质登记时代根本无从谈起。5.2 捐赠公示公益透明感是信任的基础爱心书屋的性质决定了它必须让捐赠者看到自己的书到底去了哪。所以我在前台做了一个捐赠公示页面每一本捐赠书都会展示捐赠人昵称、捐赠时间、图书当前状态以及累计借阅次数。状态是动态算出来的显示“已被××借走”还是“存放在A区03架”一目了然。这个模块技术上没有难度难的是理念公益类系统一定要把“透明度”当成功能来做而不是当作锦上添花。答辩时如果只讲技术评审老师可能觉得一般但把“为什么做捐赠公示”“数据如何联动”讲清楚项目立意就上来了。5.3 公告与阅读活动让平台不止是借还工具社区书屋的定位是社区公共文化空间所以我在系统里还加了公告管理和阅读活动报名。志愿者可以发布周末读书会的公告并关联一个活动报名表单读者在前台报名。活动模块的表结构很简单notice表里加一个activity_flag字段区分普通公告和活动再建一张activity_signup表记录报名人和活动ID。做的时候别贪大能完成“发布-展示-报名-取消报名”闭环就够了这已经是一个很完整的社区运营小场景。6. 毕设防坑指南我从这个项目里拿到的几条实在经验做完整个项目我最大的感受是毕设不一定要功能多但一定要让你踩过的坑有说头。如果你准备选类似题或者已经开始写了下面几条经验应该能帮你省不少事。6.1 先画状态机再建表至少省一周改表时间我是先建了表才去理状态流的结果后期加预约功能时表的字段改了三回接口逻辑也大面积返工。你写代码之前先把图书状态和借阅记录状态的所有流转路径写在纸上甚至把每个状态迁移对应的接口列出来再动手写建表SQL。这件事花不了一下午但能让你后面开发顺畅很多。6.2 准备一套高质量的演示数据系统写完除了自测还要准备一套像样的演示数据。至少要模拟30本图书、分布在5个分类里3个读者账号几十条借阅记录让热榜和趋势图有东西可画再故意制造一条逾期未还记录让逾期定时任务的效果可以现场演示。演示的时候别只点菜单要讲一个完整故事先看数据看板然后模拟捐赠者捐一本书志愿者审核上架读者借走再到归还回看数据看板变化。这一套走下来功能点覆盖得七七八八也比零散点页面有逻辑得多。6.3 答辩时讲透一个难点胜过罗列十个功能选这个题目的同学普遍会担心项目不够难。实际上只要做深一个点完全够讲。我最建议讲的就是借阅并发控制为什么用行锁、锁在什么范围生效、事务边界在哪、如果不用锁会出现什么后果。这个点串着数据库原理和Spring事务机制技术含量比做十个简单功能高得多。我当时的经验是把问题用十分钟讲透给评审留下的印象远好过把每个菜单念一遍。6.4 两个值得继续扩展的方向如果做完还有时间我建议从两个方向往上延伸。一个是移动端接入把借书功能搬到手机上扫码借书、预约通知推送体验会提升一大截另一个是基于借阅记录做简单的推荐按分类偏好给用户推书数据基础已经有了加一个推荐接口并不复杂。两个方向都能让这个公益图书借阅平台更有完整度论文后续也有东西可写。最后说一句实在话爱心书屋管理系统表面上是人人都会做的图书CRUD但只要你把它当成一个真实要运营的社区产品状态并发这些硬骨头很快就暴露出来啃下来之后你对SpringBoot的理解绝对比刷一百道面经题都深刻。
我在某社区做志愿活动的时候第一次看见了爱心书屋的运营现场。楼下那个旧书架摆了几百本捐赠书借阅信息全部记在纸质登记本上书的去向全凭志愿者脑补。后来我决定把整套流程数字化用SpringBoot搭了一个公益图书借阅平台把捐书、上架、借书、还书、逾期、捐赠公示全打通也正是毕设里常说的社区共享书屋数字化运营系统。这个题目看起来就是标准CRUD但真正做进去之后会发现状态流转、并发控制、事务边界、定时任务这些东西一个都躲不掉很值得写一篇完整实操记录。1. 爱心书屋的需求真相一本登记册暴露出的管理盲区我一开始和几个同学讨论题目时大家的第一反应都是借书还不简单建三张表用户表、图书表、借阅记录表剩下时间拿来刷题。但真去社区书屋蹲了两天现场想法立刻就变了。实体书和电商商品完全是两个物种每本书都有独立身份、有捐赠人、有架位、有磨损状态而且它的流转不是一次性买卖是借出去-还回来无限循环。登记册里那些涂改过期的记录背后全是业务漏洞。1.1 每本实体书都是一个独立的库存单元很多新手做图书系统时会把“书名”当成商品在图书表里放一个库存数量字段。这个思路放到共享书屋场景里是行不通的。捐赠者捐的是他手头那一本具体的书不是抽象的书名同一套《平凡的世界》可能有五个人各捐了一本这五本在架上就是五个独立个体各有各的架位码也各自有自己的状态。因为这一点book表设计成“一行代表一本实体书”是非常关键的决策。每本书的状态至少包括待审核、在库、借出、预占、下架、破损报废。字段设计大概是字段含义示例shelf_code架位编码A-03-02方便志愿者找书donor_id捐赠人用户ID用于捐赠公示溯源status当前图书状态ON_SHELF / LENT / RESERVEDversion乐观锁版本号并发更新时校验使用我见过有人把书的状态放在借阅记录里而不是图书身上带来的直接后果就是“查当前架上有什么书”这种基础功能都要join好几张表而且经常查出脏数据。书的状态必须属于书本身借阅记录只是它的流转日志。1.2 捐赠入库的审核与上架流程爱心书屋区别于普通书店的一个重要点就是书的来源是捐赠。捐书流程在纸质登记时代基本是“放下就走”但数字化之后至少要拆成提交、审核、上架三个环节。捐赠者在页面填写图书信息系统生成一条donation_record状态是待审核志愿者确认书籍品相、分类、录入架位码之后审核通过系统自动在book表里插入一条实体书记录同时把donation_record状态改成已上架。为什么要单独拆一张捐赠表而不直接把捐赠信息塞进book表因为审核过程中会有退回操作还要记录审核意见比如“品相太差不收”“少儿不宜不收”。这些信息属于捐赠流程本身不属于书的基本资料。多一张表换来的是流程可追溯。1.3 借阅规则要提前想清楚别在写代码时改来改去我在项目一开始就把借阅规则定成了可配置项放在sys_config表里而不是写死在代码里每个读者最多同时借2本默认借期30天可以续借1次续借15天逾期每天扣1个信用分信用分低于60分暂停借阅资格按时归还奖励1个信用分上限100分这些数字看着简单但它们会直接决定借还接口里有多少if判断、定时任务里怎么算逾期、积分模块怎么加减。后来社区志愿者跟我说想把可借本数改成3本管理员在后台配置页改个数字就生效不用重新部署这个细节在答辩时也很加分。2. 整体架构与数据模型给社区书屋设计一套可落地的状态机技术选型上我没有搞什么花活毕设项目讲究的是稳定、成熟、能说清楚。后端选了SpringBoot 2.7.xORM用的MyBatis-Plus数据库MySQL 8前端Vue3 Element Plus。Redis没做硬性依赖只把登录token随手放了进去这样就算学校服务器配置一般跑起来也不会有压力。Spring Security JWT做登录鉴权密码用BCrypt加密存储这些属于毕设项目的基础配置写进去基本不会出错。2.1 用状态机来管理图书和借阅记录而不是散落的if嵌套如果状态管理靠每个接口自己用if判断后期加一个“预约”功能时你会发现所有涉及状态的接口都要翻出来改一遍。我第一版就是这么干的结果改到吐。正确的做法是先定义清楚状态机然后在代码里用枚举或者常量表统一管理。图书状态流转待审核捐赠提交后的初始状态审核通过进入在库在库可被借阅也是归还后的默认落点借出被某位读者借走预占有读者预约了这本书归还后直接进入预约者名下不回到公共在库池下架/报废书籍损坏、丢失或管理员主动下架借阅记录状态流转对应的则是借阅中、已归还、已逾期、逾期已归还、违约。续借不算状态变化它只是把due_time往后推同时renew_count加1这一点很多人会误解成需要新状态。2.2 核心表结构设计整个系统我用到的关键表大概六张sys_user用户、book实体书、borrow_record借阅记录、donation_record捐赠记录、reserve_record预约记录、notice公告。业务查询高频集中在borrow_record和book上所以索引要提前留好。CREATE TABLE borrow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, book_id BIGINT NOT NULL, borrow_time DATETIME NOT NULL, due_time DATETIME NOT NULL, return_time DATETIME NULL, renew_count INT DEFAULT 0, status VARCHAR(20) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_status (user_id, status), INDEX idx_book_status (book_id, status) );这里特别要说明borrow_record里必须冗余user_id和book_id查询“某个读者当前借了哪几本”“某本书现在在谁手上”才能走索引快速返回。不要指望通过书的状态去join出历史记录查询性能会很差。2.3 为什么状态机设计比接口数量重要业务规则如果不集中管理借阅接口查一次状态、归还接口又查一次状态两边逻辑稍微不一致就会出现bug。比如借阅时允许借在库书归还时更新状态却忘了判断有没有人预约结果预约者永远等不到书。把状态机定义清楚之后所有状态迁移都收敛到几个统一方法里执行改规则只改一处。这个设计习惯对于毕设答辩来说是一个很拿得出手的亮点。3. 核心功能实现借阅、归还、续借背后的Java代码细节下面这部分我直接讲实现。先说明前端页面我不细讲核心价值都在后端的接口设计和数据一致性上。借阅流程做的不是“插入一条记录”这么简单它至少要完成五个步骤。3.1 借阅接口校验、加锁、写记录、改状态Transactional Override public Result borrow(Long userId, Long bookId) { User user userMapper.selectById(userId); if (user null || user.getStatus() ! 1) { return Result.fail(用户不存在或已被禁用); } if (user.getCredit() 60) { return Result.fail(信用分不足无法借阅); } long activeCount borrowRecordMapper.countActiveByUserId(userId); if (activeCount user.getMaxBorrowNum()) { return Result.fail(已达借阅上限); } // 注意这里使用了行锁 Book book bookMapper.selectByIdForUpdate(bookId); if (book null || !ON_SHELF.equals(book.getStatus())) { return Result.fail(当前书籍不可借阅); } BorrowRecord record new BorrowRecord(); record.setUserId(userId); record.setBookId(bookId); record.setBorrowTime(new Date()); record.setDueTime(DateUtil.offsetDay(new Date(), user.getBorrowDays())); record.setStatus(BORROWING); borrowRecordMapper.insert(record); bookMapper.updateStatus(bookId, LENT); return Result.ok(record); }selectByIdForUpdate是关键它会对book表中这一行数据加行级排他锁。两个用户同时借同一本书时后进入的事务必须等前一个事务提交或回滚才能读到最新状态这样就从数据库层面解决了超借问题。这里有个前提方法上必须有Transactional行锁要等事务提交才释放如果方法没有事务锁会在单条SQL执行完就释放等于白写。还有个小细节countActiveByUserId的SQL一定要加状态过滤只统计BORROWING和OVERDUE的记录如果统计里混进已归还记录借阅上限就形同虚设了。3.2 归还接口逾期计算与积分变动的联动归还时最核心的逻辑是算逾期天数。应还日期是6月1日实际还书是6月10日那就是逾期9天。按规则每天扣1分所以要扣9分。如果按时归还奖励1分。这个计算要在事务里跟状态更新一起完成避免出现记录状态改了但分没扣的情况。归还流程大致是根据recordId和userId查询借阅记录状态必须是BORROWING或OVERDUE计算逾期天数更新用户信用分公式为新积分 当前积分 - 逾期天数 按时奖励更新借阅记录状态为RETURNED、写入return_time判断该书有没有预约记录有则把book状态置为RESERVED并标记最早的预约人可借没有则置回ON_SHELF步骤5最容易被忽略。你想想一本预约状态的书如果被无脑放回在库池预约用户第一时间去借结果发现架上根本没有因为已经别人又被借走了这就是状态机不完整导致的线上bug。3.3 续借与预约两个容易出逻辑漏洞的点续借看起来只是把due_time往后挪但设防条件必须写全当前状态必须是BORROWING不能已逾期renew_count必须小于允许续借次数这本书当前不能有预约记录。三个条件全部满足才允许续借然后一次性更新due_time和renew_count别分成两次update减少中间态的暴露时间。预约功能则要保证同一用户对同一本书不能重复预约否则会占住队列位置。我用的reserve_record表每次插入前先查是否已有status为WAITING的记录。取预约用户时按照create_time升序排也就是先到先得。3.4 别小看索引借阅记录表会随着使用越来越臃肿书屋跑起来之后借还记录是只增不减的。就算只有几百个用户一年下来借阅记录也能轻松上万条。所以在设计表结构时就要把高频查询字段的索引建好。我不止一次见过因为没有索引首页“当前借出书籍列表”查询直接慢到秒级的情况。给borrow_record加上(user_id, status)联合索引给book加上status索引查询性能就能压到毫秒级这点成本几乎为零。4. 完成度与稳定性并发借阅、事务失效、定时任务三个实战坑这一节是全文最能帮你少走弯路的部分因为这些问题我在开发阶段全踩过。每一个坑的排查链路我都尽量复述出来比直接给结论有用得多。4.1 同一本书被两个人同时借走的并发问题第一版代码我没有加selectByIdForUpdate只做了“先查询status再插入记录再更新状态”的顺序操作。自测时一切正常因为单人操作根本不会触发并发直到我用两个浏览器同时登录测试才发现两个请求都读到了ON_SHELF状态都插入了borrow_record最后一本书被借给了两个人。排查链路是这样的先在MySQL日志里看两条请求的执行顺序确认没有等待锁的迹象再检查service方法上有没有Transactional确实有最后看SQL发现图书状态查询用的是普通selectById压根没走锁机制。根因清楚了修复就简单把查询改成SELECT ... FOR UPDATE再利用status条件做更新兜底UPDATE book SET status LENT WHERE id #{bookId} AND status ON_SHELF如果update返回影响行数为0说明这本书状态已经被别人改掉了事务直接回滚。行锁加条件更新双保险基本就不会出现超借了。4.2 Transactional不生效同类的内部方法调用这个坑更隐蔽。当时我把借阅和还书都放在同一个service类里为了复用逻辑直接在borrow方法里调用同类的另一个私有方法。结果测试时发现一旦内部方法抛异常前面的写操作居然没有回滚。后来查了Spring的文档才反应过来Transactional是基于AOP动态代理实现的通过this.xxx()调用的同类方法不会经过代理对象事务注解自然失效。这就是经典的自调用问题。解决方案有三种一是把被调用的方法拆到另一个service类里通过Spring注入后调用二是注入自身代理对象三是使用TransactionTemplate编程式事务。我最后选的是第三种因为它最直白让人一眼就能看出事务边界transactionTemplate.execute(status - { // 多个写操作 borrowRecordMapper.insert(record); bookMapper.updateStatus(bookId, LENT); return Boolean.TRUE; });这个教训我一直记着后来看项目代码时凡是事务失效问题第一反应就去查是不是同一个类内部调用。4.3 定时扫描逾期记录的幂等设计逾期判断不能只靠用户还书时触发万一有人几个月不还呢所以系统里加了一个每天凌晨2点执行的定时任务扫描所有BORROWING状态且due_time早于当前时间的记录把它们改成OVERDUE同时扣除信用分。这里最怕的是任务在扫描过程中重启导致同一条记录被处理两遍。我的处理方式是让状态更新本身带条件UPDATE borrow_record SET status OVERDUE WHERE id #{recordId} AND status BORROWING AND due_time NOW()update返回行数为1才执行扣分返回0说明已经被别的任务处理过了直接跳过。这种幂等写法比“先查再改”可靠得多即使定时任务重复执行也不会重复扣分。4.4 MyBatis-Plus默认行为带来的脏数据MyBatis-Plus确实好用但几个默认行为一定要提前知道。updateById默认不会更新null字段这本来是保护机制但如果你想主动把某个字段清空比如把图书的架位码置空直接传一个setShelfCode(null)根本不会生效。必须用UpdateWrapper显式set。另一个坑是TableField(fill FieldFill.INSERT)自动填充字段我在create_time上配置了自动填充结果业务代码里又手写了setCreateTime两边冲突日志里出现了奇怪的覆盖行为。后来统一原则填充字段只在元对象处理器里处理业务代码一律不碰。5. 社区运营视角从能借书到愿意持续用的数字细节很多人做管理系统止步于CRUD但爱心书屋这种公益项目真正考验人的是怎么让志愿者愿意用、让捐赠者信得过、让读者觉得方便。所以我在功能清单里额外加了几个运营向的模块。5.1 数据看板让志愿者一眼看清全局管理端首页我放了一个数据看板包括当前在库图书数量、借出数量、今日归还数、待审核捐赠数、预约未处理数下面再用ECharts画两张图近30天借阅趋势和分类借阅占比。热榜的实现很简单就是对借阅记录按图书ID分组统计SELECT b.id, b.title, COUNT(r.id) AS borrow_count FROM borrow_record r JOIN book b ON r.book_id b.id GROUP BY r.book_id ORDER BY borrow_count DESC LIMIT 10趋势图则用DATE_FORMAT(borrow_time, %Y-%m-%d)做分组统计。这些查询对MySQL来说都是毫秒级的但带来的运营价值却很大志愿者能看出哪个分类最受欢迎、最近活动效果怎么样而这些在纸质登记时代根本无从谈起。5.2 捐赠公示公益透明感是信任的基础爱心书屋的性质决定了它必须让捐赠者看到自己的书到底去了哪。所以我在前台做了一个捐赠公示页面每一本捐赠书都会展示捐赠人昵称、捐赠时间、图书当前状态以及累计借阅次数。状态是动态算出来的显示“已被××借走”还是“存放在A区03架”一目了然。这个模块技术上没有难度难的是理念公益类系统一定要把“透明度”当成功能来做而不是当作锦上添花。答辩时如果只讲技术评审老师可能觉得一般但把“为什么做捐赠公示”“数据如何联动”讲清楚项目立意就上来了。5.3 公告与阅读活动让平台不止是借还工具社区书屋的定位是社区公共文化空间所以我在系统里还加了公告管理和阅读活动报名。志愿者可以发布周末读书会的公告并关联一个活动报名表单读者在前台报名。活动模块的表结构很简单notice表里加一个activity_flag字段区分普通公告和活动再建一张activity_signup表记录报名人和活动ID。做的时候别贪大能完成“发布-展示-报名-取消报名”闭环就够了这已经是一个很完整的社区运营小场景。6. 毕设防坑指南我从这个项目里拿到的几条实在经验做完整个项目我最大的感受是毕设不一定要功能多但一定要让你踩过的坑有说头。如果你准备选类似题或者已经开始写了下面几条经验应该能帮你省不少事。6.1 先画状态机再建表至少省一周改表时间我是先建了表才去理状态流的结果后期加预约功能时表的字段改了三回接口逻辑也大面积返工。你写代码之前先把图书状态和借阅记录状态的所有流转路径写在纸上甚至把每个状态迁移对应的接口列出来再动手写建表SQL。这件事花不了一下午但能让你后面开发顺畅很多。6.2 准备一套高质量的演示数据系统写完除了自测还要准备一套像样的演示数据。至少要模拟30本图书、分布在5个分类里3个读者账号几十条借阅记录让热榜和趋势图有东西可画再故意制造一条逾期未还记录让逾期定时任务的效果可以现场演示。演示的时候别只点菜单要讲一个完整故事先看数据看板然后模拟捐赠者捐一本书志愿者审核上架读者借走再到归还回看数据看板变化。这一套走下来功能点覆盖得七七八八也比零散点页面有逻辑得多。6.3 答辩时讲透一个难点胜过罗列十个功能选这个题目的同学普遍会担心项目不够难。实际上只要做深一个点完全够讲。我最建议讲的就是借阅并发控制为什么用行锁、锁在什么范围生效、事务边界在哪、如果不用锁会出现什么后果。这个点串着数据库原理和Spring事务机制技术含量比做十个简单功能高得多。我当时的经验是把问题用十分钟讲透给评审留下的印象远好过把每个菜单念一遍。6.4 两个值得继续扩展的方向如果做完还有时间我建议从两个方向往上延伸。一个是移动端接入把借书功能搬到手机上扫码借书、预约通知推送体验会提升一大截另一个是基于借阅记录做简单的推荐按分类偏好给用户推书数据基础已经有了加一个推荐接口并不复杂。两个方向都能让这个公益图书借阅平台更有完整度论文后续也有东西可写。最后说一句实在话爱心书屋管理系统表面上是人人都会做的图书CRUD但只要你把它当成一个真实要运营的社区产品状态并发这些硬骨头很快就暴露出来啃下来之后你对SpringBoot的理解绝对比刷一百道面经题都深刻。
![打卡信奥刷题（3644）用C++实现信奥题 P12027 [USACO25OPEN] Ski Slope S](http://pic.xiahunao.cn/yaotu/打卡信奥刷题（3644）用C++实现信奥题 P12027 [USACO25OPEN] Ski Slope S)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
