企业官网建设流程全解析

简介：《基于Java Web的图书管理系统的设计与实现》是一份完整的Java Web课程设计/毕业设计文档，适合计算机相关专业学生、毕业设计撰写者以及需要开发图书管理系统的开发者参考。文档基于MVC设计模式与Struts框架，后端采用SQL Server数据库并通过JDBC连接，系统涵盖系统设置、读者管理、图书管理、图书借还、系统查询和更改口令六大功能模块。内容包含需求分析、可行性评估、数据库表结构设计（如图书信息表、读者信息表、借阅信息表等）、系统总体结构及各模块详细设计，目录结构清晰，章节安排完整，便于按开发流程阅读或引用。资源为1个docx文件，共2.34MB，已有384人学习下载，可用于理解Java Web项目开发流程、学习业务模块划分与数据库建模思路，也可作为同类系统设计报告的写作参考。

1. 图书管理系统这个毕设题，为什么年年有人做、年年有人翻车

「基于Java Web的图书管理系统的设计与实现」大概是高校毕设里出现频率最高的题目之一。每个做这个题的人最初都觉得它简单：无非就是图书增删改查、读者管理、借书还书几张页面。但真正动手后才发现，Servlet 和 JSP 能跑通一个登录页，和能跑通一个借阅闭环，中间隔着好几个深坑——Session 校验、事务边界、分页参数、外键约束、MySQL 8 的驱动配置，任何一个环节卡住，都能让项目在答辩前一周还处于「能启动但点两下就报错」的状态。

这篇文章不是给你讲图书管理系统的业务有多伟大，而是按我这些年带毕设、帮人排错的经验，把这个题目从选型到落地完整拆一遍：技术栈怎么选最稳、数据库怎么设计才经得起答辩追问、核心代码怎么写才不翻车、以及哪些坑是 90% 的人都会踩的。适合正在做这个毕设、或者打算用 Java Web 练手的小团队照着复现——照着做，你能在两周内跑通一个拿得出手的完整系统。

2. 技术栈选型：为什么 Servlet + JSP + JDBC 仍是毕设最稳组合

2.1 三层架构怎么切，决定你后面代码能不能写下去

做图书管理系统这类题，最常见的败因不是不会写代码，而是把所有代码堆在一起：JDBC 连接写在 JSP 里、SQL 拼在 Servlet 中、页面里混着业务逻辑。前期确实快，但一旦做到借阅功能，需要同时操作图书表和借阅记录表时，这种写法就彻底失控了。

我一般会建议按三层架构切，这是 Java Web 最经典也最容易被答辩老师认可的结构：

• 表示层（View）：JSP 页面，只负责展示数据和接收表单参数。
• 控制层（Controller）：Servlet，负责取参数、调服务、转发或重定向。
• 业务与数据层（Service + DAO）：Service 管业务逻辑（判断库存、计算逾期），DAO 管 JDBC 数据访问。

项目结构按这个分，包名也对应好：

src/main/java ├── com.library.controller // Servlet ├── com.library.service // 业务接口与实现 ├── com.library.dao // 数据访问接口与实现 ├── com.library.entity // 实体类 Book, Reader, BorrowRecord ├── com.library.util // DBUtil, 分页工具类 └── com.library.filter // 登录过滤器

这个结构看起来多了一层，但对图书管理系统这种规模的项目来说，它的价值在于：每个类的职责单一，答辩时老师问「借书流程怎么实现的」，你能明确说出「Servlet 接收请求 → Service 调 DAO 更新图书表和插入借阅记录 → 返回结果页面」，而不是含糊地说「就在那个 JSP 里写的」。

分层还有一个实际好处：Service 层的事务控制有了明确的落点。后面讲借还书的事务边界时你就会发现，事务代码写在 Service 里是唯一合理的选择。

2.2 用 Maven 还是不用 Maven：两种项目结构的落地差异

