JSP图书馆读者行为分析系统：从源码部署到统计实现全流程解析

带q52f5编号的完整工程包是那种一眼就能认出来的典型“课程设计/毕业设计交付件”：里面有源码、有数据库SQL脚本、还有一长串写着“调试部署+开发环境”的说明文档。我最近帮一位读者把这套系统从拿到压缩包到本地跑通再到改出统计报表，整个流程走了一遍。说实话，这种JSP项目放到今天来看技术并不前沿，但它把“Java Web旧式分层开发”“数据库关系建模”“读者行为数据的采集与展示”这三件事完整串了起来，作为入门和练手项目，价值比很多花架子Spring Boot项目高得多。

这篇文章我把整条链路拆开讲清楚：从这套系统到底在做什么，到为什么还需要用JSP复现一次；从数据库的表怎么设计，到行为分析的几个统计口径怎么落地；最后是调试部署阶段最容易卡住人的位置和排查思路。如果你手里正好有一套类似的“程序+源码+数据库”包，或者你打算自己从零开发一个“JSP+Servlet+MySQL”的图书馆读者行为分析系统，这篇文章可以直接当操作手册用。

1. 这类课设系统到底要解决什么问题

先别急着开IDE写代码。拿到任何一个带编号的工程包，第一步永远是搞懂它要交付的业务是什么。“JSP图书馆读者行为分析系统”这个名字拆成两半看：一半是“图书馆”，说明业务场景是图书借还、馆藏管理和读者档案；另一半是“读者行为分析”，这才是系统的灵魂。很多类似的课设系统会把重心全放在“能不能借书、还书”这种基础CRUD上，而这个项目的差异化在于：借书还书只是数据来源，它的最终产出是一批“分析结果”——哪个读者最活跃、什么图书最热门、哪类读者喜欢借哪类书、借阅高峰出现在一天里的什么时段。

我拆读完这个包里的读者模块、借阅模块和管理端之后，发现业务闭环是这样设计的：

• 读者登录系统后可以检索图书、查看个人借阅记录、提交借书申请、完成还书操作。
• 每一次借还动作，都不会只停留在“状态改一下”的层面，而是往借阅记录表里写入一条带时间戳的事件。
• 管理端（也就是图书管理员的角色）看到的不只是流水账，而是经过统计SQL或图表页面加工后的读者画像、借阅排行和热门分类。
• 另外会有“行为标签”这类设计，例如根据读者的借阅频率把读者划分成高活跃、中活跃、沉睡读者，为后续做定向推荐或催还通知提供数据依据。

这类系统最适合谁去复现？一是计算机相关专业正在做JSP课程设计或毕业设计的学生，你需要的是一个“功能完整、有分析亮点、能演示”的完整项目；二是刚学完Java Web基础知识，想找项目练手但不满足于“增删改查”的开发者。它不像Spring Boot那样有一堆自动配置把你保护起来，所有请求转发、数据库连接、参数传递都得手写，这恰恰能把底子打扎实。

2. 技术栈选型：为什么今天还值得复现一个JSP系统

在看这个工程包的技术选型之前，先说一个现状：现在Java Web新项目基本都走Spring Boot + Thymeleaf或前后端分离，新生代开发者可能只在课本里听过JSP。那为什么“JSP + Servlet + MySQL”这套旧组合仍然值得你去跑通、去读懂？我的观点是：正因为它的技术栈“笨”，很多底层机制反而暴露得很清楚。

2.1 JSP在项目中的真实定位

JSP全称是JavaServer Pages，本质上是一个以Java代码动态生成HTML的思路。你访问login.jsp的时候，Tomcat会把它翻译成一个Java Servlet，再编译成class执行。所以JSP不是一门独立的“模板语言”，它是Servlet的另一种写法。这个包里的项目采用典型的三层结构：

