Java图书管理项目实战：从Servlet分层架构到事务处理完整指南

1. 项目整体设计：图书管理项目到底在练什么

先聊点实在的。图书管理项目，几乎每个学Java的人都写过一个版本，但它真的不是那种随便交差了事的课设作业。我见过不少人把这个项目做成了"数据库增删改查大杂烩"——书能加、能删、能查，然后呢？没有然后了。如果仅仅止步于此，这个项目的价值浪费了一大半。

一个真正合格的图书管理项目，从头到尾做完，应该覆盖Java后端开发的完整链路：对象建模、分层架构、JDBC操作、事务控制、Web请求处理、参数校验、异常处理、前端页面交互、部署上线。把这些知识点在一套代码里全部串起来，你才算真正"会用"Java，而不是"认识"Java。

你可能觉得"零基础入门到精通"这种话说得太满，但实际上，图书管理这个业务场景足够简单——不会像电商系统一样有复杂的订单状态机，也不会像支付系统一样有严格的对账逻辑。图书管理的核心流程就三条：录入书籍、读者借书、读者还书。业务简单，正好把精力集中在学习技术本身，而不是理解业务上。这才是它成为经典入门项目的原因。

我一般建议新手把这个项目拆成三个版本来做：

• 版本一：控制台版，纯Java SE + JDBC + MySQL，把所有核心逻辑跑通，重点练对象设计和SQL能力。
• 版本二：Web基础版，Java Servlet + JSP + JDBC，处理HTTP请求、表单提交、Session管理，项目组建成经典的MVC结构。
• 版本三：框架整合版，Spring Boot + MyBatis（可选），用主流框架重构版本二，理解框架到底解决了什么问题。

三个阶段对应了不同阶段的你。如果刚刚学完JavaSE语法，直接去啃框架会一头雾水；但如果你只停留在控制台版，又会被"Java太low了"的错觉限制住。这篇博文以版本二为主线，同时把版本三的扩展方向穿插在关键节点，你照着走，会清楚很多。

2. 技术选型与开发环境：一套零基础友好的工具链

2.1 版本选择：别一上来就追最新版

我见过太多新手死在了安装环境这一步。JAVA_HOME配好了，CLASSPATH又出问题；MySQL好不容易装上，Navicat连不上；好不容易连上了，发现版本兼容性又崩了。所以选版本的第一原则是：稳定优先，生态成熟优先，教程最多的优先。

建议这组搭配：

• JDK 8：不要犹豫，就选8。虽然JDK 17、21已经出了很久，但绝大多数公司的存量项目还在JDK 8上，网上遇到的坑几乎都有答案，很多框架也向下兼容。等理解了JDK 9+的模块化特性再切换也不迟。
• MySQL 5.7：用InnoDB引擎，三年内的教程和工具基本都适配它。
• Maven 3.6.x：做依赖管理，而不是手动往WEB-INF/lib里扔jar包。虽然初学阶段会有点不适应，但这是克制"复制粘贴jar包的混乱感"的最好方式。
• Tomcat 8.5：Servlet容器，和JDK 8搭配很稳。
• IDEA 社区版或旗舰版：旗舰版对Web开发支持更完整，社区版也完全够用。不要折腾Eclipse或NetBeans了，时间太宝贵。

这里特别强调一下：JDK别装最新的，MySQL别装带X DevAPI的默认配置，Tomcat别装10以上版本——Servlet规范变过几次名，新手报错时对不上号非常痛苦。

2.2 开发环境搭建的踩坑记录

搭建过程我不妨给你画个完整清单，每一步都有玄机：

1. 装JDK，配置JAVA_HOME和PATH。安装目录不要带空格和中文，直接放在D:\Java\jdk8这类路径下。
2. 装MySQL，一路默认安装，但要记住root密码。安装完去服务管理里确认MySQL服务是启动状态。
3. 装Maven，修改settings.xml，把本地仓库路径改到非系统盘，配置阿里云镜像源，不然下载依赖会让你等到怀疑人生。
4. 装Tomcat，解压后不要放在桌面和中文路径下，注意catalina.bat的权限问题。
5. 在IDEA里配置好Project SDK、Maven路径，然后创建Maven Web项目骨架。

