基于JavaWeb的图书馆阅读行为与借阅预定采购一体化平台设计与实现

1. 为什么要把阅读行为、借阅、预定、采购四个模块放进同一个平台

先说一个我接手类似项目时遇到的真实场景：校图书馆管理员手里有三张Excel表，一张是学生借书记录，一张是学生填的纸质预订单，一张是各学院交上来的采购申请。每到月底，他要把三张表的数据手工合并，统计"哪些书借得最多""哪个年级的学生最爱借书""哪些书被预定了很多次但始终没有库存"。这套流程最大的问题不是累，而是数据对不上——借阅记录里显示某本书很热门，但采购Excel里完全没有这本书的申请，因为学生想借的书不在馆藏里时，根本没人主动去登记这个需求。

这个平台要解决的，本质上是两件事：一是把"学生和图书之间的每一次交互"变成结构化数据，二是让借阅、预定、采购三个业务动作在同一条数据链路上自动联动。先说第一件，阅读行为分析没那么玄乎，它分析的就是三类数据：学生借了什么书、借了多久、还了之后有没有再借同类的书。只要把借阅记录的时间字段、图书分类字段、学生年级字段存好，这些指标都能算出来。难的是第二件，很多学生想借某本书时发现已经被借走了，系统让他提交一个预定申请，这个申请攒到一定数量，管理员就应该能看到"这本书有N个人在等"，从而触发采购流程。这就是预定和采购联动的基本逻辑。

这个项目适合谁来参考？如果你是正在做JavaWeb课程设计或毕业设计的学生，可以直接把它当完整案例来搭；如果你是刚入职的初级开发，想理解一个业务系统从需求分析到表结构设计再到接口实现的全过程，这篇也能给你一条比较完整的思路。我下面写的内容不是教科书式的架构说明，而是按我自己做这类项目时真实走过的流程来讲的，包括哪些地方我一开始想简单了，哪些地方后来返工了。

2. 数据库设计：先定出八张核心表，再谈业务逻辑

2.1 基础表和业务表的边界划分

这个项目我建议先别急着写代码，花半天时间把表结构定清楚，后面能少改很多。整个系统我最终拆成了八张核心表，分三类：

基础数据表：学生表（student）、图书表（book）、图书分类表（category）、管理员表（admin）。这四张表是业务发生的前提，学生得先登录系统才能借书，图书得先录入馆藏才能被检索。

业务流转表：借阅记录表（borrow_record）、预定单表（reserve_order）、采购单表（purchase_order）。这三张表是整个平台的核心，每条记录都代表一次完整业务的某个状态。

行为分析表：阅读行为日志表（read_behavior_log）。这张表我一开始没设计，后来做统计时才意识到，光靠借阅记录表算不出"学生打开过哪些图书详情页""检索过什么关键词"这类过程数据，而过程数据恰恰是分析阅读兴趣的重要来源。

2.2 关键表和核心字段的取舍说明

每张表的字段设计，我挑几个容易踩坑的详细说说。

学生表除了学号、姓名、学院、年级、专业之外，我建议一定要加一个status字段，区分正常和禁用状态。为什么？因为学生毕业或者转校后，他的借阅历史还需要保留用于统计分析，但账号不能再登录借书了。如果直接删学生记录，借阅记录表的外键就全断了，统计历史数据时会出现大量空值。用状态位做逻辑删除，是这类业务系统最基础也最实用的做法。

图书表有个细节容易忽略：除了书名、作者、ISBN、出版社、馆藏数量这些基础字段外，一定要单独建一个available_stock字段表示当前可借数量，而不是每次查询时用total_stock减去借出中的记录数来现算。原因很简单，借还操作非常频繁，每次查询都聚合计算很伤数据库，在高并发借书时还会出现超借的问题。一本书总共5本，第6个学生来借时，系统要能立刻判断"可借数已为0"。

借阅记录表是整张表里最重要的，字段设计上有个常见争议：要不要存冗余的图书名称和学生姓名？我的建议是存。虽然通过外键join也能查出书名，但借阅记录是查询频次最高的表，管理员要看"某本书被借过多少次"，如果每次都要join图书表，数据量大了之后性能会明显下降。把书名、ISBN、学生姓名、学号这几个字段冗余进去，牺牲了一点存储空间，换来了查询的便利，这笔账是划算的。

