企业官网建设流程全解析

去年帮某高校的一位学弟做毕设，对方只丢过来一句话：“想做一个高校共享图书借阅的小程序，后端用Spring Boot。”这句话听起来不难，但真正动手才发现，共享借阅这事儿背后藏着一整条业务链：用户身份认证、图书发布与审核、借阅状态流转、逾期处理、消息通知，还得应付小程序端各种诡异的兼容问题。这篇文章就把整个项目从需求到落地的过程完整拆一遍，内容包括技术选型为什么是Spring Boot + 小程序、数据库表怎么设计、核心接口怎么实现、小程序端怎么联调、最后上线要注意什么。适合正在做同类课题的人照着抄，也适合想快速上手Spring Boot + 微信小程序全栈开发的读者。

1. 高校共享图书借阅小程序的项目画像与需求拆解

1.1 这个题目到底在做什么

把标题拆开看，核心是“高校共享图书借阅”，载体是“小程序”，后端技术是“java基于springboot”。它的业务本质不是什么新鲜东西，就是让高校里的学生把自己的闲置图书放到平台上，其他学生可以检索、借阅、归还，实现图书在校内循环流通。和校园图书馆系统最大的区别在于，图书来源不是学校采购，而是学生个人共享，所以天然带有“C2C”的属性。

这个定位决定了系统不能只做借阅管理，还要处理图书共享者、借阅者、管理员三方之间的协作。比如一本图书被上传后，要不要审核？审核通过后谁来保管？借阅者怎么联系到共享者？归还后怎么确认图书完好？这些问题在传统图书馆系统里根本不需要考虑，但在共享模式下都是绕不开的细节。

做项目时最容易犯的错，就是一上来先写代码，结果写到一半发现业务逻辑对不上。所以拿到这种题目，第一步一定是把“人、书、流程”梳理清楚。

1.2 需求拆解：共享、借阅、高校三个词

“高校”这个词给系统加上了很强的边界条件。首先是用户范围：基本限定在校内学生和教职工，所以需要学号/工号认证，而不是像开放平台一样随便注册。其次是借阅半径：图书需要在校园内流转，所以校区、宿舍楼这类位置信息很有用，方便共享者和借阅者约定取书地点。

“共享”意味着每个用户都可以是图书的贡献者。这里要区分两个概念：发布图书不等于直接挂卖，而是“我愿意把这本书借给别人”。所以系统要支持个人书架管理、图书上下架、共享状态展示。上传图书时最好能通过ISBN自动填充书名、作者、封面等信息，减少用户手动输入成本。

“借阅”是整个系统的核心动作。借阅流程不是简单地把书从A手里给到B手里，它包含申请、确认、取书、归还、评价等多个节点。系统必须记录每一本书当前在哪里、在谁手上、状态是否正常。这也是后文数据库状态机设计的动因。

如果把需求做成一张功能清单，大概长这样：

• 用户端：微信登录、学号绑定、个人信息维护、我的借阅、我的共享、收藏、消息中心。
• 图书端：发布共享图书、图书检索、图书详情、扫码查看、借阅申请、确认借出、确认归还。
• 管理端：图书审核、用户管理、借阅记录查看、违规处理、数据统计。

1.3 核心用户角色与主流程

系统一共三类角色：共享者、借阅者、管理员。一个人可以既是共享者又是借阅者，这很常见。重点在于流程设计上要把“申请—确认—取书—归还—确认”这个链条走通。

以一次完整的借阅为例：

1. 借阅者在小程序里搜索图书，查看详情，确认可借之后点击“申请借阅”。
2. 系统创建一条借阅单，状态为“待确认”，同时通知共享者。
3. 共享者看到申请后，可以选择“同意借出”或“拒绝”。
4. 同意后，双方线下碰面取书，共享者在系统里点击“确认已借出”，借阅单状态变为“借用中”。
5. 借阅者阅读完后，在小程序里点击“申请归还”，状态变为“待归还确认”。
6. 共享者收到消息后，确认图书完好并点击“确认归还”，状态变为“已归还”。