五个步骤每一步都有坑。很多人MySQL装完了等下在命令行跑mysql -uroot -p报错，原因往往是服务没启动，或者环境变量没配置。我建议你装完MySQL后，顺手安装一个可视化工具（如DBeaver或Navicat），图形界面排查问题远比命令行对新手友好。

2.3 项目骨架：从一个干净的Maven结构开始

创建好Maven Web项目后，标准的目录结构是这样的：

text复制library-management
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   │   └── com.zsz.library
│   │   │       ├── entity        // 实体类
│   │   │       ├── dao           // 数据访问层
│   │   │       ├── service       // 业务逻辑层
│   │   │       ├── servlet       // 控制层（Servlet）
│   │   │       └── util          // 工具类
│   │   ├── resources
│   │   │   └── db.properties
│   │   └── webapp
│   │       ├── admin             // 后台管理页面
│   │       ├── css
│   │       ├── js
│   │       └── WEB-INF
│   │           └── web.xml
│   └── test
│       └── java

注意WEB-INF/web.xml是Servlet项目的总配置文件，初学阶段非常容易忘记注册Servlet。Servlet不是写个类就能访问的，必须要web.xml里做映射，或者用@WebServlet注解。我建议初学阶段用注解式，少写点配置内容；但一定要知道web.xml是怎么回事，毕竟工作里老项目见得多。

3. 数据库设计：图书管理系统的地基工程

3.1 五张表的逻辑推演

图书管理的表设计不算复杂，但很典型，它包含了几乎所有的表间关系基础形态：一对一、一对多、多对多。

我按推演顺序给你完整拆解。首先，必须要有图书表、读者表、分类表：

• 图书表（book）：存储书籍的基本信息。
• 读者表（reader）：存储读者信息。
• 分类表（category）：存储图书分类，一本图书属于一个分类，一个分类下有多本图书，这是一对多关系。

有了这三张基础表后，设计借阅关系时不建议直接在book表加一个borrower_id字段，因为一次借阅行为的生命周期还需要记录借书时间、应还时间、实际归还时间。所以单独建一张借阅记录表（borrow_record）。读者和图书通过借阅记录形成了多对多关系，一个读者可以借多本不同的书，一本书也可以被多个读者先后借阅。

最后，再加一张管理员表（admin），存储登录账号和密码，这就是登录验证功能的落点。

3.2 建表SQL与字段设计要点

以下是我常用的一份建表参考，字段命名单词首字母小写，多个单词用下划线分隔，这些都是约定俗成的规范：

sql复制CREATE DATABASE IF NOT EXISTS db_library DEFAULT CHARSET utf8mb4;
USE db_library;