预定单表要特别注意预留时间的处理。学生提交预定申请后，管理员确认有书了，需要给学生保留一段时间（比如三天），到期没来取就自动释放，把图书状态改回可借。这个"到期自动释放"的逻辑可以用定时任务扫表实现，也可以在下一次有人查询或借阅这本书时懒判断。我实际开发时选了懒判断，因为定时任务要另外引入调度框架，而懒判断只需要在借阅接口里加一个状态检查，成本更低。

2.3 索引怎么建：从查询场景反推

索引设计别照抄网上的模板，要从你实际的查询语句反推。我用阿里的SQL调优经验来梳理这个项目的查询场景：

学生登录时按学号查询，所以student.student_no要建唯一索引。图书列表页支持按书名模糊搜索和按分类筛选，所以book.category_id建普通索引，book.name如果频繁做LIKE '%关键词%'查询，普通索引也帮不上忙，建议用前缀匹配或者考虑全文索引，这个我在后面踩坑部分会详细说。借阅记录表最常见的查询是"某学生借过哪些书"和"某本书被谁借走了"，所以borrow_record.student_id和borrow_record.book_id各建一个索引。预定单表要快速统计"哪本书的预定人数最多"，所以reserve_order.book_id加索引。

这里有个反直觉的点：不是说索引建得越多越好。我见过有同学给所有外键字段都建了索引，结果插入数据时索引维护成本高，写入变慢。正确的做法是先写完核心查询SQL，再对着WHERE和ORDER BY子句里的字段建索引，一个查询场景一个索引，宁缺毋滥。

3. 借阅、预定、采购三条流程的状态机设计

3.1 借阅流程的状态流转和代码落地

借阅流程看似简单，实际上状态设计不好很容易出逻辑漏洞。我的借阅记录表状态字段取值是：

这四个状态里最容易忽略的是"逾期未还"。很多第一次做借阅系统的人会把逾期当成一个计算出来的结果，而不是一个状态，觉得只要还书时判断当前时间是否晚于应还时间就行。但问题是，如果学生一直不来还书，这本书在系统里永远显示"借出中"，其他学生无法预定，管理员也无法追踪。所以我建议定期扫描一次，把超过应还日期三天以上的借阅记录状态改为2，同时触发通知逻辑，告诉学生尽快还书。

状态在代码里怎么落地？不需要为了用设计模式而用设计模式，这个项目用状态字段加if-else判断就够了。重点是把状态切换的入口方法收敛好，不要散落在Controller的各个角落。我通常会建一个BorrowService，里面定义borrowBook()、returnBook()、markOverdue()三个方法，每个方法内部先校验当前状态是否允许变更，再执行更新操作。这样保证状态流转路径是可控的。

3.2 预定流程：从提交申请到图书释放的完整闭环

预定单表的状态机设计比借阅复杂一些，因为中间涉及"管理员介入"和"超时释放"两个特殊环节。我的状态设计如下：

有一个实现细节要提醒：状态从0变到1时，"图书被预留"这个动作必须同步影响图书表的可借数量。比如某本书显示可借1本，管理员给A学生预留后，这本书的可借数量要变成0，否则B同学在同一时刻还能借走这本书，预定单就完全失效了。这就是业务系统里典型的"状态一致性"问题。

预定流程结束后，有两个分支：学生取书时，系统要根据预订单信息自动创建一条借阅记录，状态设为"借出中"，同时把预订单状态改为"已取书"；学生没来取，预订单状态改为"已过期"，同时把图书可借数量加回去。这两条路径我在开发时是用一个事务包起来的，避免出现预订单已经关闭但图书库存没恢复的情况。

3.3 采购流程：让预定数据成为采购依据

采购流程是这个平台和其他普通图书管理系统最大的区别。采购单表的状态流转是：

采购流程最关键的联动逻辑是：管理员新建采购单时，系统应该自动罗列出"预定次数超过阈值且馆藏不足"的图书，按预定人数排序，作为采购优先级参考。这个功能实现起来不复杂，核心就是一条带GROUP BY的SQL，按图书ID统计预定表中状态为"待处理"和"已预留"的记录数，过滤掉已有库存的图书，再按人数降序排列。

我实际开发时还在采购单表里加了一个source_type字段，标记这条采购申请是手工创建还是系统根据预定数据自动建议的。这个字段在项目答辩或汇报时非常有用，它直观体现了系统的智能化程度，也是"借阅预定采购"三者联动的直接证据。

3.4 状态机设计给代码结构带来的影响

状态机定好之后，代码的分层就清晰了。我的Controller层只做参数接收和状态码返回，真正的状态流转逻辑全部放在Service层。每个Service方法开头第一件事就是根据ID查出当前记录，检查状态是否合法，不合法直接抛出业务异常（比如"当前预订单状态不允许取消"），由全局异常处理器统一捕获并转换成前端提示。