• 表示层：JSP页面负责展示，包括读者登录页、图书列表页、借阅统计页。
• 业务与数据层：用Servlet接收请求、调用DAO、把结果塞进request或session，再转发回JSP渲染。
• 数据库层：MySQL存储读者、图书、借阅流水、行为日志等数据。

我打开这个项目源码时特别注意了它的包结构，常见的是com.xxx.entity（实体类）、com.xxx.dao（数据访问对象）、com.xxx.servlet（控制器）、com.xxx.util（工具类），再加上webapp目录下的JSP和静态资源。这种结构放到任何一门MVC框架课里都能直接类比理解，Spring MVC的Controller对应Servlet，MyBatis的Mapper对应DAO，只不过这里所有链路都是手动的。

2.2 部署运行环境的版本组合

交付文档里通常会写“JDK 1.8 + Tomcat 8.5/9 + MySQL 5.7 + Eclipse/IDEA”，我这次实际用的环境也验证了这个组合：

• JDK 1.8：JSP项目最稳妥的版本，太高版本或太低版本都可能出现兼容问题。
• Tomcat 8.5或9.0：支持Servlet 3.1/4.0，能跑JSP标准语法。
• MySQL 5.7：和项目里SQL脚本的字符集、排序规则最匹配。
• Eclipse IDE for Enterprise Java and Web Developers，或IDEA Ultimate版，配合Tomcat Server做本地部署。

如果你只有IDEA Community版，也不用慌，它不支持直接集成Tomcat，但可以手动把项目打包成WAR，扔到Tomcat的webapps目录下启动。这个流程会在第6节实际操作一遍。

2.3 技术栈选型背后的核心逻辑

为什么这种课设没有选更“现代”的方案？因为教学场景需要的是从HTTP请求到数据库查询每一环“可见”。Spring Boot把内嵌Tomcat、数据源、事务、JSON转换都自动配置好了，学生反而看不到一个请求是怎么一步步走到数据库的。

在这个项目里，你看一次JSP页面往Servlet提交表单、Servlet里手动获取参数、调用DAO执行PreparedStatement的过程，以后再转到任何框架，心里都会有一张“底层地图”。所以复现这套系统的价值不在技术时髦度，而在它足够透明。

3. 数据库怎么设计才能支撑“行为分析”

一个管理系统如果只做借书还书，三张表就够了：读者表、图书表、借阅记录表。但“读者行为分析”这个目标会让数据库设计多出一层考量。这个包的数据库脚本我完整过了一遍，虽然一般叫library.sql或者q52f5.sql，但里面的核心表设计逻辑很值得讲。

3.1 核心表的字段规划

第一张是读者表。除了常规的读者编号、姓名、密码之外，这个系统用了reader_type这个字段区分教师和学生。别小看这个分类字段，它在行为分析里是关键维度之一。不同身份群体的借阅偏好、借阅量都会有明显差异，后续做分群统计时就靠它group by。

第二张是图书表。馆藏图书需要关注的字段是book_id、book_name、author、publisher、category（分类）、total_count（馆藏总量）、borrow_count（累计借出次数）。category字段直接支撑“热门图书分类排行”的分析维度；borrow_count是典型的冗余统计字段——不实时去算借阅表，而是在每次借书成功后加1，属于典型的用空间换时间的统计优化。

第三张是借阅记录表，这是行为分析的数据底座。字段包括record_id、reader_id、book_id、borrow_time、return_time、status（借出/已还/逾期）。行为分析里最高频的统计都是围绕这张表展开：按时间范围查借阅量，按读者分组查活跃度，按图书分组查热度，按还书时间算是否逾期。

稍微复杂一点的系统还会加第四张行为日志表，比如读者每次点击图书详情、每次检索都记一条行为轨迹。但这个课设系统的分析规模一般用不到这么细的粒度，借阅记录表已经能覆盖大多数行为维度。

3.2 关键外键和索引设计