CREATE TABLE category (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50) NOT NULL UNIQUE,
  description VARCHAR(200)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE book (
  id INT PRIMARY KEY AUTO_INCREMENT,
  isbn VARCHAR(20) NOT NULL UNIQUE,
  name VARCHAR(100) NOT NULL,
  author VARCHAR(50),
  publisher VARCHAR(50),
  category_id INT,
  total_count INT DEFAULT 0,
  available_count INT DEFAULT 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,
  card_no VARCHAR(20) NOT NULL UNIQUE,
  name VARCHAR(50) NOT NULL,
  phone VARCHAR(20),
  max_borrow_count INT DEFAULT 5,
  current_borrow_count INT DEFAULT 0,
  status TINYINT DEFAULT 1
) 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,
  due_time DATETIME,
  return_time DATETIME,
  status TINYINT DEFAULT 0 COMMENT '0-借出中 1-已归还 2-已超期',
  CONSTRAINT fk_borrow_book FOREIGN KEY (book_id) REFERENCES book(id),
  CONSTRAINT fk_borrow_reader FOREIGN KEY (reader_id) REFERENCES reader(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE admin (
  id INT PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(30) NOT NULL UNIQUE,
  password VARCHAR(64) NOT NULL,
  real_name VARCHAR(30)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

几个容易忽略却非常重要的细节：

• ISBN要加UNIQUE约束。同一本书可能有好几条记录不同批次，但ISBN是国际标准书号，重复录入说明业务有异常。
• available_count和current_borrow_count这类数据要冗余存储，不能每次借阅都去全表count一次。虽然两表数据理论上可以通过计算得出，但实际业务里冗余字段能极大提升查询效率。代价是更新时要小心同步。
• 外键约束在初学阶段建议保留，它能让InnoDB在误操作时帮你挡住一部分脏数据。工作中可能会去掉外键做分库分表，但你现在是学习阶段，有约束能帮你的数据保持正确性。
• 所有文本字段都用utf8mb4，不用utf8，后者在存emoji和生僻字时会报错。

3.3 为什么建议手工设计表，而不是用工具逆向生成

现在有各种数据库建模工具，拖拖拽拽就生成表。但我强烈建议入门阶段用手写SQL建表。原因很简单：手写SQL逼你理解每个字段的类型、长度、约束、默认值的意义。当你敲过几十行建表语句之后，再看任何现成的表结构都一目了然。建模工具生成的表往往带有冗余后缀和奇怪的命名习惯，你反而不容易学通用规范。

4. 核心功能拆分与分层开发：从一坨代码到三层架构

4.1 三层架构到底是什么意思

很多同学写了半年Java代码，还是对三层架构一知半解。所谓三层架构，是指：控制层（Controller/Servlet）接收请求参数、业务层（Service）处理业务逻辑、数据访问层（DAO）操作数据库。

我打个比方：你去餐厅吃饭。服务员（控制层）只负责记下你要什么菜，不关心菜怎么做。厨师（业务层）只知道怎么做菜，不懂如何跟顾客沟通。食材供应商（数据访问层）只管把菜送到后厨，不关心顾客点什么。三层各司其职，分别替换互不干扰。这就是分层的好处：职责单一，可替换，可测试。

初学阶段最常见的错误就是把所有代码写在一个Servlet里：从解析参数到SQL操作到生成页面全部在一个类里完成。因为案例太简单，这样做短时间确实能跑通，但一旦让项目加一个功能，改一个字段，你就知道什么叫牵一发而动全身。分层架构会在初期多写几个类，但后期省下的时间是几何倍数的。

4.2 Servlet控制层的编写规范

这里给出一个具体的Servlet编写示例。比如删除书籍的请求长这样：

java复制@WebServlet("/book/delete")
public class BookDeleteServlet extends HttpServlet {
    private BookService bookService = new BookService();

    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        req.setCharacterEncoding("UTF-8");
        String id = req.getParameter("id");

        if (id == null || id.trim().isEmpty()) {
            resp.sendRedirect(req.getContextPath() + "/book/list?error=参数错误");
            return;
        }

        boolean success = bookService.deleteBook(Integer.parseInt(id));
        if (success) {
            resp.sendRedirect(req.getContextPath() + "/book/list");
        } else {
            resp.sendRedirect(req.getContextPath() + "/book/list?error=删除失败，请检查书是否被借阅");
        }
    }
}

注意这里的几个细节：

• POST请求和GET请求要区分开。删除操作属于改变数据状态，应该用POST而不是GET。GET请求会被浏览器预加载、爬虫抓取，把删除动作放在GET里是极不安全的。
• 参数要先校验再使用。Integer.parseInt(id)在参数非法时会抛出NumberFormatException，你必须在解析前先判断空字符串。
• 业务操作的结果要反馈给页面。用redirect重定向比forward转发更适合增删改操作，因为它会刷新页面，避免用户按F5重复提交表单。

4.3 Service业务层的核心借还逻辑

借书还书是图书管理系统里最核心的业务，也是最能在面试中展开讲的环节。我们从头推演一下借书逻辑应该处理哪些点：

1. 读者是否存在且状态正常。
2. 图书是否存在且有余量。
3. 当前读者未归还的图书数量是否已经达到上限。
4. 同一本书是否已经被该读者借走且在借出中。
5. 全部校验通过后，执行扣减库存数量、增加读者借阅数、插入借阅记录三个操作。

这五步里，前四步是校验，第五步是真正的数据变更。这里就引出了一个必考的概念：事务。如果插入借阅记录成功，但扣减库存失败，数据就错乱了。所以这三个写操作必须在同一个数据库事务里执行，要么全成功，要么全失败。

在JDBC里的做法是：

java复制public boolean borrowBook(int bookId, int readerId) {
    Connection conn = null;
    PreparedStatement ps = null;
    ResultSet rs = null;
    try {
        conn = DBUtil.getConnection();
        conn.setAutoCommit(false);  // 开启事务

        // 1. 查询并锁定图书行
        // 2. 更新可用库存
        // 3. 更新读者当前借阅数
        // 4. 插入借阅记录

        conn.commit();              // 全部成功，提交
        return true;
    } catch (Exception e) {
        if (conn != null) {
            conn.rollback();        // 任何一步失败，全部回滚
        }
        e.printStackTrace();
        return false;
    } finally {
        DBUtil.closeAll(rs, ps, conn);
    }
}

这里有个跟性能有关的点：查询图书时要加FOR UPDATE，把这一行数据锁住，防止两个并发请求同时读到库存为1然后都借走。这也是"乐观锁"和"悲观锁"概念的实际应用场景。入门阶段我用悲观锁，直接SELECT ... FOR UPDATE最直观；工作中高并发场景可能要换乐观锁版本控制。

4.4 DAO层的SQL防注入

DAO层是直接面对SQL的地方，新手最常见的做法是用字符串拼接SQL，这是极其危险的。举个反面教材：

java复制// 错误示范，绝对不要用
String sql = "SELECT * FROM admin WHERE username='" + username + "' AND password='" + password + "'";

如果输入的username是admin' -- ，就能绕过密码验证，这就是经典的SQL注入。正确的做法是使用PreparedStatement占位符：

java复制String sql = "SELECT * FROM admin WHERE username = ? AND password = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, username);
ps.setString(2, password);
ResultSet rs = ps.executeQuery();

PreparedStatement不仅防注入，还能预编译提升性能。记住一条铁律：任何SQL，永远不要用字符串拼接变量。

另外，DAO层还要注意资源释放。数据库连接用完必须关闭，不然连接池很快被耗尽。建议用try-with-resources语法：

java复制try (Connection conn = DBUtil.getConnection();
     PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setString(1, username);
    try (ResultSet rs = ps.executeQuery()) {
        return rs.next();  // 存在即登录成功
    }
}

4.5 前端页面：不谈美观，先谈可用

Web基础版的前端我不建议上太复杂的框架。直接使用JSP + JSTL + Bootstrap就能做出不错的页面效果。用Bootstrap栅格系统搭出导航栏、表格、表单，这些主要靠复制粘贴组件，但一定要理解页面请求是怎么发出去的。

页面的几个核心操作对应着Servlet路由，这是一张需要烂熟于心的对应表：

前端表单提交时要注意，form标签的action要填项目上下文路径加Servlet路径。很多新手在本地测试好好的，通过IP部署到服务器就404，就是因为路径少了项目名。

5. 数据库访问层优化：从连接工具类到连接池思维

5.1 手写DBUtil工具类的得与失

很多教程的第一步是写一个DBUtil类，加载驱动、获取连接、关闭资源都封装在里面。代码如下：

java复制public class DBUtil {
    private static final String URL = "jdbc:mysql://localhost:3306/db_library?useSSL=false&characterEncoding=utf8&serverTimezone=Asia/Shanghai";
    private static final String USER = "root";
    private static final String PASSWORD = "123456";

    static {
        try {
            Class.forName("com.mysql.jdbc.Driver");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }

    public static Connection getConnection() throws SQLException {
        return DriverManager.getConnection(URL, USER, PASSWORD);
    }

    public static void closeAll(ResultSet rs, Statement stmt, Connection conn) {
        if (rs != null) try { rs.close(); } catch (SQLException e) {}
        if (stmt != null) try { stmt.close(); } catch (SQLException e) {}
        if (conn != null) try { conn.close(); } catch (SQLException e) {}
    }
}

这段代码好的地方在于简洁，能让新手理解JDBC的标准套路。但它有一个致命缺陷：每次获取连接都是新建物理连接，短时间多次请求会让数据库压力陡增。实际项目都是通过数据库连接池（如Druid、HikariCP）来管理连接。到了框架版，连接池的使用是Spring Boot自动集成的，你不需要自己操心。

但建议不要跳步：先手写DBUtil，理解连接从哪来、怎么用、怎么还。然后再了解连接池的原理——它就是预先创建一批连接放在池里，你用的时候借一条，用完还回去，省去了每次创建的消耗。

5.2 参数配置外置，而不是硬编码在Java里

初学者经常把数据库用户名密码直接写在Java类里，这不好。更好的做法是把这些配置放进db.properties文件：

properties复制jdbc.driver=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql://localhost:3306/db_library?useSSL=false&characterEncoding=utf8&serverTimezone=Asia/Shanghai
jdbc.username=root
jdbc.password=123456

然后写一个工具类读取：

java复制public class ConfigManager {
    private static Properties props = new Properties();
    static {
        try (InputStream in = ConfigManager.class.getClassLoader()
                .getResourceAsStream("db.properties")) {
            props.load(in);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    public static String get(String key) {
        return props.getProperty(key);
    }
}

这样以后修改数据库密码、切换环境，都不需要改动代码，只改配置文件即可。这是配置与代码分离的思想，哪怕你现在只是一个人开发，也要养成这个习惯。

6. 借阅超期计算：一个看着简单但容易写错的业务点

6.1 超期天数的正确算法

图书管理系统里借阅天数计算堪称"看起来简单、写起来全是坑"的典型。最简单的想法是：超期天数 = 当前日期 - 应还日期。这句话没错，错在Java日期处理的方式。

先普及一个常识：每个读者的借阅期限可能不同，普通读者30天，教师读者60天，或者有不同的最大借阅数。这些业务参数要放在读者表里，甚至做成一个独立的配置表。不要把期限硬编码在Service里。

计算超期天数，需要注意：

• 计算的结果是工作日还是自然日？图书馆如果周末闭馆，超期天数应该按实际开放日计算还是按日历算？不同业务方要求不同，你要跟需求方确认清楚，不要自己拍脑袋。
• 应还日期逢节假日顺延。很多系统有这个规则，但初版项目一般不做，如果要加，需要维护一个节假日表，这又是一个练手点。

我用Java 8的LocalDate来实现最稳妥：

java复制public long calcOverdueDays(LocalDate dueDate) {
    LocalDate today = LocalDate.now();
    if (today.isAfter(dueDate)) {
        return ChronoUnit.DAYS.between(dueDate, today);
    }
    return 0;
}

注意使用ChronoUnit.DAYS.between，不要用Date.getTime()相减再除以86400000——因为可能受时区影响，且跨越夏令时会有精度问题。

6.2 超期状态如何展示

借阅记录的status字段有三种状态：借出中、已归还、已超期。但"已超期"这个状态比较特殊，它不是用户主动操作的结果，而是时间推移后自动产生的。这意味着你不能仅在借书还书时计算状态，而应该在每次打开借阅列表时动态计算。

推荐方案：在查询借阅记录时，对每一行做实时判断：

java复制if (record.getStatus() == 0 && record.getDueTime().isBefore(LocalDateTime.now())) {
    record.setStatus(2);  // 动态判定为超期
}

这样做不需要定时任务去批量更新数据。如果你上了定时任务，反而可能因为跑批失败产生数据不一致。

6.3 还书业务中的完整性校验

还书操作比借书看起来简单，但有一个容易漏掉的校验：归还的书必须对应该读者的借阅记录。如果请求参数里只有bookId和readerId，你要查询borrow_record表里是否存在一条匹配的、状态为借出中的记录，而不是直接去改库存。

还书时还涉及一个问题：如果一本书已经超期了，还书时需不需要收罚款？超市罚金怎么计算？这时候你可能需要一张penalty_record表来记录罚款。这个功能可以作为进阶扩展，但核心逻辑是：先确定超期天数，再根据规则计算罚款金额，最后插入罚款记录。整个流程也要放在事务里。

7. 分页查询与关键字搜索：最常见的面试提问点

7.1 手写分页：LIMIT和PageBean

图书列表页展示的数据一定会越来越多，不可能一次性查出来全部丢给前端。分页查询是Java项目里最基础也最必考的能力。

SQL层面的分页很简单：

sql复制SELECT * FROM book ORDER BY id DESC LIMIT ?, ?

但代码里的分页逻辑有讲究。你至少需要三个参数：当前页码pageNum、每页条数pageSize、总记录数totalCount。总记录数通过SELECT COUNT(*)获取。然后用这三个值计算总页数：

java复制int totalPages = (int) Math.ceil(totalCount * 1.0 / pageSize);

注意这里要*1.0转成浮点数，否则整数除法会出现最后页码丢失的问题。比如总记录数7条，每页5条，整数除法7/5=1，但实际应该是2页。这个Bug非常隐蔽，我见过不少新手在这翻车。

数据库LIMIT的偏移量计算是：LIMIT (pageNum - 1) * pageSize, pageSize。第一页偏移量应该是0，所以页码需要减一。

7.2 查询条件怎么拼才安全

关键字搜索通常涉及书名、作者、出版社等多个字段。使用MyBatis的动态SQL很简单，但在Servlet+JDBC阶段需要手动拼接。这里容易踩两个坑：占位符顺序错乱、多个条件拼接时缺一个AND或多了WHERE。

我的推荐做法是：先构建基础SQL，再用List收集参数：

java复制public List<Book> searchBooks(String keyword, String categoryId, int pageNum, int pageSize) {
    StringBuilder sql = new StringBuilder("SELECT * FROM book WHERE 1=1 ");
    List<Object> params = new ArrayList<>();

    if (keyword != null && !keyword.trim().isEmpty()) {
        sql.append(" AND (name LIKE ? OR author LIKE ? OR publisher LIKE ?) ");
        String like = "%" + keyword.trim() + "%";
        params.add(like);
        params.add(like);
        params.add(like);
    }

    if (categoryId != null && !categoryId.isEmpty()) {
        sql.append(" AND category_id = ? ");
        params.add(Integer.parseInt(categoryId));
    }

    sql.append(" ORDER BY id DESC LIMIT ?, ?");
    params.add((pageNum - 1) * pageSize);
    params.add(pageSize);

    // 用PreparedStatement遍历params填充占位符
}

WHERE 1=1这个写法虽然看起来有点奇怪，但它是动态拼装查询条件时最好用的技巧，避免了判断"第一个条件要不要加WHERE"的繁琐逻辑。团队开发中不少人反感这种写法，但小项目里它是确定可靠的。

8. 会话管理：登录功能是怎么保护页面的

图书管理系统必然有管理员登录模块。实现登录不只是判断用户名密码对没对上，更关键的是：登录之后，用户身份怎么在多个请求之间保持。

HTTP协议本身是无状态的，每个请求都是独立的。为了解决"记住我是谁"的问题，业界引入了Session和Cookie：

• 服务器为每个会话创建一个唯一的Session对象。
• 服务器把Session的ID（JSESSIONID）通过Cookie发给浏览器。
• 浏览器后续请求自动带上这个Cookie，服务器就能找到对应的Session。

Java代码里典型的登录验证逻辑：

java复制@WebServlet("/login")
public class LoginServlet extends HttpServlet {
    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        String username = req.getParameter("username");
        String password = req.getParameter("password");

        // 建议：密码先做一次散列，不要明文存储和传输
        Admin admin = adminService.login(username, password);
        if (admin != null) {
            req.getSession().setAttribute("admin", admin);
            resp.sendRedirect(req.getContextPath() + "/book/list");
        } else {
            req.setAttribute("error", "用户名或密码错误");
            req.getRequestDispatcher("/login.jsp").forward(req, resp);
        }
    }
}

为了保护受管页面不被未登录用户直接访问，可以写一个AuthFilter过滤器，在请求到达Servlet之前检查Session中是否有admin：

java复制@WebFilter("/*")
public class AuthFilter implements Filter {
    @Override
    public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain)
            throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) resp;

        String uri = request.getRequestURI();
        if (uri.contains("/login.jsp") || uri.contains("/login")) {
            chain.doFilter(req, resp);
            return;
        }

        Object admin = request.getSession().getAttribute("admin");
        if (admin == null) {
            response.sendRedirect(request.getContextPath() + "/login.jsp");
        } else {
            chain.doFilter(req, resp);
        }
    }
}