这个流程看起来清晰，但每一步都要考虑异常情况：申请被拒绝了怎么办？借出去之后对方一直不还怎么办？图书丢失了怎么办？这些在设计阶段就要想清楚，不能等编码的时候再临时拍脑袋。下面是简化版的角色权限边界：

• 共享者可以管理自己发布的图书、处理借阅申请、确认借出和归还。
• 借阅者可以搜索图书、发起申请、确认归还、查看借阅历史。
• 管理员可以审核图书、查看全平台借阅数据、处理纠纷、封禁违规账号。

2. 技术选型决策：Spring Boot + 小程序的组合逻辑

2.1 为什么后端选Spring Boot而不是其他框架

技术选型不能只看“流行”，要看团队熟悉度和项目场景。大多数高校项目团队对Java最熟，而Spring Boot在Java后端里几乎是事实标准，选它几乎没有试错成本。对比一下其他方案：用Python的Flask/Django也完全能做，但很多同学的Java课件、毕业设计模板、资料都是围绕Spring Boot展开的，后续查资料、写论文都能省不少时间。

Spring Boot真正的优势体现在这几个方面：

一是自动配置，不用像Spring MVC那样写一堆xml配置文件，起步快。二是生态成熟，Spring Data JPA、MyBatis-Plus、Spring Security、Redis、RabbitMQ都有对应的starter，项目做到后期要加缓存、加消息队列都方便。三是对小程序后端这种典型的JSON API服务支持很到位，默认的Jackson序列化、Spring MVC注解、全局异常处理机制，写接口效率非常高。

在这个项目里，我选了Spring Boot 2.7.x版本，搭配MyBatis-Plus作为ORM框架。为什么不选JPA？因为这类借阅系统查询条件很杂，比如按书名模糊搜索、按状态筛选、分页排序，MyBatis-Plus的条件构造器写起来更直观，SQL也能自己控制，出了问题好排查。

2.2 小程序端为什么是微信小程序不是App/H5

高校场景下，用户的使用习惯是“即用即走”。微信小程序不需要下载安装，扫码或者搜索就能打开，传播成本低。相比之下，独立App需要安装、需要维护两个平台，对毕设项目来说工作量直接翻倍。H5虽然也可以，但在调用微信登录、扫码、订阅消息这些能力时，体验不如原生小程序自然。

小程序端的技术方案也有讲究。目前主流有三条路：原生小程序、uni-app、Taro。我当时选了原生小程序，原因是项目本身不复杂，页面数量大概在十五个以内，原生开发足够。如果你还想打包成其他平台，或者团队里有人更熟悉Vue，那选uni-app会更合适。但要注意，uni-app在自定义组件和第三方插件适配上有时候会踩坑，调试成本并不比原生低。

登录这块要重点说明：小程序端用微信授权登录获取code，后端拿着code调用微信的接口换取openid和session_key，然后用jwt生成一个自定义token返回给小程序。注意，不能直接把openid当token用，一是没有过期机制，二是接口一旦被抓包，等于用户身份完全暴露。

2.3 关键技术栈与版本约定

这个项目的完整技术栈如下：

• 开发环境：JDK 1.8、Maven 3.6+、Node.js 16+、微信开发者工具。
• 后端：Spring Boot 2.7.x、MyBatis-Plus 3.5.x、MySQL 8.0、Redis 5.x、JWT（jjwt 0.9.x）。
• 小程序端：原生微信小程序、Vant Weapp组件库、微信订阅消息。
• 工具类：Hutool、Lombok、Apache Commons Lang3。