从SQL脚本里能看到，借阅记录表对reader_id和book_id都设置了外键约束。外键在业务开发中经常因为是“性能负担”被省略，但在这个项目场景下建议保留。原因很简单：它能在数据库层面保证不会出现“借阅记录指向一个不存在的读者”这种脏数据，对课设答辩时回答“如何保证数据完整性”是现成的加分点。

索引设计上，我建议重点关注两个组合索引：

• (reader_id, borrow_time)：支撑“按读者查借阅历史”和“按时间段统计读者活跃度”。
• (book_id, borrow_time)：支撑“按图书查借阅趋势”和“热门图书时段分析”。

MySQL查询优化器在这些字段有索引和没有索引时的执行计划差异非常大。行为分析页面如果越用越卡，第一个排查点就是看统计SQL有没有走索引。

sql复制-- 以“读者活跃度排行”的统计SQL为例，索引是否命中直接决定性能
SELECT r.reader_id, r.reader_name, COUNT(b.record_id) AS borrow_total
FROM reader r
LEFT JOIN borrow_record b ON r.reader_id = b.reader_id
WHERE b.borrow_time BETWEEN '2024-01-01' AND '2024-12-31'
GROUP BY r.reader_id, r.reader_name
ORDER BY borrow_total DESC
LIMIT 10;

这条SQL在数据量到达几万条借阅记录的时候，如果没有(reader_id, borrow_time)联合索引，会触发全表扫描，页面响应速度能从毫秒级掉到秒级。对课设演示来说可能还能忍，但如果数据量再上去，就必须关注执行计划了。

3.3 脚本导入时的两个细节

导入SQL脚本最常见的坑有两个：一是字符集不一致导致中文乱码，二是MySQL版本差异导致建表语句报错。这个包的SQL脚本用的是utf8mb4字符集，如果你的数据库默认编码是latin1或utf8mb3，导入后中文会变成问号。建议建库时显式指定：

sql复制CREATE DATABASE IF NOT EXISTS library_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
USE library_db;
SOURCE /你的路径/library.sql;

字符集的坑最好在第一次导入时就规避掉，不然后面所有页面显示出来的乱码都会让你怀疑是代码问题，而实际上源头在数据库。

4. 核心功能模块的分层实现逻辑

这个系统的功能模块拆开之后大致有以下几块：读者注册登录、图书检索和借阅、还书与逾期管理、后台统计分析、读者行为画像。我不打算把每一行代码都贴出来，那样等于把源码复抄一遍，意义不大。我更想讲清楚每个功能点在分层架构下是怎么“流转”的，以及代码里哪些写法是这套系统的关键。

4.1 登录会话的管理方式

JSP项目的登录状态管理一般有两种做法：一种是靠session，一种是靠cookie。这个项目用的是session方案。用户在login.jsp表单里输入账号密码，表单提交到LoginServlet，Servlet校验通过后往session里写入当前登录用户的对象：

java复制// LoginServlet 核心逻辑示意
Reader loginReader = readerDao.findByUsernameAndPassword(username, password);
if (loginReader != null) {
    HttpSession session = request.getSession();
    session.setAttribute("loginReader", loginReader);
    // 管理员走管理员主页，普通读者走读者主页
    if ("admin".equals(loginReader.getReaderType())) {
        response.sendRedirect("admin/index.jsp");
    } else {
        response.sendRedirect("reader/index.jsp");
    }
} else {
    request.setAttribute("errorMsg", "用户名或密码错误");
    request.getRequestDispatcher("login.jsp").forward(request, response);
}

注意这里的写法逻辑：成功后用sendRedirect重定向，避免用户刷新页面时再次提交表单；失败后用forward转发，把错误信息带到JSP页面里显示。这是Web开发的基本功，也是面试常问的“重定向和转发的区别”的实际应用场景。

4.2 图书借阅流程里的状态流转

读者查到自己想借的书，提交借书申请后，系统内部到底做了什么？这是答辩时老师最爱问的点。我拆解这个包的代码后发现，借书操作不是简单insert一条记录，而是一个事务性的多表修改：