过滤器是Servlet三大组件之一（另外两个是Servlet和Listener），理解你是如何通过Filter把通用逻辑抽出来的，对框架版学习SpringMVC拦截器非常有帮助。

关于密码存储，这里多说一句：真实项目绝对不能用明文密码，至少要用MD5加盐或SHA-256存储。虽然图书管理系统可能只是练习，但我希望你从一开始就把安全意识刻进习惯里。用DigestUtils.md5Hex(password + salt)这种工具类一行代码就能实现基础散列。实际上更推荐等Spring Security或Shiro来管认证授权，但现在这个阶段脑子里先有"不能存明文"这个概念就好。

9. 项目部署：从本地Tomcat到可访问的完整路径

9.1 WAR包怎么打

使用IDEA的Maven项目，打包非常方便。甚至不需要额外配置，直接在右侧Maven面板点package命令，或者在命令行执行：

bash复制mvn clean package

打包完成后，target目录下会生成一个library-management.war文件。把war包复制到Tomcat的webapps目录下，启动Tomcat，它会自动解压部署。

但注意：如果你的Tomcat配置了Host Manager，那么部署路径由context.xml管理；如果没有，默认war包的文件名就是访问路径。把你的war改名成library.war，部署后访问地址就是：

text复制http://localhost:8080/library/login.jsp