为什么MySQL要选8.0？因为8.0对JSON字段、窗口函数的支持更好，而且默认字符集utf8mb4，能正确存emoji表情。图书备注里如果出现了特殊符号，老版本utf8可能会有问题。Redis在这个项目里主要做两件事：一是缓存图书检索的热点数据，二是做借阅申请时的分布式锁，防止同一本书被并发申请。项目规模不大，这两个场景用Redis足够，不需要再引入消息队列。

版本选择上有个经验：不要一上来就追最新版。Spring Boot 3.x虽然已经发布，但要求JDK 17，很多同学本机还是JDK 8，而且3.x的javax换成了jakarta，很多老教程直接作废。选2.7.x是最稳妥的，网上资料最多，遇到问题百度一下基本都能解决。

3. 数据库设计：表结构、状态机与并发控制

3.1 实体关系梳理

数据库设计是整个项目的根基。很多同学喜欢直接按页面反推表，这种做法容易漏掉业务状态。我习惯先梳理实体关系，再落到建表语句。

核心实体有五个：用户、图书、借阅单、收藏、消息。它们之间的关系如下：

• 用户与图书：一对多，一个用户可以共享多本图书。
• 用户与借阅单：借阅者角度，一个用户可以发出多个借阅申请；共享者角度，一个用户可收到多个借阅申请。所以用借阅单表同时记录共享者ID和借阅者ID。
• 图书与借阅单：一对多，一本图书可以有多条借阅历史，但同一时间只能有一条“进行中”的记录。
• 用户与收藏：一对多。
• 用户与消息：一对多。

画完关系图后会发现，借阅单是整个系统最核心的表。它既要关联图书，又要关联两个用户，还要记录每个状态变更的时间点，所以字段设计必须非常完整。

3.2 核心表结构与字段设计

下面挑几张核心表来说明。建表语句就不整段贴了，字段设计更有参考价值。

用户表（t_user）：

• id：主键，自增。
• openid：微信openid，唯一。
• nickname：昵称。
• avatar：头像URL。
• student_no：学号，唯一，可空。
• real_name：真实姓名，学号绑定时填写。
• campus：所属校区。
• phone：手机号。
• role：角色，1普通用户，2管理员。
• status：状态，1正常，0封禁。
• create_time、update_time。

图书表（t_book）：

• id：主键。
• isbn：ISBN号，便于调用第三方API补全信息。
• title：书名。
• author：作者。
• publisher：出版社。
• cover：封面图URL。
• description：图书描述。
• owner_id：共享者ID，关联用户表。
• status：图书状态，0待审核，1可借，2已借出，3已下架，4审核拒绝。
• location：取书地点，如“3号宿舍楼A栋一楼大厅”。
• borrow_count：累计借阅次数。
• create_time、update_time。

关键字段status一定要用数字存，不要用字符串，因为后续做条件查询和数据统计时，数字比字符串更高效。另一个容易忽略的点是，图书表里没有直接存“当前借阅者ID”，这个信息要通过借阅单表查。原因是借阅单要记录完整的历史轨迹，如果直接在图书表冗余一个current_borrower_id，历史查询会变得很别扭。

借阅单表（t_borrow_record）：

• id：主键。
• book_id：图书ID。
• borrower_id：借阅者ID。
• owner_id：共享者ID。
• status：借阅状态，0待确认，1已同意（待取书），2借用中，3申请归还，4已归还，5已拒绝，6已取消，7已逾期。
• apply_time：申请时间。
• confirm_time：共享者同意时间。
• borrow_time：确认借出时间。
• return_apply_time：归还申请时间。
• return_time：实际归还时间。
• due_time：应还时间。
• remark：备注，如“约好周三下午取书”。

这张表加了两个索引：一个复合索引(owner_id, status)，方便共享者查看自己的待办；另一个复合索引(borrower_id, status)，方便借阅者查看我的借阅。表设计阶段就要考虑查询场景，不要等SQL跑慢了再补索引。

3.3 借阅状态机与超时释放策略

借阅单的状态流转不能靠脑补，最好画成状态机，然后把状态迁移规则写进代码。状态机如下：