• 更新图书状态：把这本书的馆藏剩余量减1，如果剩余量为0，状态标记为“不可借”。
• 插入借阅记录：status字段明确为“借出中”，borrow_time取当前系统时间。
• 冗余更新：把图书表的borrow_count在原来基础上加1，用于热门排行统计。

这三个动作必须在一个数据库事务里完成，否则会出现“书被借走但记录没插入”或者“记录插入了但书的状态没有改变”的不一致问题。

JDBC里的事务控制是手动提交模式，代码套路是：

java复制conn.setAutoCommit(false);
try {
    bookDao.updateStockDecrease(bookId, conn);
    borrowDao.insertBorrowRecord(readerId, bookId, conn);
    bookDao.updateBorrowCountIncrease(bookId, conn);
    conn.commit();
} catch (Exception e) {
    conn.rollback();
    e.printStackTrace();
} finally {
    conn.setAutoCommit(true);
    // 关闭连接
}

这个包里的事务代码写得比较规矩，DAO方法都接收了Connection参数，这是为了确保多个数据库操作使用的是同一个连接，从而保证事务的原子性。很多初学者写DAO时每个方法内部自行获取连接，导致事务控制完全失效，这是隐蔽又严重的问题。

4.3 前端JSP与后端数据交互

JSP项目里最常见的前后端交互方式就是表单提交+EL表达式取值。在借阅历史页面，后台把一个List放到request域，JSP里通过JSTL标签循环渲染。

借阅记录里通常会关联图书名称和读者名称，而不只是显示两个孤立的ID。这个实现上有两种方案：一种是在SQL里直接用JOIN查出来放到VO对象里；另一种是先从借阅记录表查出列表，再循环查图书表和读者表补充信息。前者一次查询搞定，但SQL稍微复杂；后者N+1查询问题严重，数据量一大性能就崩。这个项目用的是JOIN方案，经验上这是正确选择。

jsp复制<c:forEach items="${borrowList}" var="borrow">
    <tr>
        <td>${borrow.readerName}</td>
        <td>${borrow.bookName}</td>
        <td><fmt:formatDate value="${borrow.borrowTime}" pattern="yyyy-MM-dd HH:mm:ss"/></td>
        <td>
            <c:choose>
                <c:when test="${borrow.status == '借出中'}">
                    <span class="badge badge-warning">借出中</span>
                </c:when>
                <c:otherwise>
                    <span class="badge badge-success">已归还</span>
                </c:otherwise>
            </c:choose>
        </td>
    </tr>
</c:forEach>

JSP里能不能写Java脚本片段？能，但不建议。写大量<% %>会让页面可读性断崖式下降。这个包里的JSP页面主要用了EL表达式和JSTL标签，整体风格比较干净，你打开页面源码会发现几乎没有大段的Java逻辑，可维护性在课设项目里算是上乘的。

5. 读者行为分析的统计口径与核心指标

读者行为分析听着很玄，落到代码层面其实就是几个核心SQL统计。统计学模型里经常用RFM模型（最近一次消费时间、消费频率、消费金额）来划分用户价值，这个项目的数据库层面完全可以参考这个思路，只是把“消费金额”换成“借阅数量”。

5.1 读者活跃度排行

这个统计背后的业务问题是：谁是图书馆里最忠实的读者？实现逻辑是按读者分组统计借阅次数，再按次数降序排列取前N条。可以进一步按照身份类型分群统计，比如教师组和学生组的活跃Top10分别是谁。

sql复制SELECT r.reader_id, r.reader_name, r.reader_type, COUNT(br.record_id) AS borrow_num
FROM reader r
JOIN borrow_record br ON r.reader_id = br.reader_id
WHERE br.borrow_time >= DATE_SUB(CURDATE(), INTERVAL 6 MONTH)
GROUP BY r.reader_id, r.reader_name, r.reader_type
ORDER BY borrow_num DESC
LIMIT 10;