9.2 常见部署问题

• 端口被占用：Tomcat默认8080端口，如果你装了别的应用占用8080，启动会报Port in use。解决办法是把server.xml里的Connector端口改成8081。
• JDK版本不匹配：Tomcat 8.5要求JDK 7以上，Tomcat 9要求JDK 8以上，JDK 11以后有部分模块需要额外配置。版本匹配非常重要，不然会报难懂的UnsupportedClassVersionError。
• 数据库没启动：部署项目可以启动，但页面一访问数据库就报错，常见的原因是MySQL服务没开启。检查服务管理里mysql服务的状态，启动它。
• 页面中文乱码：JSP页面顶部要有pageEncoding="UTF-8"，Servlet里要有req.setCharacterEncoding("UTF-8")，数据库连接URL里要有characterEncoding=utf8。三层都设对了，中文才不会乱码。

9.3 把数据库脚本交付给他人

项目部署时，别人拿到你的项目代码，数据库是空的不可能跑起来。所以项目里至少要有db_library.sql脚本文件，包含建库、建表、插入初始数据的语句。更进一步，可以准备两套脚本：schema.sql只建表，data.sql只插入初始数据。这样别人执行一次就能恢复完整环境。

这个习惯很多人不以为然，但到团队开发或者未来工作任务交接时，数据库脚本就是项目的灵魂。没有脚本，换机器部署就等于重头再来。