还有一个经验可以分享：表里的状态字段别用varchar存中文，比如"借出中""已归还"这样写虽然直观，但是一旦要在SQL里做条件判断就会很痛苦，还得引号里写中文。建议用tinyint存数字，在代码里用常量类或者枚举类把数字和含义映射起来，查询时再用CASE WHEN转换成中文返回给前端。既保证了程序的可维护性，又让SQL查询条件简洁。

4. 阅读行为采集与分析：最容易做歪的一个模块

4.1 行为数据从哪里来

很多第一次做这个项目的同学有一个误区，觉得阅读行为分析就是统计借阅记录，把每本书的被借次数排个序就完了。但真正的行为分析，至少包含四个维度：

• 借阅行为：借了什么书、借了多久、是否按时归还、是否有续借。
• 检索行为：学生搜了什么关键词、搜了几次、最终有没有借走书中某本。
• 浏览行为：学生打开过哪些图书详情页、在页面停留了多久。
• 预定转化：学生预定了哪些书、预定了之后有没有真的去借。

其中检索行为和浏览行为，传统的图书馆管理系统根本不会记录，这也是"学生阅读行为"这个项目题目的核心加分点。实现方法很简单：学生每次搜索时，在搜索接口里记录一条日志；每次打开图书详情页时，在详情接口里记录一条日志。这些日志统一写到read_behavior_log表，包含学生ID、行为类型、目标图书ID、搜索关键词、时间戳。

后来我还把行为日志做了异步化处理，不然每次搜索都要等日志写完后才返回结果，接口响应时间会很慢。利用线程池把日志插入操作放到后台执行，前端响应时间从平均200毫秒降到了70毫秒左右。这个优化点如果项目文档里能写上，很加分，因为它说明你考虑到了高并发场景下的性能问题。

4.2 核心指标的SQL计算逻辑

行为数据采集回来后，怎么变成图表和排名？我汇总了这个项目里最常用的几个统计需求，直接给出SQL思路，你可以根据自己的表结构调整：

统计每日借阅量趋势：

sql复制SELECT DATE(borrow_date) AS day, COUNT(*) AS borrow_count
FROM borrow_record
WHERE borrow_date >= DATE_SUB(CURDATE(), INTERVAL 30 DAY)
GROUP BY DAY(borrow_date)
ORDER BY day;

热门图书TOP10，这里要按借阅次数去重统计，一本书被同一个人借三次应该算三次还是算一次？我的建议是算一次，因为一个学生反复借同一本书反映的是深度阅读，而这题目的核心是"行为分析"，按人去重能更好地反映图书对用户的吸引力，而不是单纯的流通次数。

sql复制SELECT book_id, book_name, COUNT(DISTINCT student_id) AS borrow_users
FROM borrow_record
GROUP BY book_id
ORDER BY borrow_users DESC
LIMIT 10;

学生阅读偏好分析，按分类统计每个学生的借阅分布：

sql复制SELECT b.student_id, b.student_name, c.category_name, COUNT(*) AS borrow_count
FROM borrow_record b
JOIN book bk ON b.book_id = bk.id
JOIN category c ON bk.category_id = c.id
GROUP BY b.student_id, bk.category_id
ORDER BY b.student_id, borrow_count DESC;

年级阅读活跃度对比，按学生表里的年级字段分组：

sql复制SELECT s.grade, COUNT(DISTINCT s.id) AS active_students,
       COUNT(b.id) AS total_borrows,
       COUNT(b.id) / COUNT(DISTINCT s.id) AS avg_borrows_per_student
FROM student s
LEFT JOIN borrow_record b ON s.id = b.student_id
GROUP BY s.grade;

这几条SQL基本覆盖了平台的报表需求。实际开发时要注意，统计分析SQL和业务查询SQL最好分开写，统计接口可以接受稍微慢一点的响应，但业务借书接口不能因为统计任务拖慢。我的做法是用一个独立的StatController来暴露统计接口，内部查询时加上必要的索引，数据量大的时候考虑用汇总表，每天定时把前一天的明细数据聚合成汇总数据，查询报表时直接查汇总表，速度会快很多。

4.3 行为分析的展示形式

这个项目的展示层不需要做得很花哨，但要逻辑清晰。我在管理端做了四个标签页：

