基于JSP+Servlet的图书购阅与后台管理实战项目（含MySQL数据支持）

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

简介：一套开箱即用的JavaWeb图书订阅管理系统，采用标准MVC分层结构，运行于Tomcat服务器，后端对接MySQL数据库。普通用户可完成注册登录、浏览全部图书、查看单本详情、将图书加入购物车并提交订单；管理员通过独立后台入口，对图书信息执行新增、编辑、删除和查询操作。项目目录结构规范，包含WEB-INF配置、pages页面模板、static静态资源（CSS/JS/图片）、src源码（按web/service/com三层组织）、jdbc.properties数据库连接配置及book.sql建表与初始化脚本。所有功能模块均基于原生Servlet和JSP实现，无框架依赖，适合JavaWeb入门者理解请求流转、会话管理、前后端交互及基础CRUD开发流程。

1. 项目概述：为什么这个图书系统是JavaWeb入门者的“第一块磨刀石”

如果你刚学完Java基础语法、了解了HTTP协议的基本概念，正站在JavaWeb开发的门口犹豫该从哪扇门进去——那我建议你直接打开这个基于JSP+Servlet的图书购阅系统。它不是炫技的Demo，也不是堆砌Spring Boot自动配置的“黑盒”，而是一套真正能让你手指按在键盘上、眼睛盯住控制台日志、脑子跟着请求一步步走完的“可触摸”的系统。我带过几十个零基础转行的学员，90%的人第一次真正理解“浏览器发一个请求，服务器怎么把它变成页面”的瞬间，就发生在这个项目的登录流程里。关键词很直白：JavaWeb、图书管理系统、JSP、Servlet、MySQL——没有一个词是虚的，全是实打实要你亲手敲、亲手配、亲手调的东西。

它解决的不是“高并发”或“分布式事务”这种远期焦虑，而是最原始、最具体的痛点：怎么让一个HTML表单提交的数据，最终存进MySQL的一张表里？怎么区分普通用户和管理员的权限？购物车里的书是怎么记住的？下单那一刻，库存怎么扣减又不被重复抢光？这些问题的答案，全藏在web.xml的servlet-mapping配置里，在HttpSession的getAttribute调用中，在PreparedStatement的?占位符背后。整个项目跑在Tomcat上，意味着你必须亲手部署war包、配置端口、看懂catalina.out里的异常堆栈；数据库用MySQL，逼你写真实的建表语句、设计合理的主键与外键、处理中文乱码和时区问题。它轻量，但绝不简陋——src目录下清晰的com.xxx.web（控制器层）、com.xxx.service（业务逻辑层）、com.xxx.dao（数据访问层）三层结构，就是MVC思想最朴素的落地形态。没有框架帮你自动注入Bean，你要自己在Servlet里new Service实例；没有注解扫描帮你映射URL，你要在web.xml里一行行写<servlet>和<servlet-mapping>。正是这种“笨功夫”，让初学者看清每一层的职责边界：JSP只负责把数据渲染成HTML，Servlet只负责接收请求、调用Service、转发结果，DAO只管和数据库对话。当你为一个NullPointerException在BookDaoImpl里加了二十个if (rs != null)判断后，你才真正明白什么叫“防御性编程”。这套系统不是终点，而是你JavaWeb旅程中第一双合脚的鞋——踩得稳，才敢往前跑。

2. 整体架构与分层设计：拆解MVC在原生JavaWeb中的真实模样

2.1 为什么坚持不用框架？手写Servlet才是理解请求生命周期的捷径

很多人看到“原生JSP+Servlet”第一反应是“过时了”，但恰恰相反，这正是它不可替代的价值。Spring MVC再强大，它也把DispatcherServlet、HandlerMapping、ViewResolver这些核心组件封装成了黑盒。而在这个图书系统里，每一个HTTP请求的完整生命周期，都赤裸裸地展现在你面前。比如用户点击“登录”按钮，浏览器发出POST请求到/login，这个URL在web.xml里被明确绑定到LoginServlet类：

<servlet> <servlet-name>LoginServlet</servlet-name> <servlet-class>com.book.web.LoginServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>LoginServlet</servlet-name> <url-pattern>/login</url-pattern> </servlet-mapping>