10. 项目演进：从Servlet走向Spring Boot

10.1 Servlet版遇到了哪些痛点

当你把Servlet + JSP版本做完，并跑起来了完整的借还流程，恭喜你，你已经掌握了Web开发最底层的逻辑。你会很明显地感受到一些痛点：

1. 配置繁琐：每写一个Servlet还要映射路由，web.xml越写越长。
2. 数据封装机械：从ResultSet里取字段、set到实体类，几十行重复模板代码。
3. 对象管理混乱：Service、DAO这些类在Servlet里new来new去，想单例又要手写。
4. 事务管理分散：每个业务方法里都要写start/commit/rollback，重复度太高。

这些正是Spring框架解决的问题。Spring IoC容器帮你管理对象，Spring MVC帮你处理路由，Spring声明式事务一注解搞定，MyBatis帮你自动封装结果集。所以学习路线非常清晰：先把Servlet版写通，再对照着同样的功能用Spring Boot实现一遍。你会瞬间理解框架为什么这么设计，而不是人云亦云地说"SpringBoot真方便"。

10.2 框架版还需要学什么

从Servlet版升级到Spring Boot版，你需要补的知识点包括：

• Maven复杂依赖管理（starter机制）。
• Spring IoC与Bean生命周期。
• Spring MVC请求流程与DispatcherServlet。
• MyBatis的Mapper接口与XML绑定。
• 自动配置原理和application.yml配置方式。
• 用Thymeleaf或Vue替代JSP做前端渲染。