• 借阅趋势：展示最近30天的借阅量曲线，可以按学院、年级筛选。
• 热门榜单：展示热门图书TOP20，点击书名能看到借过这本书的学生列表。
• 学生画像：选择一个学生，展示他借了哪些书、偏好分类、平均借阅时长、最近活跃时间。
• 采购建议：展示预定次数最多且库存不足的图书列表，直接显示"建议采购数量"，数量按预定人数加一个安全余量计算。

这里不建议自己用前端图表库去画特别复杂的可视化图，ECharts引入项目时注意版本兼容性，如果项目是传统的JSP网页模式，用简单的表格加进度条展示排名效果就足够了。那种"左边折线图右边饼图"的大屏效果是展示型项目才需要的，这个项目核心是业务流程闭环，别把精力花偏了。

5. 技术选型和项目搭建：从IDEA建项目到跑通第一个页面

5.1 Servlet/JSP还是SpringBoot，怎么选

这是很多同学搭建项目时第一个纠结的问题。说实话，如果是学校布置的JavaWeb课程设计，大概率要求的是传统Servlet+JSP+MVC，因为这门课的前置内容就是这些。但我给你一个更实际的建议：看你的时间预算和老师要求。

如果老师明确要求用JSP做前端页面，那就老老实实用Servlet+JSP，但项目结构要按MVC思想分层。如果老师只说了"JavaWeb项目"，没有限定技术栈，我建议直接用SpringBoot+Thymeleaf或者SpringBoot+JSP，理由有三个：内置Tomcat，不用单独配置外部服务器；简化了大量XML配置，新手不容易被环境问题劝退；将来写简历时SpringBoot项目比Servlet项目更有说服力。

下面我会以传统Servlet+JSP为主线来写，因为标题里的"javaweb"风格更接近这个方向，但涉及的业务分析和SQL部分，在SpringBoot下同样适用。

5.2 IDEA创建项目和目录结构

我用的是IntelliJ IDEA 2023版本，说两个新手最容易卡住的地方。第一步，新建项目时选Java Enterprise而不是普通Java项目，这样才能直接勾选Web Application模板。如果IDEA没有Java Enterprise选项，用Maven骨架建项目然后在src/main下手工创建webapp目录也行。第二步，配置Tomcat时，一定要确认Deployment里把项目的/路径映射正确，不然部署后访问的URL多出一截项目名，页面上的请求路径很容易404。

一个比较顺手的包结构参考：

text复制src
├── main
│   ├── java
│   │   └── com/library
│   │       ├── controller   # Servlet控制器层
│   │       ├── service      # 业务逻辑层，接口+实现
│   │       ├── dao          # 数据访问层，JDBC或MyBatis映射
│   │       ├── entity       # 实体类
│   │       ├── util         # 工具类
│   │       └── filter       # 过滤器，处理编码和登录拦截
│   ├── resources
│   │   ├── jdbc.properties  # 数据库连接配置
│   │   └── mybatis-config.xml
│   └── webapp
│       ├── WEB-INF
│       │   ├── web.xml
│       │   └── jsp          # JSP页面
│       ├── css
│       ├── js
│       └── index.jsp

5.3 JDBC还是MyBatis

传统JavaWeb项目里数据访问层有两种主流方式。纯JDBC的问题是代码重复量太大，每次查询都要写一遍Class.forName、getConnection、PreparedStatement、ResultSet的轮子，而且手动处理结果集非常容易出错。MyBatis把这些样板代码封装掉了，我只需要写接口方法和SQL映射文件就好。

我的建议是直接用MyBatis，即使是课程设计也没问题。学会MyBatis本身跟"纯JavaWeb"完全不冲突，技术栈里写"Servlet+JSP+MyBatis"反而比"Servlet+JSP+纯JDBC"更充实。配置方面，引入mybatis和mysql-connector-java依赖后，在mybatis-config.xml里配好数据源和Mapper扫描路径，剩下的工作就是写Mapper接口和XML文件。

5.4 事务管理的处理

这个项目很多操作不能只更新一张表。借书操作要插入一条借阅记录，同时要把图书表的可借数量减一，这两个动作必须是一个原子操作——如果第一个成功第二个失败，数据库里会出现"这本书被借走了但库存没减少"的脏数据。

纯Servlet+JSP时代，我习惯用两种方式管理事务。一种是在DAO层手动控制connection.setAutoCommit(false)、提交和回滚，缺点是每个方法都要重复写。另一种是用ThreadLocal保存当前线程的Connection对象，让同一线程内的所有DAO操作共用同一个连接，在一个统一的Service方法边界里做提交或回滚。后面这种方式其实就是Spring声明式事务的手动版，如果上了SpringBoot，直接加@Transactional注解最简单。