执行后拿到的数据可以直接喂给前端表格或柱状图JSP页面展示。如果你希望图表效果更直观，ECharts在这个项目里也很容易集成，只要用AJAX访问一个返回JSON的Servlet，再在前端渲染就行。但这个课设如果考虑到答辩时间有限，用JSP页面 + 表格展示排行也可以接受，重点是把统计口径讲清楚。

5.2 热门图书分类流向

分析“什么类型的书最受欢迎”比单纯统计“哪本书借得多”更有决策价值。后者只能告诉你某本具体图书的情况，前者能告诉图书馆采购部门应该向哪个分类倾斜经费。实现上是在图书表和借阅记录表之间做JOIN，然后按category分组：

sql复制SELECT b.category, COUNT(br.record_id) AS borrow_count
FROM borrow_record br
JOIN book b ON br.book_id = b.book_id
WHERE br.borrow_time BETWEEN ? AND ?
GROUP BY b.category
ORDER BY borrow_count DESC;

我在跑这个统计时发现一个问题：借阅表里的book_id如果没有对应到book表，JOIN结果会丢失数据。所以这里其实反过来验证了第3节里“外键必须加”的重要性——只有数据库层面保证了引用完整性，统计结果才是可信的。

5.3 借阅时段趋势分析

再往下钻一层，可以用MySQL的HOUR函数提取借阅时间的小时值。它会告诉你一天内哪个时段是借阅高峰期。比如上午10点到11点出现峰值，那就说明读者习惯上午来馆借书；晚上8点到9点如果有小高峰，可能是学生下课后集中操作。这个数据对图书馆开放时间和人工服务窗口的安排有直接参考价值。

sql复制SELECT HOUR(borrow_time) AS borrow_hour, COUNT(*) AS borrow_count
FROM borrow_record
GROUP BY HOUR(borrow_time)
ORDER BY borrow_hour;

这个结果尤其适合横向柱状图展示，从早上8点到晚上22点，一个小时的柱子配一个数据，借阅趋势一目了然。

5.4 沉睡读者识别与催还提醒

系统中有“沉睡读者”的分析场景：定义是过去30天没有任何借阅行为的已注册读者。这个名单的价值在于：图书馆可以针对性地做推送通知或阅读推广活动。SQL实现用NOT EXISTS子查询即可。

sql复制SELECT r.reader_id, r.reader_name, r.reader_type, r.register_time
FROM reader r
WHERE NOT EXISTS (
    SELECT 1 FROM borrow_record br
    WHERE br.reader_id = r.reader_id
    AND br.borrow_time >= DATE_SUB(CURDATE(), INTERVAL 30 DAY)
);

这种“30天无行为读者”和“过去7天连续活跃读者”的标签，就是行为标签体系最简单的落地形式。演示答辩时能把“标签”背后的SQL讲清楚，比你空讲一堆概念更能证明你真的理解业务。

6. 调试部署实录：从环境构建到高频报错排查

接下来进入这个包最让人头大的部分——跑通环境。我见过很多同学拿到的源码本身没问题，但倒在了部署环节。这里把我在实际部署中踩过的坑和排查链路完整写出来，按顺序操作，大概率能一次性跑通。

6.1 Eclipse/IDEA中配置Tomcat与项目导入

先说Eclipse路线。下载Eclipse IDE for Enterprise Java and Web Developers，导入项目时注意选择“Existing Projects into Workspace”，不是“Import from File System”。如果项目不是Maven结构，直接选目录导入即可。然后在Server视图里点击新建，选择Tomcat v9.0 Server（按你安装的Tomcat版本选），Runtime Environment里指向你本机的Tomcat安装目录。右键项目选择“Run As → Run on Server”，Eclipse就会自动把项目部署到Tomcat的webapps下并启动。