这些内容每一个单独拿出来都够写长篇教程，但你在Servlet版积累的底子，会让你在过渡时只关注"框架做了什么"而不是"代码怎么写"。这也是为什么我一直强调别急着跳进Spring Boot。

11. 常见问题排查与避坑经验速查表

我在带新人或者自己调试这个项目的过程中，积累了下面几个高频问题和应对方法。这里整理成速查表，希望你遇到问题时能快速定位。

除了表格里的内容，再分享几个必须养成的排错习惯：

• 看日志不要只看最后一行。控制台报错的堆栈信息从上往下看，第一行往往才是核心异常。最后一行只是"Caused by"提示链尾。
• 分模块测试。不要写完一整个Servlet再启动测试，应该先写DAO层测试方法，确认能查出数据；再写Service层测试逻辑；最后接页面。每一层都验证过了，出错时迅速锁定层级。
• 善用Logger，少用System.out。System.out虽然方便，但工作中全部要打印到日志文件里。从练习项目开始就用Logger是个极好的习惯。
• 数据库备份。每次做大规模数据修改前，先备份数据库。练习项目虽然不用太严肃，但这个习惯能让你在真实工作中少挨骂。

12. 项目完成后，你还能往哪里扩展

图书管理系统的核心功能整个做完，它已经是一个完整的可演示项目了。但如果你想让它更有特色，有这些扩展方向可以参考：