这里特别提醒一个我踩过的坑：JDBC连接超时。默认的MySQL连接如果长时间不用会被服务端断开，但应用端的连接池不知道，下次拿出来用时会报Connection is not available或者Communications link failure。解决方案是给连接池配置testWhileIdle或者testOnBorrow，确保每次拿到的连接都是可用的。

6. 核心接口与前后端交互设计

6.1 接口清单和请求路径设计

前后端不分离的传统JavaWeb项目，接口就是Servlet的URL映射。合理的请求路径设计能让项目结构更清晰，我推荐按资源名和操作动词来命名：

6.2 借书接口的完整处理链条

借书接口是整个平台业务逻辑最密集的地方，我把它每一步的操作说明写清楚，你对照着检查自己的代码：

1. 从请求参数中拿到student_id和book_id。
2. 根据student_id查学生表，确认账号状态是正常，不是禁用。
3. 根据book_id查图书表，确认available_stock大于0。
4. 执行库存扣减SQL：UPDATE book SET available_stock = available_stock - 1 WHERE book_id = ? AND available_stock > 0。这条语句的返回值如果为0，说明有并发请求已经把最后一本借走了，当前请求直接提示"库存不足"。
5. 插入借阅记录，状态为"借出中"，应还日期为借出日期加30天。
6. 查询该学生是否有状态为"已预留"的预订单，如果有且图书ID相同，把预订单状态更新为"已取书"。

第4步的乐观锁式更新特别重要。如果你的代码是"先查库存，判断大于0，再执行更新"，在高并发下会出问题——两个请求同时查到库存为1，同时执行扣减，最后库存变成-1。用上面这种带条件的更新语句，从根上避免了超卖问题，这个细节在项目文档里值得重点说明。

6.3 管理端的交互设计

管理端的核心逻辑是"今天我要处理什么"。我给管理员设计的首页是一张待办事项面板：今天需要处理的预定申请有几条、待审核的采购单有几条、已经逾期未还的借阅记录有几条。这比一般的"欢迎使用图书管理系统"那种静态首页实用得多。

预定处理页面要展示的信息包括：学生姓名、学号、预约图书名称、提交时间、当前图书库存状态。管理员点击"确认预留"时，系统要弹出确认框，提示"将为学生保留该书3天，期间其他人不可借阅"，防止管理员误操作。采购审核页面要展示采购图书的名称、申请数量、预计金额、系统采集到的预定人数，方便审核人判断这笔采购是否合理。

学生端的交互设计相对简单，核心是"搜索图书→查看详情→借阅或预定→在个人中心查看当前借阅和预订记录"。有一个细节可以增加用户体验：学生在提交借阅时，如果这本书当前不可借，页面不要只显示"库存不足"四个字，应该同时给出一个"提交预定申请"的按钮，并显示当前已有多少人预定了这本书。这样借阅和预定两个模块就很好地打通了。

7. 实测中踩过的坑与排查链路

7.1 并发借阅同一本书导致库存变负数

这个问题我在前面提到过，排查时走了不少弯路。当时的现象是：班级里很多同学同时点击借阅同一本热门书，后台日志报库存扣减失败，但数据库里available_stock字段变成了负值。我一开始以为是UPDATE语句写错了，反复检查SQL后发现语句没问题，后来才意识到是"先查后改"的逻辑天生就有竞态条件。

修复方案就是前面说的，把库存扣减合并成一条带条件的UPDATE语句。改完之后如果UPDATE返回的行数为0，说明库存已经被借完了，此时在Service层抛出业务异常"抱歉，这本书刚刚被借走了"。

7.2 浏览器中文乱码问题

这个坑在纯JSP项目里特别容易遇到，而且现象五花八门：有的是页面显示中文乱码，有的是数据库里存的中文乱码，还有的是前端提交的中文到后端时乱码。

排查链路从三个入口分别检查。第一，浏览器到Tomcat的请求编码，需要在web.xml里配置一个CharacterEncodingFilter过滤器，强制请求和响应的编码都是UTF-8；第二，Tomcat连接器的URIEncoding属性设为UTF-8，否则URL参数中的中文会乱码；第三，数据库连接URL上要加useUnicode=true&characterEncoding=utf8，否则JDBC写入数据库时中文会变成问号。这三处都设置好之后，乱码问题基本可以根治。

7.3 统计接口查询慢得离谱