如果用的是IDEA Ultimate，步骤是：Project Structure里配置JDK 1.8和要发布的Web模块；Artifacts选项卡点击+号，选择Web Application: Exploded，确保输出目录中有WEB-INF/classes；再配置一个Tomcat Server运行配置，Deployment选项卡里把刚才的Artifacts加进去，Application context填写项目名，比如/library。启动后项目路径就是http://localhost:8080/library/。

需要留意的是：如果项目依赖用Maven管理，仓库里的jar下载失败会导致各种NoClassDefFoundError。最稳妥的做法是先执行一遍mvn clean install，观察BUILD SUCCESS之后再启动Tomcat。

6.2 JDBC驱动连接失败的排查链

运行项目后最常见的报错是：

text复制java.lang.ClassNotFoundException: com.mysql.jdbc.Driver

这个报错的意思是Tomcat运行时的WEB-INF/lib目录下没有MySQL驱动jar。解决方法是下载mysql-connector-java对应的版本，然后放到webapps/项目名/WEB-INF/lib目录下。如果你用的是Eclipse或IDEA，要在项目构建路径里也加上这个jar，否则编译阶段会找不到Driver类。

如果你用的是MySQL 8.0以上版本，驱动类名已经变了，不再是com.mysql.jdbc.Driver，而是com.mysql.cj.jdbc.Driver，URL也需要加上时区参数：

properties复制driver=com.mysql.cj.jdbc.Driver
url=jdbc:mysql://localhost:3306/library_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
username=root
password=你的密码

如果项目里的db.properties还是旧的驱动配置，连接数据库时会直接报Unable to load authentication plugin 'caching_sha2_password'或Communications link failure。前者是MySQL 8默认认证插件和旧驱动不匹配，换成新版驱动即可；后者多半是端口不对、服务没启动或防火墙拦截。

6.3 中文乱码的完整链路排查

中文乱码在JSP项目里太经典了。它的排查链路要从上到下捋：数据库表字符集、数据库连接URL、JSP页面编码、Servlet请求编码。任何一环不一致都会乱码。

• 数据库层：建库时用utf8mb4，导入SQL脚本前确认脚本文件本身是UTF-8编码。
• JDBC连接层：URL里带characterEncoding=utf8，同时注意如果表字段是utf8mb4，写法建议改成characterEncoding=utf8或直接依赖服务器默认。
• JSP页面层：页面顶部要有<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>。
• Servlet接收请求参数：POST提交场景下，要在获取参数前加上request.setCharacterEncoding("UTF-8")，否则读取到的就是ISO-8859-1编码的乱码。

显示端的乱码会在HTML里看到一排问号或菱形符号，而Servlet端乱码则会让数据库里存进去的就是乱码。所以排查顺序是先查数据库里有没有乱码，没有再去看页面显示，最后查请求传递。

6.4 启动阶段的其他高频报错

除了类找不到和乱码，还有几个出现频率极高的坑：

端口被占用时Tomcat启动失败，报Port 8080 required by Tomcat v9.0 Server at localhost is already in use。解决方式可以杀掉占用进程，也可以把Tomcat默认端口改掉。改端口在Eclipse里是双击Server视图中的服务器实例，修改Ports栏目下的HTTP/1.1端口，改成8081或8090。

HTTP 404错误通常是应用上下文路径不对。访问路径少了项目名，比如直接访问http://localhost:8080/login.jsp，而正确路径是http://localhost:8080/项目名/login.jsp。JSP页面内的超链接如果写了绝对路径/login.jsp，也会因为少了上下文路径而404。最佳实践是用${pageContext.request.contextPath}拼路径前缀。

HTTP 500错误就要看Tomcat的catalina日志或页面上的异常堆栈了。JSP页面报错最常见的是Unable to compile class for JSP，比如页面里用了某个不存在的方法或引用了没有import的类。这类问题解决起来不复杂，把报错堆栈往上翻，定位到具体行号，修改对应JSP页面即可。

6.5 管理端页面无法访问的隐藏问题