待确认 -> 已同意 待确认 -> 已拒绝 待确认 -> 已取消（借阅者发起） 已同意 -> 借用中（共享者确认已借出） 借用中 -> 申请归还（借阅者发起） 申请归还 -> 已归还（共享者确认） 借用中/申请归还 -> 已逾期（定时任务触发）

这里最容易出问题的是“待确认”和“已同意”这两个状态。比如借阅者提交申请后，共享者一直不处理，这条记录就会挂在那里。所以需要设定超时策略：申请超过24小时未确认，自动变为“已取消”，同时释放图书的可借状态；共享者同意借出后，如果48小时内没有确认“已借出”，自动取消并释放图书。

这样做的好处是，图书状态的变更始终有据可依，不会出现一本书在系统里显示“可借”，但实际已经被某个人占用了的情况。释放逻辑一定要放在借阅单状态变更的同时。如果你把“图书状态改为可借”和“借阅单状态改为已取消”分开写，很可能因为某个接口报错造成数据不一致。

并发控制方面，最关键的是“一本书不能被多个人同时申请借阅”。解决方案有两种：一是数据库层面用乐观锁，在图书表加version字段，update时带上version；二是借阅申请前用Redis的setnx加锁。我推荐两种结合：Redis锁拦住高并发请求，数据库乐观锁兜底。这样即便Redis没锁住，数据库更新时也会因为version不匹配而失败，从而保证只有一个人能申请成功。

4. 后端核心实现：从登录到借阅全链路

4.1 微信登录与Token认证

后端的第一道关卡是登录认证。小程序端调用wx.login拿到code，请求后端接口，后端再用code调用微信的code2Session接口换取openid和session_key。

微信接口调用建议封装成单独的服务类。用Hutool的HttpUtil发起请求，然后解析返回的JSON。拿到openid后先查用户表是否已存在，如果不存在就自动注册一个“未绑定学号”的账号，存在则正常登录。

登录成功后生成JWT返回给小程序。JWT的秘钥不要写在代码里，要放到配置文件中，并且要用足够长的随机字符串。payload里只放userId和role，不放敏感信息。过期时间设置为7天，到期后小程序端需要静默重新登录。

拦截器是必须的。写一个WebMvcConfigurer，注册HandlerInterceptor，在preHandle里从请求头的Authorization字段取出token并解析。解析不到或者过期，返回统一的401错误码。这里有个坑：小程序端有时候会先加载页面再等登录完成，导致部分请求在token还没设置好的时候就发出去了。解决方案是在小程序端加一个请求拦截器，如果发现本地没有token，先执行登录流程，再放行请求。

4.2 图书发布、检索与详情

图书发布接口的入参包括ISBN、书名、作者、出版社、封面图、描述、取书地点。为了用户体验，前端可以在用户输入ISBN后调用后端接口，通过ISBN查询第三方图书API自动填充信息。但这块要加兜底：第三方接口可能超时，所以即使用户手填，也要允许提交。

图书发布后不能直接显示在“可借”列表里，需要管理员审核。审核通过后status变为1（可借）。这里提醒一点：上传封面图要使用对象存储，比如阿里云OSS或腾讯云COS，不要直接把图片存到MySQL的BLOB字段里。数据库只存URL，图片上传接口单独写一个。

图书检索用MyBatis-Plus的LambdaQueryWrapper实现。基本条件是status=1（可借），然后根据关键字模糊匹配标题、作者、出版社。如果用户按校区筛选，再加上campus条件。排序规则很重要：默认按发布时间倒序；如果图书借阅次数高，可以按borrow_count升序优先展示，这样能让共享者的书有更多被借的机会。

图书详情接口需要返回基本信息、共享者信息、借阅状态。注意不要直接返回共享者手机号，要在详情页设计“联系共享者”按钮，点击后调用后端接口获取手机号，并且记录一条消息。这样可以防止用户绕过平台直接私下交易。