阅读行为日志表的数据逐渐增多后，我发现统计页面打开要好几秒。用EXPLAIN一看，查询语句走的是全表扫描——read_behavior_log表上没建索引，而统计SQL里的WHERE条件字段是student_id和action_type。

解决思路分两层。短期方案是给行为日志表加复合索引(student_id, action_type, create_time)，覆盖绝大多数单学生行为的查询。长期方案是把实时统计改成离线汇总，每天凌晨用定时任务把前一天的明细数据聚合成学生维度、图书维度、分类维度三张汇总表，日报表和月报表直接查汇总表。这个优化做完之后，即使数据量翻十倍，统计接口的响应时间也基本稳定在一秒以内。

7.4 预定到期释放逻辑的边界情况

预定到期自动释放这个功能，我用懒判断实现时忽略了一个边界情况：一本被预留的书，到期当天正好有另一个学生来借。此时系统需要先判断"这本书的预留是否已经过期"，如果过期则自动把预订单状态改为"已过期"，库存恢复，再执行借阅。但如果学生A的预留当天到期，学生B在到期前几分钟提交了借阅请求，库存还是0，系统会拒绝B的请求，这是合理的还是不合理？

按正常业务逻辑，预留期内图书归预留者所有，B借不了是对的。但这里有一个体验优化空间：如果A的预留在当天23:59到期，B在22:00来借书，系统能不能提示"该书已被预留，预计明天上午释放，可提前预定"？我最后实现时，在图书详情页做了一个"预释放时间"字段展示，对学生透明显示这本书什么时候会重新变为可借状态，虽然只是一个小的交互优化，但使用评价很高。

7.5 会话超时导致学生表单提交失败

学生填完预定申请，点击提交时如果Session刚好超时，就会被登录拦截器重定向到登录页，填了一堆的数据全丢了。这个体验问题在开发环境不明显，因为IDE里Session默认超时时间很长，部署到生产环境后Tomcat默认30分钟就会失效。

要彻底解决，前端表单在提交前先用一个/checkLogin的轻量接口探测Session状态，如果未登录或已超时，先弹窗提示并保存当前表单数据到本地存储，跳转登录后再自动回填。这个方案虽然要写点JavaScript，但整体代码量不大，解决的是最直接影响学生使用体验的问题。

8. 几点关于这个项目后续扩展的个人建议

项目做到能跑、流程闭环、报表能出，核心要求就算完成了。但如果你有精力，我建议按下面三个方向选一个做深，对个人能力的提升远比多写两个CRUD接口更有价值：

第一个方向是行为分析的深度。现在的阅读行为分析还是基于借阅记录的简单统计，如果要做得更"有说服力"，可以引入RFM模型，把学生按最近借阅时间、借阅频率、借阅丰富度三个维度打分，自动划分出"活跃读者""沉睡读者""流失风险读者"几类，再往图书馆推送定向推荐结果。这个在答辩或者面试时讲出来，效果完全不一样。

第二个方向是推荐功能。基于学生已有的借阅记录，用协同过滤的思路找"借过同类书的人还借了什么"，做成"猜你喜欢"列表。不追求算法多先进，但至少能体现你理解推荐系统的核心思想：用户行为数据驱动个性化结果。

第三个方向是采购预测。预定数据已经拿到了，可以进一步做"根据历史借阅趋势预测未来采购量"，比如某本教材在开学季会有借阅高峰，系统在高峰期到来前自动生成本季度的采购建议单。这能证明你不只是在写增删改查，而是在思考业务数据如何反哺业务决策。

我在做这个项目的过程中，最大的感受是：这种业务系统真正的复杂度不在某个单一技术点，而在"流程闭环"。借阅和预定之间有没有把库存扣重？预定的过期释放有没有影响借阅？采购入库有没有更新馆藏？每一个环节就像齿轮一样咬合，一个地方漏了，整条链子在特定场景下就会出问题。写代码前先画业务流程图（不用复杂的工具，纸笔或者简单的绘图工具都行），把所有状态流转和异常分支标出来，再动工写表结构和接口，能节省大量返工时间。

最后分享一个调试技巧：状态类字段的变更，建议在代码里统一打日志，输出"操作人、操作前状态、操作后状态、触发来源"。我在排查并发借阅问题时就是这个日志帮了大忙——对比两个并发请求的日志时间线，能清晰地看到它们都认为库存是充足的，从而快速定位到竞态条件。这种基础日志习惯，平时看不出价值，遇到线上问题就是救命稻草。