简介：《共享图书管理系统设计与实现》是一份完整的课程设计与毕业设计参考文档，主要面向计算机相关专业的学生、毕业设计者以及需要开发图书管理系统的开发者。文档针对传统图书馆借阅效率低、资源利用率不高等问题，系统梳理了研究背景与意义、国内外研究现状、系统开发目标，并详细介绍了面向对象思想、输入输出处理、JSON数据交换、JDBC数据库连接、JSP动态页面、Ajax异步交互等关键理论与技术，同时涉及Tomcat、Eclipse、Oracle 11g等开发环境与工具，内容覆盖从需求分析到系统设计的完整流程。资源包包含1个docx文件，压缩后大小约13.15MB，目录结构清晰，涵盖摘要、Abstract、绪论、相关理论与技术、系统需求分析与功能模块设计等章节，既可作为论文写作的章节框架参考，也可用于理解共享图书系统的整体设计思路。目前已有109人学习下载，适合用于快速掌握图书管理系统从立项到设计的关键要点，并为后续编码实现提供清晰的规划基础。
1. 共享图书管理系统设计与实现：一份能跑通借还书全流程的课设资源
这套系统没有分布式架构，也没有微服务拆分，全部代码就是 JSP + Servlet + JDBC 往 Oracle 11g 里读写数据，核心功能围着注册登录、借书还书、图书管理、用户管理打转。真正让这份资源有价值的地方在于，它把「用户端 + 管理端 + 数据库 + 测试」串成了一条完整链路，适合做毕设课题、Java Web 课程设计，或者想快速理解传统 B/S 项目分层的人。对已经习惯 SpringBoot 的同学来说，它反而能让你看清最原始的前后端交互长什么样——没有自动配置，没有注解魔法，每一个请求流转都摆在明面上。接下来我从技术栈拆解、数据库设计、功能实现到踩坑记录，把这个系统的可复现路径完整走一遍。
2. 技术栈拆解：为什么守着 JSP + Servlet + Oracle 11g 不放
2.1 功能边界：名字带「共享」，实际是标准借阅管理
先给这份资源定个性。项目标题写的是共享图书管理系统，但翻完目录就能看出来，它没有做 C2C 模式下用户之间互相借书的功能，也没有积分、预约、书评这些共享经济常见的玩法。它的真实身份是一套标准的图书馆借阅管理系统：用户端能注册、登录、浏览书库、借书、还书、查借阅记录、改密码；管理员端能维护图书类型、增删改图书信息、查看所有用户和借阅情况。「共享」两个字更多体现在多用户共用一套图书数据这项基础能力上，而不是商业模式上的共享。这个边界得先搞清楚，不然下载下来找「共享」功能会扑空。
系统按模块化管理原则拆成管理员模块和用户模块。管理员模块管图书类别、图书信息和所有用户；用户模块管个人的查找、借书、还书、查看历史。两条线在数据库里通过外键关联起来，整体结构对课程设计来说相当完整，应付毕设开题、中期检查和答辩演示都够用。如果把系统比作一个黑匣子，那这个黑匣子从输入到输出都有清晰的数据流：前端 JSP 页面捕获数据，Servlet 接收请求做逻辑分发，DAO 层通过 JDBC 读写 Oracle，结果再返回前端渲染。
2.2 JSP + Servlet + JDBC：为什么不是 SpringBoot
现在的 Java Web 课程基本都在教 SpringBoot，但每年高校毕设里仍有大量 JSP + Servlet 项目，原因有三点。第一，答辩老师对这类项目可审查性更好，每一行代码都在明面上，不像 SpringBoot 大量依赖自动配置，出问题不好讲。第二，课设项目代码量需求不大，普通借阅管理用 Servlet 做控制器、JSP 做视图、JDBC 连 Oracle，三层加起来两三千行，比引入 Spring 全家桶更省事。第三，论文好写，JSP、JDBC、Ajax 这些名词在绪论和研究现状部分能讲出历史脉络，参考文献一抓一把。
这里有个矛盾点要提醒你：论文摘要里写了 Java spring，但翻遍正文实现部分基本看不到 Spring 的依赖注入或事务配置，实际技术栈是 JSP + Servlet + JDBC + Ajax + Oracle 11g。下载后建议先核对 lib 目录和 web.xml，确认它是传统 Java Web 项目而非 Spring 项目，这直接影响你用什么方式打开项目、用哪个版本 Tomcat 部署。这种论文描述和实际代码脱节的情况在课设资源里非常普遍，不是这份资源独有的毛病。
2.3 Ajax 与 JSON：无刷新交互的实现方式
系统在前端用了 Ajax 来提升用户体验，典型场景是不用整页刷新就能完成借书操作、查询借阅状态。实际做法是 JSP 页面里用 JavaScript 发起异步请求，Servlet 接收后访问数据库，再往响应里写 JSON 字符串，前端拿到 JSON 后局部更新页面节点。好处是表单提交和页面跳转的割裂感消失了，用户在列表页点「借阅」后不用跳转就能看到结果反馈，这也是论文里强调用户体验的主要依据。
一个典型的请求流转是这样的：用户在 bookList.jsp 点击借书按钮 → JavaScript 读取书本 ID → 用 JQuery 或 XMLHttpRequest 发起 POST 请求到 borrowBook Servlet → Servlet 调用 BorrowDao 插入借阅记录并更新图书状态 → 返回 JSON 格式结果 → 前端判断 code 字段后提示成功或失败。这个链路完整覆盖了 JSP 视图层、Servlet 控制层、DAO 数据访问层三部分，也是后续所有功能模块的基础模板。理解这条链路，就等于拿到了这套系统所有功能的通用钥匙。
2.4 工具链与运行环境：Eclipse + Tomcat + Oracle 11g
开发工具选了 Eclipse、Oracle 11g，配套 Servlet 容器是 Tomcat。这里有一层隐性约束：Oracle 11g 的 JDBC 驱动 ojdbc6.jar 对应 JDK 6/7，如果本地装的是 JDK 8 以上，建议换成 ojdbc8.jar，否则可能出现驱动加载异常。Tomcat 用 8.x 对应 Servlet 3.1 规范，和教材、论文里的写法对得上；Tomcat 9 不是不行，但老代码里用 web.xml 配置 Servlet 映射的写法要注意版本兼容，有的标签在 9 里会报警告甚至报错。
Eclipse 打开这种项目很方便，File → Open Projects from File System 直接选目录就能识别 Web 项目，前提是项目里有 .project 文件。如果资源包只有源码和 JSP，就得手动配成 Dynamic Web Project，把 src 设为 source folder、WebContent 设为 web root。数据库端建议直接用 Oracle 自带的 SQL Developer 建表导数据，比命令行直观得多。整套环境配置下来大概半天时间，大部分时间会花在 Oracle 安装上，这个后面专门讲坑。
3. 数据库与后端：从 E-R 图到 JDBC 连接
3.1 数据模型：四张核心表与它们的关系
数据库设计是这份资源最值得照抄的部分。整个系统围绕用户、图书类型、图书、借阅记录四个实体展开，表结构可以按下面这样设计。这套表设计是典型的课设风格，字段不多但功能齐全，改造成其他管理系统的底子也够用。
| 表名 | 核心字段 | 说明 |
|---|---|---|
| book_user | id, username, password, real_name, phone | 用户表，username 唯一 |
| book_type | id, type_name | 图书类型表 |
| book_info | id, book_name, type_id, author, publisher, stock | 图书表，type_id 外键关联类型 |
| borrow_record | id, user_id, book_id, borrow_date, return_date, status | 借阅记录，status 标识在借/已还 |
四张表的关系是：book_user 和 book_info 通过 borrow_record 形成多对多借阅关系，book_info 通过 type_id 和 book_type 形成多对一关系。借阅状态用 status 字段控制，比直接删记录更安全，还能保留历史痕迹。Oracle 11g 建表时优先用 VARCHAR2 而不是 VARCHAR——Oracle 的 VARCHAR 类型语义和主流数据库不同，VARCHAR2 才是标准做法，这个细节写在论文里也算个加分项。
3.2 主键策略：序列加触发器
Oracle 11g 没有 MySQL 的 AUTO_INCREMENT，主键自增需要靠序列实现。下面给一段建序列的 SQL，在 SQL Developer 里直接执行即可。注意执行顺序：先建用户和图书相关的序列，再建表，顺序反了可能出现约束引用不存在的错误。
CREATE SEQUENCE seq_user_id START WITH 1 INCREMENT BY 1; CREATE SEQUENCE seq_book_id START WITH 1 INCREMENT BY 1; CREATE SEQUENCE seq_type_id START WITH 1 INCREMENT BY 1; CREATE SEQUENCE seq_record_id START WITH 1 INCREMENT BY 1;序列建好后，在插入语句里直接用 seq_user_id.NEXTVAL 就能取下一个主键值。也可以用触发器在 INSERT 前自动赋值，但课设场景下直接写进 SQL 更直观，排查问题时不至于多一层嵌套。需要留意序列有个特征：每次 NEXTVAL 都会递增，即使事务回滚也不会回退，调试时如果发现主键跳号，这是正常现象，不用怀疑代码写错。另外，序列方式天然支持并发插入，比 MAX(id)+1 的做法安全得多，后者在高并发下会产生重复主键报错。
3.3 DBUtil 封装：JDBC 连接管理模板
系统通过 JDBC 链接 Oracle 数据库，核心是把连接管理封装成一个 DBUtil 类。这个类负责三件事：加载驱动、提供 getConnection 连接、关闭资源。后续所有 DAO 都复用这套模板，算是整个后端代码里复用率最高的组件。下面是实际项目中常见的封装写法。
package com.library.util; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; public class DBUtil { private static final String URL = "jdbc:oracle:thin:@localhost:1521:orcl"; private static final String USER = "library"; private static final String PASSWORD = "library123"; static { try { Class.forName("oracle.jdbc.driver.OracleDriver"); } catch (ClassNotFoundException e) { e.printStackTrace(); } } public static Connection getConnection() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } public static void close(ResultSet rs, Statement stmt, Connection conn) { try { if (rs != null) rs.close(); if (stmt != null) stmt.close(); if (conn != null) conn.close(); } catch (SQLException e) { e.printStackTrace(); } } }三个关键点说明一下。第一，URL 格式固定是jdbc:oracle:thin:@主机名:端口:服务名，1521 是 Oracle 默认监听端口，orcl 是安装时指定的全局数据库名。这两个值写错最常见的报错就是 ORA-12505，后面避坑章节展开说。第二，驱动类加载写进静态块保证只执行一次，Class.forName 找不到类就是缺 ojdbc 驱动 jar，记得把 ojdbc6.jar 丢进 WEB-INF/lib。第三，关闭资源顺序很重要：先 ResultSet 再 Statement 最后 Connection，顺序反了可能出现连接未能释放的问题，严重时会耗尽数据库连接数。
如果项目访问量稍大，可以在 DBUtil 上再包一层连接池，比如 DBCP 或 C3P0，论文里写一句「引入了数据库连接池优化」也算加分项。不过多数课设直接使用 DriverManager 是够用的，毕竟演示场景并发很低。还有一个小建议：数据库密码不要写死在源码里，至少抽到一个 properties 文件用 Properties 类加载，答辩时提到这个细节会显得更专业。
3.4 DAO 层：从 ResultSet 到对象的映射
JDBC 查询结果的麻烦在于结果集映射，DAO 层就是干这件事的。以用户查询为例，典型写法是先写 SQL，再用 PreparedStatement 绑定参数，最后从 ResultSet 取值构造 User 对象返回。下面给一段 UserDao 的 findByUsername 方法，这是登录验证的基础，也是后面所有 DAO 的模板。
public User findByUsername(String username) { String sql = "SELECT id, username, password, real_name, phone FROM book_user WHERE username = ?"; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, username); try (ResultSet rs = ps.executeQuery()) { if (rs.next()) { User user = new User(); user.setId(rs.getInt("id")); user.setUsername(rs.getString("username")); user.setPassword(rs.getString("password")); user.setRealName(rs.getString("real_name")); user.setPhone(rs.getString("phone")); return user; } } } catch (SQLException e) { e.printStackTrace(); } return null; }这里用的是 try-with-resources 写法，省去手动 close 的冗余代码，JDK 7 以后都支持。PreparedStatement 相比 Statement 有两个好处：一是 SQL 预编译提升执行效率；二是参数占位符避免字符串拼接产生的 SQL 注入问题。登录模块里这个点尤其重要，如果写成字符串拼 SQL，答辩时被评委问一句「SQL 注入怎么办」就会很被动。后续借书记录、还书记录的 DAO 都遵循同一模板，改 SQL 和实体类就能复用，这套代码结构值得原样保留。
4. 核心功能实现：登录会话、借还书与 Ajax 刷新
4.1 用户与管理员双角色登录：Session 管理
登录分用户和管理员两条线，分别走 userLogin 和 adminLogin 两个 Servlet，登录成功把用户对象塞进 Session，页面通过判断 Session 是否存在来决定跳转或展示对应菜单。下面这段是用户登录处理的典型实现，管理员登录逻辑同构，只是查的表换一张。
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("UTF-8"); String username = request.getParameter("username"); String password = request.getParameter("password"); UserDao userDao = new UserDao(); User user = userDao.findByUsernameAndPassword(username, password); if (user != null) { request.getSession().setAttribute("loginUser", user); response.sendRedirect("index.jsp"); } else { request.setAttribute("errorMsg", "用户名或密码错误"); request.getRequestDispatcher("login.jsp").forward(request, response); } }两个点值得备注。第一，request.getParameter 取到的是表单里 name 属性对应的值，JSP 里 input 的 name 必须和这行代码的参数名一致，否则取出来是 null，导致永远登录失败。第二，登录失败用 forward 而不是 sendRedirect，这样 request 域中的 errorMsg 能被 login.jsp 里的${requestScope.errorMsg}读到；如果用重定向，request 域就丢了，页面拿不到错误提示。
密码存储方面，这份资源大概率是明文存在 book_user.password 字段，这是课设通病。如果你要交作业，可以在论文改进方向里提一句 MD5 加盐或 BCrypt 方案，属于答辩加分点，但别真在源码里改——改了密码校验逻辑，原项目所有测试用例可能全挂。
4.2 借书还书：状态流转与事务控制
借书是核心业务，也是逻辑上最容易出问题的地方。用户在图书列表页点借阅按钮，把 bookId 传到 BorrowServlet，Servlet 需要做两件事：往 borrow_record 插入一条状态为在借的记录，同时把 book_info 的库存减一。这两步必须放在同一个事务里，否则会出现记录插了但库存没减的脏数据。下面这段是 BorrowService 里的核心代码，事务控制写在 Service 层。
public boolean borrow(Connection conn, int userId, int bookId) { String insertRecord = "INSERT INTO borrow_record(id, user_id, book_id, borrow_date, status) " + "VALUES (seq_record_id.NEXTVAL, ?, ?, SYSDATE, 0)"; String updateBook = "UPDATE book_info SET stock = stock - 1 WHERE id = ? AND stock > 0"; try { conn.setAutoCommit(false); try (PreparedStatement ps1 = conn.prepareStatement(insertRecord); PreparedStatement ps2 = conn.prepareStatement(updateBook)) { ps1.setInt(1, userId); ps1.setInt(2, bookId); ps1.executeUpdate(); ps2.setInt(1, bookId); int rows = ps2.executeUpdate(); if (rows == 0) { conn.rollback(); return false; // 库存不足或图书不存在 } conn.commit(); return true; } } catch (SQLException e) { try { conn.rollback(); } catch (SQLException ex) { ex.printStackTrace(); } e.printStackTrace(); return false; } }这段代码的要点是 UPDATE 语句带上了AND stock > 0条件，executeUpdate 返回 0 就说明没更新成功，借此判断库存不足，比先 SELECT 再 UPDATE 更安全。借书日期直接用 Oracle 的 SYSDATE 取数据库当前时间，比在 Java 里new Date()再传参少一步转换。还书逻辑正好相反：把 borrow_record 的 status 改成 1、写入 return_date，再把 book_info 的 stock 加回去，同样要走事务。如果资源里有 due_date 字段做逾期判断，就用 SYSDATE 和 due_date 比较；没有的话自己补一列，不复杂。
注意这段代码里的 Connection 是从外面传进来的，不是 DBUtil.getConnection() 现取的。原因很简单：事务要保证多条 SQL 用同一个连接，如果每条 SQL 各取各的连接，事务就失效了。正确做法是在 Service 层开连接、开事务，调用完 DAO 后统一 commit 或 rollback，最后在 finally 里关闭连接。
4.3 借阅记录查询：单用户视角与全量视角
用户能查自己的借阅记录，管理员能查所有图书的借阅信息，这两个查询在 SQL 上只差一个 WHERE 条件的区别。用户视角的 SQL 是借阅记录表 JOIN 图书表 WHERE user_id = 当前登录用户，管理员视角去掉 WHERE 或按图书维度聚合。用 JOIN 而不是查两次表再手动拼对象，能让代码量减少一半，可读性也好得多。
SELECT r.id, b.book_name, r.borrow_date, r.return_date, r.status FROM borrow_record r JOIN book_info b ON r.book_id = b.id WHERE r.user_id = ? ORDER BY r.borrow_date DESCJSP 页面展示这张记录表时，用 JSTL 的 c:forEach 遍历 Servlet 放进 request 域的 List 集合即可。这里有一个常见翻车点：DAO 查出的 List 没放进 request 或 session 域，页面上一直接收不到数据。正确做法是request.setAttribute("recordList", list)然后转发到 recordList.jsp，页面里用requestScope.recordList取值。放 session 域虽然也能用，但用户 logout 后数据还在，下一人登录会看到上一个人的借阅记录，属于明显的安全隐患。
4.4 Ajax 无刷新借书：JSON 响应与回调
Ajax 用在借书反馈、查重等场景，目标是让用户在列表页直接操作，不需要页面跳来跳去。前端用 JQuery 的 $.ajax 发 POST 请求，后端 Servlet 返回 JSON 字符串，前端在 success 回调里根据返回的 code 决定显示成功还是失败提示。后端响应代码一般长这样。
response.setContentType("application/json;charset=UTF-8"); PrintWriter out = response.getWriter(); JSONObject json = new JSONObject(); if (result) { json.put("code", 1); json.put("msg", "借阅成功"); } else { json.put("code", 0); json.put("msg", "库存不足或图书不存在"); } out.print(json.toString()); out.flush();前端页面对应的调用片段如下，注意 data 里的参数名要和 Servlet 里 getParameter 一致，写错的话后端收不到 bookId，永远提示失败。
$.ajax({ url: "borrowBook", type: "post", data: { bookId: bookId }, dataType: "json", success: function (res) { if (res.code === 1) { alert("借阅成功，请到借阅记录中查看"); location.reload(); } else { alert(res.msg); } }, error: function () { alert("请求失败，请检查网络或联系管理员"); } });这个交互模式是传统 Java Web 项目里最常见的局部更新方案。理解它以后再去看 SpringBoot 的 @ResponseBody 返回 JSON，会发现原理完全一样，只不过 Spring 把 JSON 序列化自动做了。如果资源包里没有引入 fastjson 或 Gson 这类库，后端手拼 JSON 字符串也可以，格式简单时成本不高。要留意 JSONObject 的依赖 jar 必须放进 WEB-INF/lib，否则运行时直接抛 NoClassDefFoundError。
4.5 管理员功能：图书类型的增删改查
管理员端功能基本是标准 CRUD：添加图书类型、删除图书类型、添加图书、修改图书信息、查看所有用户、查看借阅信息。增删改页面大同小异：一个表单加一个 Servlet，SQL 用 INSERT、UPDATE、DELETE。真正有坑的是删除图书类型：如果 book_info 里还有图书引用该 type_id，直接 DELETE 会报 ORA-02292 违反完整性约束错误。解决方案是删除前先查关联数量，有引用则提示无法删除；或者用逻辑删除标记代替物理删除，在 book_type 表加一个 status 字段区分启用和停用。这个坑在答辩演示时很容易被抓到，提前处理掉能省去很多尴尬。
5. 避坑与常见问题：驱动、乱码、密码过期六条记录
系统跑不起来、页面乱码、数据库连不上——这套资源最让人受挫的地方不在业务逻辑，而在环境。下面六条是拆这类毕设的血泪经验，按现象、原因、解决三段列清楚，每一条都遇到过不止一次。
5.1 ClassNotFoundException: oracle.jdbc.driver.OracleDriver
现象：启动 Tomcat 访问任意页面就报 ClassNotFoundException，找不到 oracle.jdbc.driver.OracleDriver 这个类。
原因：Oracle 的 JDBC 驱动 jar 没有放进 WEB-INF/lib 目录，或者放进去但没重启 Tomcat。毕设项目源码往往不带第三方 jar，或者只带了源码目录，驱动需要自己补。
解决：把 ojdbc6.jar（对应 Oracle 11g）复制到项目 WEB-INF/lib 下，右键 Build Path → Add to Build Path，清理 Tomcat 缓存后重启。如果本地是 JDK 8 以上，换成 ojdbc8.jar 避免驱动和 JDK 版本不兼容。
5.2 ORA-12505: 监听程序无法识别连接描述符中的 SID
现象：启动后尝试连接数据库报 ORA-12505，Oracle 服务已启动但连接失败。
原因：JDBC URL 里的服务名写错。正确格式是jdbc:oracle:thin:@localhost:1521:orcl，冒号和斜杠很容易搞混。另外，如果安装 Oracle 时全局数据库名不是 orcl，这里也要对应修改。
解决：用 SQL Plus 执行SELECT VALUE FROM V$PARAMETER WHERE NAME='service_names'查实际服务名，然后修正 DBUtil 里的 URL。同时检查安装目录下 listener.ora 中配置的 SID_NAME 是否与实际一致，修改后重启监听服务才生效。
5.3 页面中文全部变问号或乱码
现象：登录注册后，页面上所有中文书名、作者、出版社显示为乱码。
原因：三层编码不一致。JSP 的 pageEncoding、Servlet 里的 request.setCharacterEncoding、Oracle 数据库字符集三者不对齐，最常见的是数据库是 ZHS16GBK 而页面用 UTF-8。
解决：统一为 UTF-8 最省事。JSP 文件头写<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8" %>，Servlet 的 doPost 开头加request.setCharacterEncoding("UTF-8")，Tomcat 的 server.xml 里 Connector 加URIEncoding="UTF-8"。数据库字符集查 NLS_CHARACTERSET，不是 AL32UTF8 的话，不重建库就只能在 JDBC URL 后面补 NLS 参数，但最干净的方案还是用 UTF-8 建库。
5.4 ORA-28001: 密码已过期
现象：数据库正常用了一个多月，某天项目突然连不上，SQL Developer 登录提示密码过期。
原因：Oracle 11g 默认有密码有效期策略，默认 180 天过期，过期后旧密码被拒绝。
解决：用 SQL Plus 以管理员身份登录执行ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;，再给业务用户重置密码ALTER USER library IDENTIFIED BY library123;。新装 Oracle 建议第一步就关掉这个限制，避免项目演示当天数据库突然拒绝连接。
5.5 Ajax 请求成功但页面不更新
现象：点击借书按钮，浏览器调试里请求已发出、返回正常，但图书列表和借阅状态没有变化。
原因：success 回调里没有刷新数据区域。要么借书成功后没调用 location.reload() 或重新加载列表的 JS 函数；要么后端返回的 JSON 字段和前端判断对不上，比如后端返回 status 而前端判断的是 code。
解决：先在浏览器 Console 里console.log(res)看返回对象的实际字段，再调整前端判断逻辑。列表不刷新的话，在 success 里执行location.reload()或封装一个 loadBookList() 方法重新拉数据，保证借书后列表同步。
5.6 论文说 Spring 但代码里没有 Spring 依赖
现象：资源包里有论文和源码，但源码里找不到 spring 相关 jar，也搜不到 @Autowired 或 XML 配置。
原因：摘要里写了 Java spring，但实际编码是传统 JSP + Servlet 路线，Spring 只作为背景理论出现在论文前两章，代码没有任何框架。
解决：不强行往项目里塞 Spring 框架，直接用现有结构跑通功能。开题和答辩时把「共享」和「管理系统」两个关键词解释清楚即可。如果学校硬性要求必须有框架，再按第 6 章的迁移路径逐步改造到 SpringBoot，风险可控。
6. 验证与改造升级：从跑通到能答辩
6.1 功能验证清单
项目跑起来后，按下面这张清单做一轮回归测试。这套测试本身也是论文第五章的素材，测试数据用同一本图书做借出、归还、再借出的循环，验证库存数量是否正确变化。
| 测试模块 | 操作步骤 | 预期结果 |
|---|---|---|
| 用户注册 | 填写用户名、密码、姓名、电话 | 注册成功并跳转登录页 |
| 用户登录 | 正确密码和错误密码各一次 | 正确进入首页，错误显示提示 |
| 图书检索 | 按书名关键词查询 | 展示匹配列表 |
| 借书 | 选择在馆图书点击借阅 | 库存减一，生成借阅记录 |
| 还书 | 在借阅记录中点击还书 | 状态变已还，库存加一 |
| 管理员添加图书 | 选择类型、填写信息、设置库存 | 图书列表出现新记录 |
| 管理员删除类型 | 删除有图书引用的类型 | 提示无法删除 |
测试要重点盯两个边界：同一用户重复借同一本书的状态流转，以及库存为 0 时借书按钮的表现。这两处最容易出脏数据，也是答辩评委最可能提问的点。
6.2 从 JSP + Servlet 迁移到 SpringBoot
如果想把这份资源升级成 SpringBoot 写法，按这个顺序改最稳。第一步，用 Spring Initializr 新建工程，引入 spring-boot-starter-web、spring-boot-starter-jdbc、ojdbc8 依赖。第二步，把原 DAO 类里的 Connection、PreparedStatement 全部替换成 JdbcTemplate 的 queryForObject、update 方法，每个方法体量能缩到原来三分之一。第三步，把 web.xml 里的 Servlet 映射改成 @WebServlet 注解或 Controller 类，原业务逻辑代码可以直接搬进 Service 层。第四步，JSP 页面临时保留，移到 src/main/resources/META-INF/resources 目录下，后续再按需替换成 Thymeleaf。
改造过程中原项目的表结构和业务逻辑完全不用动，DAO 层改完跑一次借还书流程验证即可。整个迁移工作量大概一到两天，比从零写快得多——这就是有现成资源打底的价值。
这套资源适合两类人：一是需要一个能跑通的毕设/课设底子，把论文、数据库脚本、源码打包成完整交付物；二是想搞明白传统 B/S 项目请求从哪里来、数据在哪落地的初学者。当年我拿到第一份 JSP 项目时，为了搞清楚 Session 为什么存不住登录状态，在过滤器里卡了一整晚，后来才发现是 web.xml 的 URL 匹配写错。从那以后我每次拿到同类资源，都强制自己先跑通登录再改业务——登录通了，整个项目就等于通了七成。这份资源也一样，先把 Oracle 连上、把登录跑起来，后面的借书还书就是按模板循环。希望帮到你。
本文还有配套的精品资源，点击获取