• 加入批量导入/导出：使用POI操作Excel，批量导入书籍数据，导出借阅报表。这是企业里面最常用的功能之一。
• 加入Redis缓存：热门书籍查询结果缓存、登录Session共享、借阅排行缓存。给你一个理解缓存适用场景的真实案例。
• 加入消息队列：还书消息通知、新书上架通知、逾期提醒定时任务。这个会自然引向RabbitMQ或Kafka的学习。
• 加入图表统计：用ECharts展示每月借阅量趋势、图书分类占比、读者借阅排行。做完了你就有可视化作品了。
• 加入多角色权限：普通管理员和超级管理员功能不一致，按钮级别的权限控制可以加深你对拦截器和注解的理解。

个人做项目最掉价的面试回答就是"只做了CRUD"。但如果你的CRUD后面能说清楚：怎么防注入、怎么处理并发下库存、怎么规划表结构、怎么设计事务边界、怎么解决分页多条件查询，那这个项目就是有含金量的。哪怕它只是一个图书管理系统。

最后分享一点我实际的体会：很多同学做这个项目时，会陷入"我自己跑通了就是会了"的错觉。其实跑通和会之间还差一个"换个需求能不能改"的距离。我建议你做完后，尝试给自己加一个需求，比如"增加一个出版社管理功能"，或者"实现图书批量上下架"。当你能在不百度的情况下，独立完成从页面到数据库的完整链路，恭喜你，这个项目才算真正写进了你的能力里。