如果你在头歌这类在线实训环境里练过 Java Web，大概率见过直接往 WEB-INF/lib 里丢 jar 包的做法。这种方式对纯学习没问题，但做毕设我强烈建议用 Maven——理由很实际：第一，依赖版本不用自己到处找；第二，项目换电脑后一条mvn clean package就能重新构建；第三，答辩时老师看到 pom.xml 会比看到一堆手动导入的 jar 包更认可。

用 Maven 建项目时，关键是把打包方式设成 war，并确保依赖范围正确：

<packaging>war</packaging> <dependencies> <!-- Servlet API，编译期使用，Tomcat 已自带 --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> <!-- JSP API，同样由容器提供 --> <dependency> <groupId>javax.servlet.jsp</groupId> <artifactId>javax.servlet.jsp-api</artifactId> <version>2.3.3</version> <scope>provided</scope> </dependency> <!-- MySQL 驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <!-- JSTL 标签库，JSP 里做循环与判断用 --> <dependency> <groupId>jstl</groupId> <artifactId>jstl</artifactId> <version>1.2</version> </dependency> </dependencies>

这里有个参数细节要重点说明：<scope>provided</scope>意味着这个 jar 只在编译和测试时使用，打包时不会塞进 WAR。如果去掉这个配置，Tomcat 启动时会出现 jar 包冲突导致的java.lang.NoSuchMethodError，这是 Maven 项目最常见的翻车原因之一。

JSP 文件里用 JSTL，需要引入标签库指令。这点经常被忽视，导致页面报 500 错误，提示找不到标签描述符：

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

2.3 Java Web 项目的最小运行环境：Tomcat、JDK、MySQL 版本怎么配

版本搭配是这个题目里最「玄学」的部分。很多人明明代码写得没问题，但环境版本不对，启动就报奇怪错误。我的经验是：JDK 1.8 + Tomcat 9 + MySQL 8.0 + Maven 3.6 以上的组合最稳，网上能找到的绝大多数解决方案都基于这个组合。

Tomcat 版本和 JDK 有对应关系：Tomcat 9 要求 JDK 8 及以上，Tomcat 10 则需要 JDK 11 及以上，而且 Tomcat 10 把包名从javax.servlet改成了jakarta.servlet。如果你在网上抄的代码用的是javax.servlet.http.HttpServlet，却配了 Tomcat 10，会直接编译不过。这个坑非常隐蔽，因为报错信息看起来像是「找不到类」，实际是包名迁移问题。

MySQL 8 的 JDBC 连接串和 5.x 有显着差异，这也是老代码拷过来必翻车的点。MySQL 8 的驱动类名是com.mysql.cj.jdbc.Driver，连接串需要带时区和 SSL 配置：

Class.forName("com.mysql.cj.jdbc.Driver"); String url = "jdbc:mysql://localhost:3306/library_db" + "?useUnicode=true&characterEncoding=utf8" + "&serverTimezone=Asia/Shanghai" + "&useSSL=false&allowPublicKeyRetrieval=true";

serverTimezone和useSSL=false这两个参数缺一不可。MySQL 8 默认要求 SSL 连接，而开发环境的 MySQL 通常不配 SSL 证书，allowPublicKeyRetrieval=true是解决Public Key Retrieval is not allowed报错的关键参数。这三项是 JDBC 连接 MySQL 8 最典型的坑，后面避坑章里会再展开讲排查过程。

3. 数据库与权限模型：把图书、借阅、读者三张核心表先立住

3.1 五张核心表的设计与字段说明（含建表 SQL）

图书管理系统的数据库设计，直接决定了后面功能的复杂度和答辩时能讲多深。最简版的图书系统可能只需要两张表：图书表和读者表。但这样设计会带来一个致命问题——借阅记录没有地方存，还书日期、逾期状态全部无法实现。

我的建议是至少建五张表：book（图书表）、reader（读者表）、admin（管理员表）、borrow_record（借阅记录表）、category（图书分类表）。其中分类表可以简化，但借阅记录表绝不可省，它是整个系统的数据核心。