4.3 借阅、归还、续借的接口设计

借阅申请接口路径可以定义为POST /api/borrow/apply，入参是bookId和remark。接口内部逻辑顺序很重要：

1. 校验图书是否存在且状态为可借。
2. 校验借阅者不是共享者本人。
3. 通过Redis分布式锁锁定bookId。
4. 再次查询图书状态，防止期间状态变化。
5. 创建借阅单，状态为待确认。
6. 将图书状态改为“锁定”，这里可以加一个状态：待确认时可借状态暂时改为“借出中”，避免其他人看到还能申请。

第6步很多人会纠结：图书还在共享者手里，改成“借出中”会不会误导？实际上，加了“待确认”状态后，图书应该立刻不可申请。所以我建议把图书状态直接变为“借出中”，或者新增一个“锁定中”。借阅单被拒绝后，再恢复为“可借”。

确认借用接口由共享者触发，路径POST /api/borrow/confirm，入参是recordId。执行时把借阅单状态改为“借用中”，同时设置due_time为当前时间加30天。这里不要在前端计算到期时间，日期计算放在后端统一处理，避免用户修改本地时间造成数据错乱。

归还申请接口是借阅者点“申请归还”，状态变为“申请归还”。共享者看到后，线下确认书没问题，再点“确认归还”，状态变为“已归还”，同时把图书状态恢复为“可借”，borrow_count加一。如果共享者发现书有损坏，可以在备注里记录并拒绝确认归还，这时候就需要管理员介入处理。

续借功能不是必须的，但如果要做，建议限制只能续借一次，续借天数不超过15天，而且必须是在借阅状态为“借用中”且未逾期时才能申请。续借本质上就是更新due_time并记录一条操作日志。

4.4 消息通知、逾期处理与定时任务

高校共享借阅场景里，消息通知是提升体验的关键。接入了微信订阅消息，但订阅消息的特点是“一次性”：用户点了同意授权，后端才能发一条。所以不要在用户每次操作时都弹授权，而是把授权时机放在“申请借阅”“确认借出”这些关键动作上。

消息表（t_message）字段包括id、userId、title、content、type、isRead、create_time。站内信是保底，即使微信订阅消息发送失败，用户登录小程序后也能看到消息提醒。

逾期处理必须靠定时任务。实现方式有两种：Spring自带的@Scheduled，或者集成xxl-job。这个项目并发量不大，用@Scheduled足够。启动类加上@EnableScheduling，写一个定时任务类，每五分钟执行一次：

• 查出所有状态为“借用中”且due_time小于当前时间的借阅单。
• 将状态改为“已逾期”。
• 给借阅者发送逾期通知，内容包含图书名和应还日期。
• 如果逾期超过7天，给共享者发送提醒，建议发起纠纷。

定时任务的逻辑不复杂，但要注意SQL性能。比如“查询所有借用中且due_time小于now”这种语句，一定要在due_time和status上建联合索引，否则数据量大了之后定时任务会拖垮数据库。

4.5 全局异常、参数校验与接口安全

后端的健壮性取决于异常处理。我用@RestControllerAdvice + @ExceptionHandler做统一异常处理。自定义业务异常类BizException带有错误码和错误信息。接口里遇到业务不满足的情况，直接throw new BizException(ErrorCode.BOOK_NOT_AVAILABLE)即可，全局异常处理器负责把错误信息转成统一的JSON结构返回。

统一返回结构非常重要。我定义了Result类，包含code、message、data三个字段。成功时code为0，业务失败时code为业务码，系统异常时code为500。这样小程序端可以根据code做统一的错误提示，不用每个接口单独判断。

参数校验用javax.validation，在Controller入参的实体类上添加@NotBlank、@NotNull等注解。但要注意，小程序端传来的参数有时候会出现“空字符串”而不是“null”，尤其是输入框没填时。前端要在提交前做一次trim，后端除了加@NotBlank，还在业务代码里再做了一次StringUtils.isBlank判断，双重保险。