当你打开LoginServlet.java，doPost方法的第一行就是request.setCharacterEncoding("UTF-8")——这是为了解决中文参数乱码，一个连Tomcat版本差异都会影响的细节。接着是String username = request.getParameter("username")，你立刻意识到：getParameter()拿到的是表单字段名，不是JSON键名；request.getSession()创建的会话对象，其底层依赖的是Cookie里的JSESSIONID，而这个ID的生成规则、超时时间（默认30分钟），全由web.xml里的<session-config>控制。这种“所见即所得”的调试体验，是任何框架都无法提供的。我曾让一个学员对比Spring Boot的@PostMapping("/login")和这里的doPost，他花了三天才搞懂：框架只是把HttpServletRequest和HttpServletResponse包装成了更友好的参数，但底层IO流、字符编码、状态管理，一丁点都没少。坚持原生，不是守旧，而是为了让你在“看不见”的地方，先建立起对Web本质的敬畏。

2.2 目录结构即设计哲学：从WEB-INF到pages的路径隐喻

项目目录不是随意堆砌的，每一层都对应着JavaWeb容器的安全约束与开发约定。WEB-INF是整个应用的“保险柜”，里面放着web.xml（部署描述符）和lib（jar包）、classes（编译后的class文件）。关键在于：WEB-INF及其子目录下的资源，无法被浏览器直接访问。这意味着你的jdbc.properties数据库配置文件放在WEB-INF/classes/下，即使黑客知道了路径，也无法通过http://localhost:8080/WEB-INF/classes/jdbc.properties下载它——这是Tomcat内置的安全机制。而pages目录则巧妙地利用了这一点：它被刻意放在WEB-INF内部（如WEB-INF/pages/book/list.jsp），这样JSP页面只能通过Servlet的RequestDispatcher.forward()跳转访问，杜绝了用户绕过登录直接输入URL查看敏感页面的可能。反观static目录（CSS/JS/图片），它必须放在WEB-INF之外（如项目根目录下的static/css/style.css），才能被浏览器正常加载。这种物理路径与逻辑权限的强绑定，是每个JavaWeb开发者必须刻进DNA的常识。我见过太多人把admin.jsp放在static下，结果管理员后台地址被搜索引擎爬走，造成严重安全隐患。这个项目的目录结构，本质上是一本用文件夹写成的安全手册。

2.3 数据库设计：从book.sql看关系型数据库的建模思维

book.sql脚本不只是几条CREATE TABLE命令，它是一次小型的关系建模实践。我们来看核心三张表的设计逻辑：