下面是一份经过验证的建表 SQL，字段命名和类型都考虑到了实际业务场景：

CREATE DATABASE library_db DEFAULT CHARACTER SET utf8mb4; USE library_db; -- 图书分类表 CREATE TABLE category ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL UNIQUE COMMENT '分类名称，如：文学、计算机', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 图书表 CREATE TABLE book ( id INT PRIMARY KEY AUTO_INCREMENT, isbn VARCHAR(20) NOT NULL UNIQUE COMMENT 'ISBN，防止重复录入', name VARCHAR(100) NOT NULL COMMENT '书名', author VARCHAR(50) COMMENT '作者', publisher VARCHAR(100) COMMENT '出版社', category_id INT COMMENT '所属分类', total_count INT NOT NULL DEFAULT 1 COMMENT '馆藏总量', remain_count INT NOT NULL DEFAULT 1 COMMENT '当前可借数量', location VARCHAR(50) COMMENT '书架位置，如 A-03-02', status TINYINT DEFAULT 1 COMMENT '1-上架 0-下架', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_book_category FOREIGN KEY (category_id) REFERENCES category(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 读者表 CREATE TABLE reader ( id INT PRIMARY KEY AUTO_INCREMENT, reader_no VARCHAR(20) NOT NULL UNIQUE COMMENT '借书证号', name VARCHAR(50) NOT NULL, phone VARCHAR(20), password VARCHAR(100) NOT NULL COMMENT '登录密码，建议存 MD5 或加盐哈希', max_borrow_count INT DEFAULT 5 COMMENT '最大可借数量', status TINYINT DEFAULT 1 COMMENT '1-正常 0-冻结', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 借阅记录表 CREATE TABLE borrow_record ( id INT PRIMARY KEY AUTO_INCREMENT, book_id INT NOT NULL, reader_id INT NOT NULL, borrow_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '借出时间', due_time DATETIME COMMENT '应还时间，通常为借出时间加30天', return_time DATETIME COMMENT '实际归还时间，NULL表示未还', status TINYINT DEFAULT 0 COMMENT '0-借出中 1-已归还 2-已逾期', CONSTRAINT fk_br_book FOREIGN KEY (book_id) REFERENCES book(id), CONSTRAINT fk_br_reader FOREIGN KEY (reader_id) REFERENCES reader(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 管理员表 CREATE TABLE admin ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有几个字段设计是必须说明白的。book表里的total_count和remain_count是两个字段，不能合并——remain_count会随借还动态变化，而total_count记录的是初始馆藏，用来判断某个书是否「全部借出」。如果只用一个字段，还书时就无法区分「增加了库存」还是「恢复了原本的库存」。

borrow_record表里的due_time是一个容易被忽略但极其实用的字段。常见错误做法是不存应还时间，每次计算逾期时用borrow_time + 30天做动态运算。这么做功能上也能跑，但问题在于：如果业务规则变了（比如改为普通读者借期 30 天、教师借期 60 天），已经产生的借阅记录会被规则变化影响，历史数据就全乱了。把due_time固化下来，能让规则变更只影响新借阅记录。

3.2 借阅状态机与超期计算：这不是加个字段那么简单

借阅状态是图书管理系统核心逻辑里最容易做砸的部分。很多人的实现方式是「在页面用 if 判断借出时间是否超过30天」，这只能在展示层显示一个结果，无法支撑「逾期提醒列表」「逾期罚款统计」这类功能。

正确的做法是把状态做成状态机，并允许状态流转而不是实时计算。borrow_record.status的合法流转路径是：

0-借出中 → 1-已归还（正常还书） 0-借出中 → 2-已逾期（定时任务或借阅查询时更新） 2-已逾期 → 1-已归还（逾期后还书，状态收归为已归还，但可加一个逾期天数标记）

为了避免在业务代码里到处写new Date()然后比较这种散乱逻辑，我会把状态更新收敛成一个服务方法。这个方法在查询借阅列表时调用，将超期未还的记录从状态 0 刷成状态 2：

public void updateOverdueRecords() { String sql = "UPDATE borrow_record SET status = 2 " + "WHERE status = 0 AND due_time < NOW()"; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.executeUpdate(); } catch (SQLException e) { LOGGER.error("更新逾期记录失败", e); throw new RuntimeException("更新逾期记录失败", e); } }

这段 SQL 的关键在于due_time < NOW()这个判断。为什么不写成borrow_time + INTERVAL 30 DAY < NOW()？因为一旦改过借期规则，这个 SQL 会把历史记录按新规则重新计算，导致错误逾期。使用due_time字段配合UPDATE ... WHERE status = 0，能保证状态只会从借出中流转为逾期，不会把已归还的记录重新刷成逾期。

实际调用这个方法的时机，一般在两个地方：一是管理员进入「借阅记录」页面前调用，二是返回图书列表前调用。这个方案能保证逾期状态在页面可见之前就已经落库，而不是每次查询都现算。

3.3 管理员与读者的角色权限怎么落进表结构

图书管理系统的用户分两种角色：管理员和读者。最简实现是在一张用户表里加role字段区分，但对于这个题目，我建议拆成admin和reader两张表，理由在答辩时也站得住：管理员和读者的字段完全不同——管理员只有用户名和密码，读者有借书证号、电话、最大借书数、冻结状态。强行合成一张表，会出现大量 NULL 字段，数据库规范上就说不过去。

权限控制的核心是登录后的 Session 区分。管理员登录后存admin的 id 和 username，读者登录后存reader的 id 和 name。然后通过一个 Filter 拦截未登录请求，并在 JSP 页面上根据 Session 属性决定展示哪些操作入口：

@WebFilter(urlPatterns = {"/*"}) public class LoginFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse resp = (HttpServletResponse) response; String uri = req.getRequestURI(); // 登录和静态资源放行 if (uri.endsWith("/login") || uri.endsWith("/login.jsp") || uri.contains("/css/") || uri.contains("/js/")) { chain.doFilter(request, response); return; } // 读者请求管理员页面或管理员请求读者页面时拒绝 if (uri.contains("/admin/") && req.getSession().getAttribute("adminUser") == null) { resp.sendRedirect(req.getContextPath() + "/login.jsp"); return; } if (uri.contains("/reader/") && req.getSession().getAttribute("readerUser") == null) { resp.sendRedirect(req.getContextPath() + "/login.jsp"); return; } chain.doFilter(request, response); } }

这个 Filter 的 URL 匹配策略是我反复调整后的经验值：把所有需要鉴权的页面按路径前缀分组，/admin/开头的必须是管理员，/reader/开头的必须是读者，而不是在每一个 Servlet 里重复写 Session 判断。如果不用 Filter，十个 Servlet 里就有十份重复的 Session 检查代码，后面新增功能时忘加一个，就是未授权访问漏洞。

4. 从登录页到借阅闭环：核心功能的分层实现

4.1 登录与 Session 校验：拦截器还是 Filter

图书管理系统的登录功能是整个系统被访问最多的入口，也是很多人在答辩演示时最容易出状况的地方——经常是登录成功后刷新页面又跳回登录页，或者登录失败时错误提示一闪而过看不到具体原因。

登录的完整逻辑分三步：取参数 → 查表验证 → 写 Session。这里有一个容易被忽略的参数问题：登录表单的账号密码是中文还是英文其实不重要，重要的是 Servlet 里取参数之前必须设置 UTF-8 编码。如果漏掉request.setCharacterEncoding("UTF-8")，读者姓名中含中文就会在验证时匹配不到数据库记录，造成「明明密码对但登录失败」的诡异现象。

登录 Servlet 的核心验证逻辑如下：

@WebServlet("/login") public class LoginServlet extends HttpServlet { private ReaderService readerService = new ReaderServiceImpl(); private AdminService adminService = new AdminServiceImpl(); @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { req.setCharacterEncoding("UTF-8"); String role = req.getParameter("role"); // "reader" 或 "admin" String username = req.getParameter("username"); String password = req.getParameter("password"); if ("admin".equals(role)) { Admin admin = adminService.login(username, password); if (admin != null) { req.getSession().setAttribute("adminUser", admin); resp.sendRedirect(req.getContextPath() + "/admin/index.jsp"); } else { req.setAttribute("error", "管理员账号或密码错误"); req.getRequestDispatcher("/login.jsp").forward(req, resp); } } else { Reader reader = readerService.login(username, password); if (reader != null) { // 检查是否冻结 if (reader.getStatus() == 0) { req.setAttribute("error", "该借书证已被冻结，请联系管理员"); req.getRequestDispatcher("/login.jsp").forward(req, resp); return; } req.getSession().setAttribute("readerUser", reader); resp.sendRedirect(req.getContextPath() + "/reader/index.jsp"); } else { req.setAttribute("error", "读者账号或密码错误"); req.getRequestDispatcher("/login.jsp").forward(req, resp); } } } }

关于「跳转页面用 redirect 还是 forward」，我建议登录成功后一律用sendRedirect，登录失败才用forward。原因是 Post-Redirect-Get 模式：如果登录成功用forward，浏览器的地址栏仍然是/login，用户按 F5 刷新会重新提交表单，导致重复登录。用redirect跳到/admin/index.jsp后，地址栏变成目标页面地址，刷新就是普通的 GET 请求，不会有副作用。

关于 Filter 还是 Spring MVC 的 Interceptor——标题锁定了 Java Web 技术栈，没有 Spring 容器，所以 Filter 是唯一合适的选择。如果你后期想升级 Spring Boot，Interceptor 的拦截思路和 Filter 基本一致，迁移成本不高。

4.2 图书检索与分页：为什么 limit 翻页一直有坑

图书检索是图书管理系统里查询最频繁的功能，也是把「读代码的能力」和「写代码的能力」区分开的一个点。不少人的实现是SELECT * FROM book WHERE name LIKE '%关键字%'然后全量丢到页面上。书少时无所谓，一旦馆藏几千册，这种做法会导致页面卡顿、数据量不可控，更严重的是——答辩老师如果问「数据量大了怎么办」，你答不上来。

可靠的做法是做分页查询，并配一个独立的分页工具类。分页 SQL 的标准写法是LIMIT offset, size，但很多人会在前端页面上直接拼页码参数，引发两个问题：第一，页码参数没有校验，?page=-1会被 MySQL 解析成 offset 为负数然后报错；第二，排序字段如果由前端传参拼进 SQL，会引入 SQL 注入风险。

图书检索的 DAO 层实现如下：

public List<Book> searchBooks(String keyword, int pageNum, int pageSize) { StringBuilder sql = new StringBuilder( "SELECT * FROM book WHERE status = 1"); List<Object> params = new ArrayList<>(); if (keyword != null && !keyword.trim().isEmpty()) { sql.append(" AND (name LIKE ? OR author LIKE ? OR isbn LIKE ?)"); String likeParam = "%" + keyword.trim() + "%"; params.add(likeParam); params.add(likeParam); params.add(likeParam); } // 排序可以固定在 id 上，保证翻页顺序稳定 sql.append(" ORDER BY id DESC LIMIT ?, ?"); int offset = (pageNum - 1) * pageSize; params.add(offset); params.add(pageSize); // 执行查询并封装结果返回 return queryList(sql.toString(), params); }

这里有三个关键点需要展开。第一，LIMIT ?, ?的参数必须用 PreparedStatement 绑定，不能直接拼字符串，否则用户输入1; DROP TABLE book; --这类值会让整个系统崩溃。第二，offset的计算要在 Service 层完成，页面传来的 pageNum 先做校验，小于 1 的强制改为 1，大于总页数的兜底为最后一页。第三，总页数的计算需要一个额外查询SELECT COUNT(*) FROM book WHERE status = 1，这个 count 查询最好放在分页查询之前，并缓存到 Service 层——不建议每次翻页都重新 count，但毕设规模下不需要做太多优化，保持代码可读性优先。

4.3 借书/还书的事务边界：两行 UPDATE 也要用事务

借书和还书是这个系统里唯一涉及多表写入的操作，也是事务控制的主战场。借书需要做两件事：往borrow_record插入一条借阅记录，同时把book.remain_count减 1。还书则反过来：更新borrow_record的return_time和status，同时把book.remain_count加 1。

很多人在这里犯的一个经典错误是：先执行插入，再执行更新，两条 SQL 都不是事务的——第一条执行成功、第二条失败时，数据库会留下一条没有库存扣减的借阅记录，或者还书后库存没加回来。这个问题不频繁出现，但一旦出现（比如 MySQL 连接在第二步中断），数据就永久性错乱，而且极难排查。

正确的实现是把两条 SQL 放到一个事务里。我的做法是在 Service 层获取连接、关闭自动提交、执行完毕后统一提交或回滚：

public void borrowBook(int bookId, int readerId, int borrowDays) { Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 开启事务 // 1. 检查库存 Book book = bookDao.findById(conn, bookId); if (book == null || book.getRemainCount() <= 0) { throw new BusinessException("图书不存在或已无库存"); } // 2. 插入借阅记录 Date dueTime = DateUtil.addDays(new Date(), borrowDays); borrowDao.insert(conn, bookId, readerId, dueTime); // 3. 扣减库存 int updated = bookDao.decreaseRemainCount(conn, bookId); if (updated == 0) { throw new BusinessException("库存扣减失败，请重试"); } conn.commit(); // 全部成功才提交 } catch (Exception e) { if (conn != null) { try { conn.rollback(); } catch (SQLException ex) { LOGGER.error("回滚失败", ex); } } throw new RuntimeException("借书失败：" + e.getMessage(), e); } finally { if (conn != null) { try { conn.setAutoCommit(true); conn.close(); } catch (SQLException e) { LOGGER.error("关闭连接失败", e); } } } }

这里有一个细节值得注意：decreaseRemainCount的 SQL 应该是UPDATE book SET remain_count = remain_count - 1 WHERE id = ? AND remain_count > 0。这样写能在数据库层面防止库存变成负数。如果只写UPDATE book SET remain_count = remain_count - 1 WHERE id = ?，当并发借阅发生时可能把库存扣成 -1，而且 Service 层的 if 检查根本拦不住并发。

事务边界要放在 Service 层而不是 DAO 层，这是 Java Web 事务控制的常识性结论——DAO 只负责单表操作，事务是跨 DAO 的业务行为。把事务代码污染进 DAO，会让每个 DAO 方法都背上连接管理的负担，后续想换连接池时重构量巨大。

5. Java Web 图书管理系统避坑清单：环境与代码里的 5 个高频翻车点

5.1 现象：Tomcat 启动正常，但访问任意页面都是 404

这是我见过最多的启动问题。代码编译通过、Tomcat 也启动了，但浏览器访问localhost:8080/项目名/永远是 404 或 403。排查时看 Tomcat 控制台又没有明显报错。

原因通常有三个。第一，WAR 包没有正确部署——用 Maven 构建后，没有把target/项目名.war拷到 Tomcat 的webapps目录，或者 IDEA 里没有配置 Artifact 为war:exploded且 Deployment 里没有加项目。第二，访问路径写错——项目名（context path）和你输入的不一致，localhost:8080/library/和localhost:8080/booksystem/差一个字符就全是 404。第三，web.xml里的<welcome-file-list>配置不当，访问根路径时找不到欢迎页。

解决方法是先访问http://localhost:8080/看 Tomcat 默认首页是否正常，正常则说明 Tomcat 本身没问题，接下来检查 IDEA 的 Deployment 配置里的 Application context 是否和浏览器地址一致。注意修改 context path 后必须重启 Tomcat，热部署经常不生效。

5.2 现象：JDBC 首次连接报 Public Key Retrieval is not allowed

MySQL 8 的驱动和旧版驱动行为不同。用Class.forName("com.mysql.jdbc.Driver")会直接报ClassNotFoundException，因为 MySQL 8 的驱动类已经改名为com.mysql.cj.jdbc.Driver。而用新版驱动连接时，如果连接串少了配置项，会报Public Key Retrieval is not allowed或Connection refused。

原因是 MySQL 8 默认使用 caching_sha2_password 认证插件，客户端首次连接需要从服务器获取公钥来加密密码传输，服务器出于安全策略默认不允许这个行为。解决方式就是在连接串上追加allowPublicKeyRetrieval=true&useSSL=false。另一个关联项是serverTimezone：MySQL 8 的驱动要求显式指定时区，否则报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。这三个参数是一起出现的，缺一不可，建议直接从第三节贴的连接串复制使用。

5.3 现象：存进数据库是中文，查出来变成问号

中文乱码是 Java Web 项目里历史最悠久的坑，而且它是三处独立的编码问题叠加导致的。第一处是 JSP 页面的pageEncoding和contentType不一致；第二处是 Servlet 接收 POST 请求时没有设置setCharacterEncoding；第三处是 MySQL 连接的 URL 没有指定characterEncoding=utf8，或者建表时字符集是默认的 latin1。

排查思路要按链路走：先看数据库表字符集，执行SHOW CREATE TABLE book，确认CHARSET=utf8mb4；再看连接串，缺characterEncoding=utf8就补上；最后看 JSP，统一写成：

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

注意一个隐蔽点：GET 请求的乱码和 POST 请求的乱码不是一套解决方案。POST 用request.setCharacterEncoding("UTF-8")能解决，但 GET 请求的中文参数是 Tomcat 解析 URL 时解码的，需要在 Tomcat 的server.xml里给 Connector 加URIEncoding="UTF-8"。如果用 IDEA 内置的 Tomcat，这个参数在 Run Configuration 中配置。

5.4 现象：删除图书时外键约束挡住了，DELETE 直接报错

图书表的外键category_id指向分类表，借阅记录表的外键book_id指向图书表。管理员想在后台删掉一个分类或下架一本书，结果 SQL 执行直接报Cannot delete or update a parent row: a foreign key constraint fails。

原因是经典的外键级联策略问题。我在建表 SQL 中使用了FOREIGN KEY约束但没指定ON DELETE行为，MySQL 默认是RESTRICT——禁止删除被引用的父记录。解决方式有三种，我应该按场景选择：对于图书和分类，如果分类下还有书，应该禁止删除，这符合业务逻辑，无需改动；对于图书和借阅记录，如果这本书已有历史借阅记录，物理删除会导致借阅记录里的book_id变成悬空引用。

我的建议是：不要物理删除图书，而是用status字段做逻辑删除，即把「删除操作」实现为UPDATE book SET status = 0 WHERE id = ?。这样既能保留历史借阅记录的关联完整性，又能实现图书下架效果。如果坚持物理删除，则必须先把该书的借阅记录删除或置空，这个顺序经常被忽略。

5.5 现象：Maven 项目启动报 java.lang.NoSuchMethodError

这个报错经常出现在引入某些工具类或 JSON 库时。NoSuchMethodError的含义是类存在但方法不存在——几乎都是版本冲突。最典型的是项目中同时存在多个版本的同一个库，比如传了fastjson1.x 和 2.x，而高版本的类被低版本覆盖。

排查方式是在 IDEA 终端执行mvn dependency:tree，查看依赖树中是否有重复坐标。常见冲突来源有两个：一是直接依赖传了 A 库的 1.0，另一个库间接依赖 A 库的 2.0，Maven 按最短路径原则取了 2.0，但编译时用的 1.0 的 API；二是 Tomcat 的lib目录里有同名的 jar，和项目 WEB-INF/lib 里的版本不一致。解决方法是统一版本号，或者在pom.xml中用<exclusion>排除冲突的传递依赖。这类问题没有标准答案，每次都要按依赖树具体分析。

6. 让答辩和验收站得住：除了能跑，还要能讲清楚

6.1 画一张系统架构图，文档加分效果立竿见影

很多人的毕设文档里堆了几十页代码框，却连一张架构图都没有。答辩老师不可能在你演示时读完代码，他判断你「懂不懂」往往靠二十分钟的陈述。而一张清晰的三层架构图，能在三十秒内让老师 get 到你的系统结构。

画图时不必用复杂工具，直接在 Word 里用文本框和箭头就能画清楚：最上层是 JSP 页面，中间是 Servlet 控制器，下面是 Service 接口与实现，最底层是 DAO 和 MySQL。用箭头标注依赖方向，旁边标注几个核心类名。这张图的价值在于：它同时回答了「项目怎么分层」「请求怎么流转」「数据存在哪」三个问题，比贴十页表格有用得多。

6.2 功能演示脚本：按借阅闭环走，别点哪算哪

答辩演示最常见的翻车是临场乱点，点到一个没准备好的页面就开始报错。我的建议是提前准备一条演示主线，严格按「读者登录 → 检索图书 → 借书 → 查看借阅记录 → 还书 → 管理员登录 → 查看库存变化」的顺序走。

每个操作前说一句「接下来我演示的是借书流程，注意看库存数量的变化」，让老师知道你在演示什么、关键观察点在哪。演示数据最好提前准备好——预先插入几个书名含「Java」的测试数据，检索时直接输入「Java」就能出结果，不要现场纠结关键字拼写。还书演示时注意展示return_time被正确写入，这是事务控制的直接证据，答辩时主动指出这个细节很加分。

6.3 验收前的冒烟测试清单与数据准备

答辩前一周，我建议按下面这份清单自查一遍，按顺序执行：

1. 清空数据库后重新执行建表 SQL，确认无报错。
2. 初始化数据：手动插入一个分类、三本图书、两个读者（一个正常、一个冻结）、一个管理员。
3. 用无效账号登录，确认错误提示正常显示。
4. 正常借书，确认remain_count减 1。
5. 把某本书全部借出后再次查询，确认检索结果中该书状态正确。
6. 还书，确认remain_count加回 1，borrow_record状态变为已归还。
7. 用冻结读者账号登录，确认被拦截。
8. 重启 Tomcat 后刷新之前借书的界面，确认 Session 仍存在或正确跳转登录页。
9. 在另一台机器上部署 WAR 包，确认环境无关性。

这个清单里我特别强调第 9 条——环境无关性。很多人的项目在本人电脑上跑得好好的，拿到答辩教室的电脑上就崩，原因多半是 JDK 版本、MySQL 字符集或 Tomcat 版本不一致。提前在干净环境里部署一次 WAR 包，能避免答辩现场最尴尬的场面。

我自己以前做这个题目时就吃过一次亏：答辩前一天在宿舍电脑上测试一切正常，第二天教室电脑上 MySQL 是 5.7，而我的连接串里写了 MySQL 8 的驱动类名，启动直接报ClassNotFoundException。从那以后，我养成了两个习惯：第一，连接串里的驱动类名和 URL 参数都写成 MySQL 5.7 和 8.0 兼容的形式；第二，答辩前必做一次跨机器部署测试。这个习惯后来帮我避免了很多类似问题，希望你也能在验收前留出半天做环境联调——项目能跑是底线，换个地方还能跑才叫真正做完。希望这篇拆解能帮到你。

本文还有配套的精品资源，点击获取