接口安全方面，除了JWT认证和参数校验，还要注意SQL注入。MyBatis-Plus的条件构造器默认防止注入，但如果你自己写了SQL，一定要用#{}而不是${}。另外，所有列表接口都要做分页，不能一次性查全表。MyBatis-Plus的Page对象可以直接传入LambdaQueryWrapper，返回分页结果非常方便。

5. 小程序端实现与前后端联调

5.1 页面架构与路由设计

小程序端的目录结构建议：

• pages/login：登录页
• pages/index：首页（图书推荐、搜索入口）
• pages/book-list：图书列表
• pages/book-detail：图书详情
• pages/publish：发布共享图书
• pages/my-books：我的共享
• pages/my-borrow：我的借阅
• pages/messages：消息中心
• pages/profile：个人中心
• pages/audit：管理员审核页

底部TabBar只需要四个入口：首页、发布、消息、我的。发布按钮放中间可以做特殊样式，但TabBar一定要选微信原生支持的配置，不要自定义组件，不然会出现切换时页面闪动。

首页规划为一个图书推荐流，数据来自后端的推荐接口。推荐逻辑可以简单一点：优先展示最新发布、借阅次数多的书，再按用户的默认校区过滤。页面顶部放一个搜索框，点击跳转到图书列表页，列表页支持关键字搜索和状态筛选。

5.2 登录、扫码借书、图书详情交互

登录页的逻辑比较绕，建议这样处理：进入小程序后，先通过wx.login拿到code，调用后端登录接口换取token，然后用token请求“查询用户信息”接口。如果用户还没绑定学号，个人信息接口会返回一个标识，前端看到后就跳转到绑定页。绑定时需要输入学号和真实姓名，后端可以对接学校的接口做校验，但大多数毕设项目里，直接存数据库、由管理员审核即可。

图书详情页是整个小程序最复杂的页面，包括图书封面、信息、共享者信息、借阅按钮。核心交互是“借阅申请”按钮，点击后弹出确认框，然后调用后端申请接口。如果成功，按钮变成“已申请，等待确认”。这个状态变化要交给后端返回的数据驱动，不能只在前端本地改。因为如果别人已经借走这本书，后端返回错误，前端就要重新拉取图书详情刷新状态。

扫码借书功能可以做一个加分项。管理员或者共享者扫码后，直接进入图书详情页。实现上不需要自己写二维码生成，小程序端可以用wx.scanCode扫码，后端生成二维码时只需要把图书ID编码进去，比如https://yourdomain.com/book?id=123。这样扫码后进入详情页，用户点“借阅申请”即可。

5.3 联调中的“隐形坑”

前后端联调是项目耗时最多的阶段，这里集中说几个我踩过的坑。

第一个是请求地址问题。小程序端不能用域名访问本地后端，必须配置“不校验合法域名”。开发模式下可以在微信开发者工具里打开这个选项，但真机预览时，手机会默认校验合法域名。解决办法是绑定一个HTTPS域名，或者用内网穿透工具临时调试。这个坑几乎每个人都会遇到，如果不提前配置，真机一调试就白屏。

第二个是JSON字段格式问题。后端Long类型的id传到小程序端会丢失精度，因为JavaScript的Number类型最大安全整数是2^53-1，一旦超出精度就会出错。解决办法是在后端序列化时，把Long类型统一转成String。可以在Jackson配置里把Long序列化为String，或者用注解@JsonSerialize(using = ToStringSerializer.class)单独处理id字段。

第三个是时间格式问题。后端返回的时间是Java的LocalDateTime，默认序列化结果是“2025-01-05T12:00:00”，小程序端new Date()解析这个格式在iOS上会报错，但在安卓上是好的。所以统一在后端返回时间戳，或者把Jackson的时间格式改成“yyyy-MM-dd HH:mm:ss”。这个差异非常隐蔽，测试时一定要用iPhone真机跑一遍。