这个系统把管理员页面放在admin文件夹下，如果不设置访问拦截，任何知道URL的人都能直接访问管理员页面。我在跑通项目后顺手测了一下，发现直接访问admin/index.jsp确实能打开。这个安全漏洞在课设项目里普遍存在，但答辩时如果被问“怎么防止普通读者进管理页”，能答出来加不少印象分。

最简单方案是用Servlet Filter做一个登录拦截器，在web.xml里配置：

xml复制<filter>
    <filter-name>AdminAuthFilter</filter-name>
    <filter-class>com.yourpackage.filter.AdminAuthFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>AdminAuthFilter</filter-name>
    <url-pattern>/admin/*</url-pattern>
</filter-mapping>

过滤器里先判断session中是否包含管理员标记，如果不存在就重定向到登录页。虽然只是一个很基础的过滤器，但正好说明了开发中“功能能跑”和“功能健壮”之间的差距。

7. 从跑通到加分的几个进阶改动方向

如果你手里的项目已经能跑通，别急着收工。做课设和接外包最大的不同是，课设只要在原有的CRUD之上再多做两三个亮点，答辩评分就能明显拉开差距。这里分享几个我能快速落地而且不会破坏原系统架构的改进方向。

第一个方向是给统计页面加可视化图表。原系统的统计基本都是表格形态，数字摆在表格里的信息传达效率一般。可以把活跃度排行、分类占比、时段趋势三个SQL结果集换成ECharts图表，前端用柱状图和饼图展示，视觉冲击力立刻不一样。集成方式不复杂，导入ECharts的JS文件后，用JSP后台把JSON数据输出到页面上，再用AJAX读取并渲染。

第二个方向是增加一个“读者借阅趋势”的折线图。这个页面不再做排行，而是按月展示某一段时间内的整体借阅量走势。SQL写法是按月分组聚合：

sql复制SELECT DATE_FORMAT(borrow_time, '%Y-%m') AS borrow_month, COUNT(*) AS borrow_count
FROM borrow_record
WHERE borrow_time >= DATE_SUB(CURDATE(), INTERVAL 12 MONTH)
GROUP BY DATE_FORMAT(borrow_time, '%Y-%m')
ORDER BY borrow_month;

有了这个趋势图，系统的“分析”味道就浓了不少，因为它不再是简单的现状描述，而是带上了时间维度，能看出增长或下降的规律。

第三个方向是完善读者画像标签。除了前面说的沉睡读者，还可以加“高频借阅者”“热门分类爱好者”“借阅逾期常客”等标签，在读者列表页面直接把标签以文本形式展示出来。实现思路是给reader表增加一个tag字段，在读者每次还书后触发规则引擎更新标签，或者在管理端展示时动态计算标签。考虑到课设代码的简洁性，动态计算更合适，不需要新的数据表。

第四个方向是做一个简单的图书推荐模块。根据当前读者的历史借阅分类偏好，推荐同分类下借阅量最高的图书，SQL上分两步就能完成。推荐结果不要求多精准，关键是能讲清楚推荐逻辑。这种完整的“采集行为数据→分析偏好→输出个性化结果”的闭环，会让整个项目的业务完整度上一个台阶。

我实际做这些改动时的顺序是：先跑通原系统，确认所有页面和统计SQL都能正常执行，再逐个增加图表页面和推荐模块。每加完一个功能，重启一次Tomcat验证，避免一次性改动太多导致问题不好定位。

最后再分享一个经验：无论你是手写这套系统还是拿现成工程包跑通，千万别只停留在“能打开登录页、能借书、能还书”这个层面。JSP项目的技术栈本身不新，它真正的学习价值在于让你完整经历过一遍Web开发的经典链路——从前端页面到后端控制再到数据库建模，以及项目从编码到部署的全流程。把这条链路跑通，再回头看Spring Boot这类封装完善的框架，你会发现自己看到的不是一堆魔法，而是一层比一层更清晰的封装路径。