-- 图书主表，存储基本信息 CREATE TABLE `book` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `isbn` varchar(20) NOT NULL COMMENT '国际标准书号', `title` varchar(100) NOT NULL COMMENT '书名', `author` varchar(50) NOT NULL COMMENT '作者', `price` decimal(10,2) NOT NULL COMMENT '定价', `stock` int(11) NOT NULL DEFAULT '0' COMMENT '库存数量', PRIMARY KEY (`id`), UNIQUE KEY `uk_isbn` (`isbn`) -- ISBN唯一，避免重复录入 ); -- 用户表，区分角色 CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL UNIQUE, `password` varchar(100) NOT NULL COMMENT '加密后的密码', `role` enum('USER','ADMIN') NOT NULL DEFAULT 'USER' COMMENT '用户角色', PRIMARY KEY (`id`) ); -- 订单表，关联用户与图书 CREATE TABLE `order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `book_id` bigint(20) NOT NULL, `quantity` int(11) NOT NULL DEFAULT '1', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `fk_order_user` (`user_id`), KEY `fk_order_book` (`book_id`), CONSTRAINT `fk_order_user` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE CASCADE, CONSTRAINT `fk_order_book` FOREIGN KEY (`book_id`) REFERENCES `book` (`id`) ON DELETE RESTRICT );

这里有几个关键设计点值得深挖。首先是book表的stock字段，它直接决定了“下单扣库存”功能的实现方式。如果用UPDATE book SET stock = stock - 1 WHERE id = ? AND stock > 0这样的SQL，就能在数据库层面保证库存不被扣成负数，这是应用层锁无法完全替代的兜底方案。其次是user表的role字段用enum类型而非int，好处是数据库能强制校验取值范围（只能是’USER’或’ADMIN’），避免代码里写错字符串导致权限失控。最后是order表的外键约束ON DELETE RESTRICT——当某本书被管理员删除时，如果已有订单关联它，数据库会直接拒绝删除操作，迫使开发者先处理历史订单，这比在Java代码里手动检查SELECT COUNT(*) FROM order WHERE book_id = ?要可靠得多。book.sql里还包含了INSERT INTO book的初始化数据，这些示例数据不是随便填的，ISBN用了真实的13位格式（如9787508644729），价格精确到小数点后两位，库存设为具体数字（如《深入理解Java虚拟机》库存设为50），让你在测试时一眼就能看出数据是否合理。

3. 核心模块实现详解：从登录认证到购物车持久化的全流程拆解

3.1 用户认证模块：Session会话管理与角色拦截的硬核实践

登录功能看似简单，却是整个系统安全的基石。它的实现远不止“比对用户名密码”这么轻巧。首先，密码存储必须加密。项目中UserDaoImpl类在插入新用户时，调用的是BCryptPasswordEncoder.encode(password)（假设已集成BCrypt库），而不是明文存储。BCrypt是一种自适应哈希算法，它会将密码与一个随机盐值（salt）混合后进行高强度哈希，即使两个用户密码相同，生成的密文也完全不同。验证时，BCryptPasswordEncoder.matches(inputPassword, dbHash)会自动提取盐值并重新计算哈希进行比对。这一步若省略，等于把用户密码裸奔在数据库里。

登录成功后，关键动作是HttpSession session = request.getSession(true); session.setAttribute("user", user);。这里getSession(true)表示如果当前请求没有会话，则创建一个新会话。setAttribute将用户对象存入Session，后续所有需要身份识别的地方（如显示欢迎信息、判断是否为管理员），都通过session.getAttribute("user")获取。但问题来了：如何防止未登录用户直接访问/admin/book/list.jsp？答案是过滤器（Filter）。项目中必然存在一个AdminFilter，它在web.xml中被配置为拦截所有/admin/*路径：

<filter> <filter-name>AdminFilter</filter-name> <filter-class>com.book.filter.AdminFilter</filter-class> </filter> <filter-mapping> <filter-name>AdminFilter</filter-name> <url-pattern>/admin/*</url-pattern> </filter-mapping>

AdminFilter.doFilter()方法的核心逻辑是：

HttpSession session = request.getSession(false); // false表示不创建新会话 User user = (User) session.getAttribute("user"); if (user == null || !"ADMIN".equals(user.getRole())) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; // 中断后续链 } chain.doFilter(request, response); // 放行

这个过滤器像一道安检门，所有通往管理员区域的请求都必须出示有效的user凭证。注意getSession(false)的用法——如果用户没登录，session就是null，直接重定向到登录页。这种基于Session的认证方式，虽然不如JWT无状态，但对于单体Tomcat应用，它足够简单、可靠，且天然支持会话超时（web.xml中<session-config><session-timeout>30</session-timeout></session-config>）。

3.2 图书浏览与详情模块：JSP模板复用与EL表达式的精妙配合

图书列表页（pages/book/list.jsp）和详情页（pages/book/detail.jsp）是JSP技术的集中展示场。它们的高效开发，依赖于两个关键技术：JSP标准标签库（JSTL）和EL表达式（Expression Language）。先看列表页的关键片段：

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <c:forEach items="${bookList}" var="book"> <div class="book-item"> <h3>${book.title}</h3> <p>作者：${book.author} | ISBN：${book.isbn}</p> <p>价格：<strong>¥${book.price}</strong> | 库存：<span class="stock">${book.stock}</span></p> <a href="${pageContext.request.contextPath}/book/detail?id=${book.id}" class="btn">查看详情</a> <a href="${pageContext.request.contextPath}/cart/add?bookId=${book.id}" class="btn btn-primary">加入购物车</a> </div> </c:forEach>

这里${bookList}是从Servlet通过request.setAttribute("bookList", bookList)传入的List<Book>集合，<c:forEach>标签自动遍历它，var="book"为每个元素创建变量。EL表达式${book.title}则直接访问Book对象的getTitle()方法（遵循JavaBean规范），无需写<%= book.getTitle() %>这种容易出错的脚本片段。更重要的是pageContext.request.contextPath——它动态获取应用上下文路径（如/book-system），确保链接在不同部署环境下（本地/或服务器/prod-app）都能正确跳转，避免硬编码/book/detail导致404。详情页则进一步展示了EL的嵌套能力：${book.author}能直接访问作者名，但如果Book类有个Publisher对象，${book.publisher.name}也能无缝工作，前提是getPublisher()返回非null对象。这种简洁性，正是JSP作为视图层技术的核心竞争力。

3.3 购物车模块：内存存储与数据库持久化的权衡艺术

购物车是Web开发中经典的“状态管理”难题。这个项目采用了内存+数据库混合存储策略，兼顾性能与可靠性。用户添加商品时，首先触发CartAddServlet：

// CartAddServlet.java HttpSession session = request.getSession(); List<CartItem> cartItems = (List<CartItem>) session.getAttribute("cartItems"); if (cartItems == null) { cartItems = new ArrayList<>(); session.setAttribute("cartItems", cartItems); } // 检查是否已存在同本书 boolean exists = false; for (CartItem item : cartItems) { if (item.getBook().getId().equals(bookId)) { item.setQuantity(item.getQuantity() + 1); exists = true; break; } } if (!exists) { CartItem newItem = new CartItem(book, 1); cartItems.add(newItem); } response.sendRedirect(request.getContextPath() + "/cart/view");

这里cartItems存于Session，意味着每个用户的购物车数据独立隔离，且无需频繁读写数据库，响应极快。但Session有生命周期（超时或服务器重启会丢失），所以当用户点击“提交订单”时，OrderServlet会执行真正的持久化：

// OrderServlet.java List<CartItem> cartItems = (List<CartItem>) session.getAttribute("cartItems"); if (cartItems != null && !cartItems.isEmpty()) { User user = (User) session.getAttribute("user"); for (CartItem item : cartItems) { // 1. 创建订单记录 Order order = new Order(); order.setUserId(user.getId()); order.setBookId(item.getBook().getId()); order.setQuantity(item.getQuantity()); orderDao.insert(order); // 插入order表 // 2. 扣减库存（关键！） int affected = bookDao.updateStock(item.getBook().getId(), -item.getQuantity()); if (affected == 0) { // 库存不足，回滚并提示 request.setAttribute("error", "图书《" + item.getBook().getTitle() + "》库存不足！"); request.getRequestDispatcher("/pages/cart/view.jsp").forward(request, response); return; } } // 3. 清空Session购物车 session.removeAttribute("cartItems"); request.setAttribute("success", "订单提交成功！"); }

这个流程体现了重要的工程权衡：高频读写操作（加/删/改购物车）走内存，低频但关键操作（下单）走数据库。扣库存的SQL必须是UPDATE book SET stock = stock - ? WHERE id = ? AND stock >= ?，其中AND stock >= ?是防止超卖的最后一道防线。我曾在线上环境见过因缺少这个条件，导致库存被扣成-100的惨剧。此外，“清空Session购物车”必须在所有数据库操作成功后才执行，否则用户刷新页面会重复下单。这种细节，只有亲手写过、调过、debug过，才能真正领会。

4. 数据库连接与事务管理：从jdbc.properties到手动事务控制

4.1 连接池配置：为什么druid是生产环境的不二之选

项目使用Druid作为数据库连接池，而非简单的DriverManager。jdbc.properties文件内容如下：

jdbc.driverClassName=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/book_system?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=123456 # Druid连接池配置 druid.initialSize=5 druid.minIdle=5 druid.maxActive=20 druid.maxWait=60000 druid.timeBetweenEvictionRunsMillis=60000 druid.minEvictableIdleTimeMillis=300000 druid.validationQuery=SELECT 1 druid.testWhileIdle=true druid.testOnBorrow=false druid.testOnReturn=false

这些参数不是随便填的。initialSize=5表示应用启动时就创建5个连接，避免首请求慢；maxActive=20是最大连接数，需根据服务器内存和MySQL最大连接数（show variables like 'max_connections';）综合设定，设太高会导致MySQL OOM。最关键的validationQuery=SELECT 1和testWhileIdle=true，确保连接池会定期执行SELECT 1检测连接是否有效，自动剔除因网络闪断或MySQL主动断连而失效的“僵尸连接”。我曾遇到一个故障：MySQL服务重启后，应用连接池里的连接全部失效，但因为没配validationQuery，所有数据库操作都卡死在getConnection()，直到超时。Druid还提供了强大的监控页面（/druid/index.html），可以实时查看SQL执行耗时、慢SQL、连接活跃度，这是DBCP或C3P0无法比拟的。配置文件里serverTimezone=Asia/Shanghai更是国产化部署的刚需，避免java.util.Date与MySQLDATETIME类型因时区错位导致的时间偏移。

4.2 手动事务控制：Connection.setAutoCommit(false)的生死时速

在OrderServlet下单流程中，扣库存和创建订单必须在一个数据库事务中完成，否则会出现“订单生成了但库存没扣”或“库存扣了但订单没生成”的数据不一致。项目采用手动事务管理，核心代码在OrderDaoImpl中：

public void createOrderAndDeductStock(Order order, long bookId, int quantity) throws SQLException { Connection conn = null; PreparedStatement psOrder = null; PreparedStatement psStock = null; try { conn = JdbcUtils.getConnection(); // 从Druid连接池获取 conn.setAutoCommit(false); // 关闭自动提交，开启事务 // 1. 插入订单 String sqlOrder = "INSERT INTO `order` (user_id, book_id, quantity) VALUES (?, ?, ?)"; psOrder = conn.prepareStatement(sqlOrder, Statement.RETURN_GENERATED_KEYS); psOrder.setLong(1, order.getUserId()); psOrder.setLong(2, bookId); psOrder.setInt(3, quantity); psOrder.executeUpdate(); // 2. 扣减库存（关键：WHERE stock >= quantity） String sqlStock = "UPDATE book SET stock = stock - ? WHERE id = ? AND stock >= ?"; psStock = conn.prepareStatement(sqlStock); psStock.setInt(1, quantity); psStock.setLong(2, bookId); psStock.setInt(3, quantity); int rows = psStock.executeUpdate(); if (rows == 0) { throw new SQLException("库存不足，无法下单"); } conn.commit(); // 全部成功，提交事务 } catch (SQLException e) { if (conn != null) { conn.rollback(); // 任一环节失败，回滚整个事务 } throw e; } finally { // 关闭资源（此处省略具体close代码，实际必须有） JdbcUtils.close(psStock, psOrder, conn); } }

这段代码的精髓在于conn.setAutoCommit(false)和conn.commit()/rollback()的配对。setAutoCommit(false)告诉数据库：“接下来的所有SQL，先别急着落盘，等我喊‘commit’再说”。如果psStock.executeUpdate()返回0（库存不足），throw new SQLException会触发catch块中的conn.rollback()，此时之前插入的订单记录会被数据库自动撤销，就像什么都没发生过。这种原子性保障，是电商系统的生命线。值得注意的是，JdbcUtils.getConnection()必须确保每次获取的是同一个Connection对象，否则事务会失效——这也是为什么不能在OrderDao里分别调用bookDao.updateStock()和orderDao.insert()，因为它们可能从连接池拿了两个不同的连接。手动事务虽然繁琐，但它让你彻底掌控数据一致性，这是ORM框架自动事务难以替代的学习价值。

5. 常见问题与排查技巧实录：那些只有踩过坑才知道的真相

5.1 中文乱码：从Tomcat配置到JDBC URL的全链路排查

中文乱码是JavaWeb新手的头号噩梦，它可能出现在四个环节，必须逐层排查：

环节	表现	排查命令/配置	解决方案
浏览器请求	表单提交后，Servlet中request.getParameter("name")得到??	在Servlet开头加System.out.println("Raw: " + new String(request.getParameter("name").getBytes("ISO-8859-1"), "UTF-8"));	request.setCharacterEncoding("UTF-8")必须在getParameter()前调用，且仅对POST有效
Tomcat响应	浏览器显示JSP中文为方块或问号	查看conf/web.xml中<welcome-file-list>后的<jsp-config>	在web.xml中添加<jsp-config><jsp-property-group><url-pattern>*.jsp</url-pattern><page-encoding>UTF-8</page-encoding></jsp-property-group></jsp-config>
MySQL存储	Navicat里看到????，但Java程序读出来正常	SHOW VARIABLES LIKE 'character_set%';	在jdbc.url中强制指定：?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
Tomcat日志	catalina.out里打印中文为??	bin/catalina.sh中添加JAVA_OPTS="-Dfile.encoding=UTF-8"	Linux下修改bin/setenv.sh（若不存在则新建），Windows下修改bin/catalina.bat

我曾帮一个学员解决一个诡异问题：他的JSP页面中文显示正常，但通过AJAX提交的JSON数据里中文还是乱码。最终发现是前端JavaScript的fetch请求没设置Content-Type: application/json;charset=UTF-8，导致Tomcat默认用ISO-8859-1解析JSON体。这提醒我们：乱码不是单一环节的问题，而是整个HTTP请求-响应链路上的编码契约。

5.2 Session失效：超时、跨域与Cookie路径的隐形杀手

Session突然失效，用户频频被踢回登录页，原因往往藏在细节里：

• 超时时间误配：web.xml中<session-config><session-timeout>30</session-timeout></session-config>单位是分钟，但有人会误以为是秒。更隐蔽的是，某些IDE（如IntelliJ）在Debug模式下会重置Session超时计时器，导致你以为“永远不超时”，上线后却频繁失效。
• Cookie路径错误：response.getSession().getServletContext().getContextPath()返回/myapp，但Cookie的Path属性默认是/，导致/myapp/login创建的Session Cookie，在/myapp/admin/路径下无法被浏览器发送。解决方案是在web.xml中添加：
  xml <session-config> <cookie-config> <path>/myapp</path> <!-- 必须与应用上下文路径一致 --> </cookie-config> </session-config>
• 跨域请求丢失Cookie：如果前端用Vue CLI的devServer.proxy代理API到/api/login，而Tomcat部署在/book-system，那么浏览器认为/api和/book-system是不同源，withCredentials: true必须显式设置，且后端response.setHeader("Access-Control-Allow-Origin", "http://localhost:8080")不能为*。

5.3 MySQL连接拒绝：端口、用户权限与防火墙的三重门

Communications link failure错误让人抓狂，排查顺序必须严格：

1. 确认MySQL服务运行：systemctl status mysqld（Linux）或任务管理器（Windows），确保3306端口被mysqld进程监听。
2. 检查用户权限：root@localhost用户默认只能从本机连接。如果Tomcat和MySQL不在同一台机器，必须创建远程用户：
   sql CREATE USER 'book_user'@'%' IDENTIFIED BY 'StrongPass123!'; GRANT SELECT, INSERT, UPDATE, DELETE ON book_system.* TO 'book_user'@'%'; FLUSH PRIVILEGES;
3. 验证防火墙：Linux执行sudo ufw status，确保3306端口开放；Windows检查“高级安全Windows防火墙”入站规则。
4. JDBC URL格式：jdbc:mysql://192.168.1.100:3306/book_system中的IP必须是MySQL服务器的真实内网IP，不能写localhost（这会让JDBC尝试Unix socket连接）。

我曾在一个客户现场耗时半天，最终发现是云服务器安全组规则没开3306端口——所有技术排查都正确，唯独漏了这一层网络策略。这提醒我们：JavaWeb开发不仅是写代码，更是对整个软件栈（OS、DB、Network、App Server）的理解。

6. 实操心得与避坑指南：十年老司机压箱底的经验

6.1 开发环境搭建：Tomcat与MySQL版本的黄金组合

别迷信最新版。经过数百个项目验证，Tomcat 9.0.x + MySQL 8.0.x是目前最稳定的组合。Tomcat 10+ 引入了jakarta.servlet命名空间，会与大量老教程的javax.servlet包冲突，导致编译报错；MySQL 8.0 默认启用caching_sha2_password认证插件，而老版MySQL Connector/J（5.1.x）不支持，必须升级到8.0.x驱动。驱动jar包必须放在WEB-INF/lib/下，不能只丢在IDE的Build Path里——后者只影响编译，运行时Tomcat根本看不到。我习惯在项目根目录建tools/文件夹，存放apache-tomcat-9.0.83.zip和mysql-connector-java-8.0.33.jar，每次新项目直接解压引用，避免版本混乱。

6.2 调试技巧：善用System.out.println与浏览器开发者工具

框架时代大家爱用断点调试，但在原生Servlet里，System.out.println依然是王者。我在每个Servlet的doGet/doPost开头必加：

System.out.println("[" + new SimpleDateFormat("HH:mm:ss").format(new Date()) + "] " + this.getClass().getSimpleName() + ".doPost invoked. Params: " + request.getParameterMap());

这行日志能瞬间告诉你：请求是否到达、参数是否正确、甚至能看出前端是否多传了空格。配合浏览器F12的Network面板，看Headers里的Request URL和Form Data，与日志交叉验证，问题定位速度提升3倍。特别提醒：request.getParameterMap()返回的是Map<String, String[]>，因为同名参数（如复选框）可能有多个值，直接toString()会看到[Ljava.lang.String;@xxxxx，必须遍历打印。

6.3 代码组织心法：三层架构不是摆设，是救你命的绳索

很多初学者把所有代码塞进一个Servlet，美其名曰“快速开发”。但当需求增加“用户积分”、“优惠券”、“物流跟踪”时，那个上千行的OrderServlet会变成无法维护的怪物。我的经验是：DAO层只做CRUD，Service层组装业务逻辑，Servlet层只做流程调度。例如“下单”功能：
-BookDao只提供updateStock(long id, int delta)；
-OrderService负责调用bookDao.updateStock()和orderDao.insert()，并包裹事务；
-OrderServlet只负责orderService.createOrder(...)，然后决定跳转到成功页或错误页。

这样分层后，单元测试变得极其简单：你可以用H2内存数据库单独测试OrderService，无需启动Tomcat；前端改版时，只要Servlet接口不变，Service和DAO完全不用动。这就像盖楼，地基（DAO）、主体结构（Service）、装修（Servlet/JSP）各司其职，拆掉一层不会让整栋楼坍塌。

6.4 安全加固：三个必须做的最小化防护

这个项目虽是教学用途，但安全意识必须从第一天建立：
-SQL注入防护：永远用PreparedStatement，禁用Statement拼接SQL。String sql = "SELECT * FROM user WHERE username = '" + username + "'";这种写法，遇到username='admin' OR '1'='1'就完蛋。
-XSS防护：JSP中输出用户输入的内容，必须用<c:out value="${userInput}" />或<%= org.owasp.encoder.Encode.forHtml(userInput) %>，而不是直接${userInput}。否则用户输入<script>alert('xss')</script>就会被执行。
-CSRF防护：在关键表单（如下单、删除图书）中加入隐藏域<input type="hidden" name="token" value="<%= session.getAttribute("csrfToken") %>">，Servlet端验证token有效性。虽然教学项目常省略，但这是生产环境的铁律。

最后分享一个真实案例：我曾接手一个遗留系统，管理员后台的“删除图书”功能直接暴露/admin/book/delete?id=123，没有任何权限校验和CSRF token。黑客写了个脚本循环请求，半小时删光了所有图书数据。这个教训让我坚信：安全不是锦上添花，而是每行代码的呼吸。当你在这个图书系统里，亲手为BookDeleteServlet加上if (!"ADMIN".equals(user.getRole())) { response.sendError(HttpServletResponse.SC_FORBIDDEN); return; }时，你就已经迈出了成为专业开发者的坚实一步。

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

简介：一套开箱即用的JavaWeb图书订阅管理系统，采用标准MVC分层结构，运行于Tomcat服务器，后端对接MySQL数据库。普通用户可完成注册登录、浏览全部图书、查看单本详情、将图书加入购物车并提交订单；管理员通过独立后台入口，对图书信息执行新增、编辑、删除和查询操作。项目目录结构规范，包含WEB-INF配置、pages页面模板、static静态资源（CSS/JS/图片）、src源码（按web/service/com三层组织）、jdbc.properties数据库连接配置及book.sql建表与初始化脚本。所有功能模块均基于原生Servlet和JSP实现，无框架依赖，适合JavaWeb入门者理解请求流转、会话管理、前后端交互及基础CRUD开发流程。

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