第四个是请求拦截器的执行顺序。小程序端在App.onLaunch里异步调登录接口，可是Page.onLoad里的接口可能已经发出了。此时本地token还没拿到，所以请求会被拦截器拦住。解决办法是在登录接口的Promise调用中，把页面请求放进队列，等token获取成功后再统一放行。或者更简单一点，把登录流程做成同步的PROMISE，首页在拿到token后再加载数据。

6. 部署上线与问题排查实录

6.1 环境准备与服务器打包

后端部署我建议用一台2核4G的云服务器就够跑。操作系统选CentOS 7或Ubuntu 20.04，安装JDK 8、MySQL 8.0、Redis、Nginx。打包时用Maven命令mvn clean package -DskipTests，生成jar包后通过scp上传到服务器，用java -jar命令启动。

为了让项目在服务器上常驻运行，可以用shell脚本配合nohup启动，或者用systemd服务管理。我更推荐systemd，因为进程崩溃后能自动重启。写一个服务文件：

[Unit] Description=library project After=network.target [Service] ExecStart=/usr/bin/java -jar /opt/library/app.jar --spring.profiles.active=prod Restart=on-failure [Install] WantedBy=multi-user.target

生产环境的application-prod.yml要单独配置，数据源密码、Redis密码都不能写在代码仓库里。可以用Jasypt加密配置文件，或者在服务器上用环境变量覆盖。毕设项目的话，用环境变量就足够了，例如：

SPRING_DATASOURCE_PASSWORD=yourpassword

小程序端上线需要注册微信小程序账号、上传代码、提交审核。个人主体的小程序不支持开通微信支付和部分类目，但图书借阅类目一般是可以的。审核的时候注意，如果涉及“图书共享”这种UGC内容，最好在详情里说明有内容审核机制，不然可能被拒。

6.2 高频问题与排查方法

我在项目里遇到过各种奇奇怪怪的问题，这里整理一个速查表：

排查问题的时候，日志最重要。建议后端启动时把日志级别调成DEBUG，但生产环境用INFO。遇到问题先在本地复现，再一步步打日志缩小范围。不要一上来就改代码，先把请求参数和返回结果打印出来，十有八九是参数对不上。

6.3 优化建议与个人踩坑体会

这个项目如果只是应付答辩，做到这步基本够了。但如果你想把它当作品集项目，还可以做几个优化方向：

一是检索能力提升。现在用的是MySQL模糊查询，数据量小没问题，但如果图书数量上千，搜索响应就会变慢。可以引入Elasticsearch或者MeiliSearch做全文检索，把图书索引和搜索分离。不过在毕设体量下，这个优化的意义不大，再说清楚就行。

二是借阅信用体系。可以给用户增加信用分功能：按时归还加分，逾期扣分，信用分过低不能借书。这块能很好体现你对产品逻辑的思考，答辩时非常加分。

三是数据统计分析。管理员后台加一个统计页面，用ECharts展示每日借阅量、热门图书Top10、共享贡献榜。把MySQL的聚合查询练熟，这个功能几天就能做完。

最后说点个人的实际操作体会。这个项目表面上是技术题，但真正难的是把借阅流程定义清楚。我陪着学弟改了三版状态机才算稳定。第一版只设计了四个状态，结果发现共享者拒绝申请后图书状态没恢复，书就这样“消失”了。第二版加了逾期状态，但没用定时任务去驱动，导致逾期单永远卡死。第三版才把自动释放、定时扫描、消息通知全部串起来。

所以我还是那句话：不要急着写代码。把状态机画清楚，把每条状态迁移产生的影响想明白，再动手写。Spring Boot和小程序本身都不难，难的是把业务规则落地成稳定可靠的系统。希望这篇拆解能让你少走点弯路。