1. 项目概述：一个真实可跑的JavaWeb综合训练场
“黑马旅游网”这个名字在Java初学者圈子里几乎成了某种共识性符号——它不是某个商业平台，而是一套被反复打磨、用于检验学习者是否真正掌握Servlet、JSP、MySQL、MVC分层、数据库连接池、前端交互等核心能力的典型教学案例。我带过几届某高校实训班，也帮不少自学的朋友调试过类似项目，发现一个共性：很多人卡在“能看懂代码，但自己搭不起来”“源码跑通了，换张表就报错”“页面能显示，但登录后跳转总404”。这恰恰说明，这个案例的价值不在“功能多炫”，而在“细节多真”：它把企业级Web开发中90%以上的基础陷阱都埋进去了——比如中文乱码的三重校验点、session失效时间与浏览器关闭的微妙关系、JDBC事务回滚时Connection未正确释放导致的连接池耗尽、以及最常被忽略的web.xml中servlet-mapping路径斜杠引发的404连锁反应。
你拿到的这份“day48 JavaWeb阶段——综合案例：黑马旅游网”，本质是一个压缩包里的完整生态：从pom.xml里明确定义的Spring 5.3.22 + MyBatis 3.4.6 + Druid 1.2.16版本组合，到src/main/resources下log4j2.xml里精确到毫秒的日志输出格式，再到target目录生成的war包结构，每一处都是可验证、可复现、可调试的实体。它不教你“Spring Boot自动配置有多爽”，而是逼你亲手写Filter拦截未登录请求、手动配置Druid监控页面、在web.xml里一行行敲出 和 的对应关系。这种“返祖式”的开发方式，恰恰是理解现代框架底层逻辑的必经之路。如果你正处在学完Servlet基础、想验证自己是否真懂MVC分层，或者准备面试前需要一个能讲清楚每个环节的项目，那么这个案例就是你的练兵场——不是玩具，是手术刀，切开来看清JavaWeb的血管与神经。
2. 整体架构设计与技术选型逻辑拆解
2.1 为什么坚持用传统JavaWeb而非Spring Boot？
很多新手看到“黑马旅游网”还用web.xml和手动配置，第一反应是“过时了”。但这是个关键误判。这套架构的选择，根本不是技术落后，而是教学目标倒推的结果。Spring Boot的自动配置像一层厚棉被，把Tomcat启动、Servlet注册、数据库连接初始化这些过程全裹住了。你run起来很爽，但问一句“DispatcherServlet是怎么被Tomcat加载的？”，很多人答不上来。而本项目强制你面对三个核心问题：
容器生命周期管理：在web.xml中定义 监听ServletContext初始化，手动new一个DbUtil单例并调用init()方法加载Druid数据源。这个过程让你亲眼看到“应用启动时到底发生了什么”。
请求链路可视化：所有请求必须经过LoginFilter（检查session）、CharacterEncodingFilter（统一UTF-8编码）、然后才到具体的Servlet。你可以打断点，看着request从浏览器发出，经过Filter链，再进入doGet/doPost，最后forward到JSP。每一步的request.getAttribute()存了什么、session.setAttribute()写了什么，一目了然。
错误溯源直白化：当出现404时，你立刻去查web.xml里的url-pattern是否多写了斜杠；当出现500时，日志里第一行就是具体哪行Java代码抛的异常，而不是Spring Boot那堆嵌套十几层的代理类堆栈。
提示：这不是反对Spring Boot，而是强调“先建楼再装电梯”。我见过太多人Spring Boot项目部署失败，最后发现是连Tomcat都没配对端口——因为从来没手动配过。
2.2 Maven依赖组合的深意：精准控制版本冲突
打开pom.xml，你会看到这样一组核心依赖：
<dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.2.16</version> </dependency>这里藏着三个关键设计点：
<scope>provided</scope>的深意：javax.servlet-api只在编译和测试时需要，运行时由Tomcat提供。如果漏写这个scope，打包时会把servlet-api打进war包，而Tomcat 9自带的servlet-api 4.0.1和你打进去的版本冲突，直接导致启动报错“NoClassDefFoundError: javax/servlet/Filter”。这是新手打包失败的头号原因。MySQL驱动版本与JDK的绑定：mysql-connector-java 8.0.33要求JDK 8u191+。如果你用JDK 7或早期JDK 8，必须降级到5.1.47。我在某次实训中遇到学员死活连不上数据库，最后发现他电脑上装的是JDK 8u171，降级驱动后立刻解决。版本匹配不是玄学，是字节码兼容性问题。
Druid替代DBCP的必然性：项目选用Druid而非更早的DBCP，是因为Druid的监控页面（/druid/index.html）能实时看到连接池活跃数、等待线程数、SQL执行时间。当用户并发刷首页导致页面卡顿，你不用猜，直接打开监控页看“ActiveCount”是否飙到maxActive值——这就是生产环境排查思路的雏形。
2.3 MVC分层的物理落地：src目录下的战争地图
整个src/main/java目录就是一场MVC的物理布防：
cn.itcast.travel.dao：DAO层不是简单封装JDBC，而是用DbUtil.getConn()获取连接，用DbUtil.release()确保finally块里关闭资源。注意它的release()方法里有双重判空：
if(rs != null) rs.close(); if(stmt != null) stmt.close(); if(conn != null) conn.close();——因为JDBC的close()方法可能抛SQLException，必须单独try-catch，否则conn.close()没执行，连接就永远留在池子里。cn.itcast.travel.service：Service层用TransactionManager实现手动事务。关键代码在
startTransaction()里调用conn.setAutoCommit(false)，在commit()里调用conn.commit()，并在catch块里conn.rollback()。这里有个坑：事务只能控制同一个Connection上的多个操作。如果你在service里new了两个dao，每个dao都自己getConn()，那事务就失效了——必须把conn作为参数传给所有dao方法。cn.itcast.travel.web.servlet：Servlet层是真正的指挥中心。比如RouteServlet的doPost()里，先解析JSON参数，再调用service.search(), 最后用response.getWriter().write(JSON.toJSONString(result))输出。这里没有用任何JSON框架，纯手写，就是为了让你看清HTTP响应体怎么组装。
这种分层不是为了炫技，而是为了解耦。当我需要把MySQL换成Oracle时，只需改DAO层的SQL和驱动，service和servlet完全不动。这就是架构设计的原始力量。
3. 核心模块实现与关键细节解析
3.1 用户登录模块：从密码明文到BCrypt加密的演进
登录功能看似简单，但它是整个项目安全性的试金石。原始版本用的是MD5加盐，但项目后续升级到了BCrypt，这个转变背后有硬核逻辑：
MD5的致命缺陷：MD5是哈希算法，不可逆，但存在彩虹表攻击风险。即使加盐（如salt=用户名+固定字符串），攻击者仍可用GPU集群暴力破解。我在某次渗透测试中，用Hashcat跑一个8位数字字母组合的MD5盐值，3分钟就撞出来了。
BCrypt的不可逾越性：BCrypt内置了work factor（强度因子），默认是10，意味着要进行2^10次哈希运算。每次验证都要消耗CPU时间，天然防暴力破解。项目中UserServiceImpl.login()方法里，
BCrypt.checkpw(password, user.getPassword())这行代码，表面看只是个布尔判断，实则背后是上千次的密钥派生运算。
注意：BCrypt加密后的密码长度固定为60字符，且以
$2a$或$2y$开头。如果你在数据库里看到user表password字段是32位十六进制字符串，那一定是MD5，需要立即迁移。
登录流程的另一个关键点是Session管理。LoginServlet成功后执行：
HttpSession session = request.getSession(); session.setAttribute("user", user); session.setMaxInactiveInterval(30 * 60); // 30分钟无操作过期这里setMaxInactiveInterval()设的是秒，不是分钟。我见过太多人写成session.setMaxInactiveInterval(30)，结果用户30秒不操作就掉线。更隐蔽的坑是：request.getSession()和request.getSession(true)效果一样，但request.getSession(false)在session不存在时不创建新session，返回null——这是做“记住我”功能时必须用的。
3.2 线路搜索模块：Lucene全文检索的轻量级实践
“黑马旅游网”的线路搜索不是简单的SELECT * FROM route WHERE rname LIKE ?，而是集成了Lucene 7.7.2实现的轻量级全文检索。这步设计直指企业痛点：当线路表有10万条数据时，LIKE查询会全表扫描，响应时间从毫秒级飙升到秒级。
Lucene的索引构建在RouteDaoImpl中完成：
// 创建索引写入器 Directory directory = FSDirectory.open(Paths.get("D:/lucene/travel")); IndexWriterConfig config = new IndexWriterConfig(new IKAnalyzer()); IndexWriter writer = new IndexWriter(directory, config); // 为每条线路创建Document Document doc = new Document(); doc.add(new StringField("rid", route.getRid()+"", Field.Store.YES)); doc.add(new TextField("rname", route.getRname(), Field.Store.NO)); // 不存储，只索引 doc.add(new StoredField("price", route.getPrice())); // 只存储，不索引 writer.addDocument(doc);这里三个Field类型的选择是精髓：
- StringField：用于精确匹配（如按ID查），不分词，适合主键。
- TextField：用于全文检索（如按线路名模糊搜），用IKAnalyzer中文分词器切词。
- StoredField：只存储不索引，用于结果展示（如价格），避免重复存储。
搜索时，QueryParser parser = new QueryParser("rname", new IKAnalyzer());这行代码决定了搜索入口。当你在搜索框输入“云南 大理”，IKAnalyzer会分词成["云南", "大理"]，然后Lucene用BooleanQuery组合，要求两个词都出现。如果改成parser.setDefaultOperator(QueryParser.AND_OPERATOR)，就能实现“与”逻辑；不设置则是默认“或”。
实操心得：Lucene索引目录必须是绝对路径，且Tomcat进程要有该目录的读写权限。我曾因把路径写成相对路径
"lucene/travel"，导致每次重启Tomcat索引就丢失，排查了两天才发现是路径解析问题。
3.3 订单支付模块：模拟支付与事务一致性的生死线
订单模块是检验你是否真正理解数据库事务的考场。OrderServlet中创建订单的代码，表面看只是插入order表和order_item表，但背后是强一致性要求：
// 开启事务 TransactionManager.startTransaction(); try { // 1. 插入订单主表 String orderId = orderService.addOrder(order); // 2. 插入订单明细表（可能多条） for(OrderItem item : order.getItems()) { item.setOid(orderId); orderItemService.addItem(item); } // 3. 扣减库存（关键！） productService.updateCount(routeId, count); TransactionManager.commit(); } catch (Exception e) { TransactionManager.rollback(); throw new RuntimeException(e); }这里藏着三个必须死磕的细节：
库存扣减必须在事务内：如果把
productService.updateCount()放到事务外，可能出现“订单创建成功但库存没扣”，导致超卖。反之，如果扣减库存失败（如库存不足），事务回滚，订单和明细全删。主键生成策略：orderId不是数据库自增，而是用
UUID.randomUUID().toString().replace("-", "")生成32位字符串。这是为了防止订单号被恶意猜测（如用1,2,3遍历），也是分布式系统的基础思维。支付状态机：order表有status字段（0-未支付，1-已支付，2-已取消）。支付回调接口PaymentServlet里，必须先查订单当前状态，如果是0才更新为1，否则直接返回“重复支付”。这个判断必须用
UPDATE order SET status=1 WHERE oid=? AND status=0，利用数据库的原子性，避免并发支付时状态覆盖。
4. 实操部署全流程与环境避坑指南
4.1 从零搭建开发环境：JDK、Tomcat、IDE的黄金组合
部署前必须确认三件套的版本锁链：
JDK版本：项目pom.xml指定
<maven.compiler.source>1.8</maven.compiler.source>，所以必须用JDK 8。但注意不是任意JDK 8，推荐使用Adoptium Temurin JDK 8u362，它修复了Oracle JDK 8u202之后的SSL握手bug，避免后续连接MySQL 8.0时出现Could not create connection to database server。Tomcat版本：必须用Tomcat 9.0.x。Tomcat 10+全面转向Jakarta EE命名空间（javax.* → jakarta.*），而项目代码全是
import javax.servlet.http.HttpServletRequest，直接报错。我在某次升级中误装Tomcat 10，整整一天都在改import包名，得不偿失。IDE配置：以IntelliJ IDEA为例，关键三步：
- Project SDK选JDK 8；
- Project language level选8；
- 在Settings > Build > Compiler > Java Compiler里，Target bytecode version选1.8。
常见问题：导入项目后显示“Cannot resolve symbol ‘servlet’”。这是因为IDEA没识别到Tomcat的servlet-api.jar。解决方案：File > Project Structure > Libraries > + > Java > 选择Tomcat安装目录下的lib文件夹，勾选servlet-api.jar。
4.2 数据库初始化：字符集、时区、驱动的三位一体
MySQL初始化是第二大雷区。执行sql/travel.sql前，必须确认以下三点：
数据库字符集：创建数据库时必须指定
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。为什么不是utf8？因为MySQL的utf8实际是utf8mb3，不支持emoji和部分生僻汉字。utf8mb4才是真正的UTF-8。如果建库时用CREATE DATABASE travel;没指定字符集，后续插入中文会变问号。MySQL时区：项目中
new Date()生成的时间戳要和数据库时间一致。在my.cnf中添加：[mysqld] default-time-zone = '+08:00'然后重启MySQL。否则Java里
System.currentTimeMillis()和MySQL的NOW()可能差8小时，导致订单创建时间错乱。驱动加载方式：MySQL 8.0+必须用
com.mysql.cj.jdbc.Driver，且URL要加serverTimezone=GMT%2B8&useUnicode=true&characterEncoding=UTF-8。原始travel.sql里给的URL是jdbc:mysql://localhost:3306/travel?useUnicode=true&characterEncoding=utf8，必须手动补全。
执行sql脚本时，用命令行比Navicat更可靠：
mysql -u root -p --default-character-set=utf8mb4 < sql/travel.sql--default-character-set=utf8mb4参数确保导入过程不乱码。
4.3 Maven构建与War包部署：从target到Tomcat的生死时速
构建过程必须严格遵循顺序：
清理旧包：
mvn clean删除target目录，避免残留class文件干扰。编译测试：
mvn compile检查语法，mvn test运行单元测试（项目里test目录有JUnit测试用例）。打包：
mvn package生成travel.war。注意：war包里不能有WEB-INF/lib/servlet-api.jar（因为scope是provided），如果有，说明pom.xml配置错了。部署：将travel.war复制到Tomcat的webapps目录，启动Tomcat。此时Tomcat会自动解压war包为travel文件夹，并在logs/catalina.out里打印启动日志。
关键日志判断点：看到
INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/path/to/tomcat/webapps/travel.war]表示开始部署；看到INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/path/to/tomcat/webapps/travel.war] has finished in [X] ms表示成功。如果卡在中间，立刻看catalina.out最后一行报错。
部署后访问http://localhost:8080/travel/，如果出现404，90%是web.xml里<welcome-file-list>没配对，或者index.jsp路径写错了。检查<welcome-file>index.jsp</welcome-file>是否在<welcome-file-list>标签内。
5. 常见问题排查与独家调试技巧实录
5.1 中文乱码问题：从请求到响应的全链路追踪
中文乱码是JavaWeb项目的“感冒”，症状多样，根源单一：编码不一致。按请求流向逐层排查：
| 环节 | 检查点 | 调试方法 |
|---|---|---|
| 浏览器请求 | URL地址栏输入中文是否乱码 | 用Chrome开发者工具Network标签，看Request URL是否显示%XX编码 |
| Tomcat接收 | Tomcat默认用ISO-8859-1解码 | 在conf/server.xml的Connector节点加URIEncoding="UTF-8" |
| Servlet处理 | request.getParameter()是否乱码 | 在Servlet开头加request.setCharacterEncoding("UTF-8") |
| JSP输出 | 页面显示中文是否乱码 | JSP顶部加<%@ page contentType="text/html;charset=UTF-8" %> |
| 数据库存储 | MySQL表字段字符集 | SHOW CREATE TABLE tab_name看是否为utf8mb4 |
最经典的组合拳是：Tomcat没配URIEncoding + Servlet没setCharacterEncoding → GET请求中文全变问号；而POST请求只要Servlet里setCharacterEncoding就OK，因为POST数据在body里，不受URL编码影响。
独家技巧：在LoginServlet的doPost()第一行加
System.out.println("username="+request.getParameter("username"));，如果控制台打印出来是乱码，说明request.setCharacterEncoding没生效或位置错了（必须在getParameter()之前调用）。
5.2 404错误：路径映射的七种死法
404不是找不到文件，是找不到映射关系。根据web.xml配置，梳理七种高频死法：
Servlet类名拼写错误：
<servlet-class>cn.itcast.travel.web.servlet.UserServlet</servlet-class>里UserServlet.java文件名是UserSevlet（少个r），编译不报错但运行时报ClassNotFoundException。url-pattern斜杠陷阱：
<url-pattern>/user/login</url-pattern>和<url-pattern>/user/login/</url-pattern>是两个不同路径。浏览器访问/user/login时，后者匹配不到。JSP路径错误：
request.getRequestDispatcher("/pages/user/login.jsp").forward(request, response);中的/pages/是相对于webapp根目录，不是相对于当前Servlet路径。静态资源拦截：如果配置了
<url-pattern>/*</url-pattern>的Filter，它会拦截所有请求，包括css/js/jpg，导致页面样式丢失。应改为<url-pattern>/</url-pattern>。Tomcat端口被占：
Address already in use: bind错误，用netstat -ano | findstr :8080查PID，再用taskkill /pid XXXX /f杀掉。war包名与访问路径不一致：travel.war部署后，访问路径是
/travel/，不是/。如果想用根路径，需重命名为ROOT.war。IDEA热部署失效：修改JSP后不刷新，需在Settings > Build > Compiler里勾选
Build project automatically，并按Ctrl+Shift+Alt+/打开Registry，启用compiler.automake.allow.when.app.running。
5.3 数据库连接池耗尽：Druid监控页面的救命稻草
当网站突然变慢，首页加载超过10秒，第一反应不是优化SQL，而是看Druid监控页：http://localhost:8080/travel/druid/index.html（账号admin/admin）。
重点看三个指标：
- ActiveCount：当前活跃连接数。如果长期接近maxActive（默认8），说明连接没释放。
- WaitThreadCount：等待获取连接的线程数。如果>0，说明请求在排队。
- SQL列表：点击“SQL”标签，看执行时间最长的SQL，往往就是问题源头。
一次真实案例：某学员的线路搜索变慢，Druid显示WaitThreadCount飙升到15。点开SQL列表，发现SELECT * FROM route WHERE rname LIKE ?执行时间2秒。优化方案不是加索引，而是把LIKE查询换成Lucene检索——因为LIKE在大数据量下注定慢，而Lucene是为检索而生。
终极排查法：在Druid监控页点“Wall”标签，开启防火墙模式，它会拦截所有执行时间>1秒的SQL，并记录堆栈。这样你就能精准定位到是哪个Servlet的哪行代码触发了慢SQL。
6. 项目延伸与能力跃迁路径
6.1 从“能跑”到“能改”：三个必动手的改造实验
仅仅让项目跑起来是及格线，真正的成长在于主动破坏再修复。我给学员布置的三个经典改造题：
增加验证码功能：在login.jsp里加
<img src="/travel/checkCodeServlet" onclick="this.src='/travel/checkCodeServlet?'+Math.random()">，后端CheckCodeServlet用BufferedImage生成图片，并把验证码文本存入session。关键点：验证码校验必须在LoginServlet里取session.getAttribute("checkcode")对比，且校验后立即session.removeAttribute("checkcode")，防止重放。实现分页查询：修改RouteServlet，接收pageCode和pageSize参数，调用service.pageQuery(pageCode, pageSize)。DAO层用
LIMIT #{startIndex}, #{pageSize}，startIndex = (pageCode-1)*pageSize。难点在于计算总页数：SELECT COUNT(*) FROM route，这个count查询必须和分页查询在同一个事务里，否则数据变更会导致页数不准。接入Redis缓存：把热门线路数据（如点击量前10）缓存到Redis。在RouteServlet里，先查Redis，命中则直接返回；未命中则查DB，再存入Redis，设置过期时间30分钟。这里要注意缓存穿透：如果查一个不存在的rid，Redis没数据，每次都打DB。解决方案是缓存空对象，
redis.setex("route:9999", 300, "null")。
这三个改造覆盖了Web开发的三大核心能力：安全防护、性能优化、缓存设计。做完它们，你对JavaWeb的理解就从“使用者”升级为“构建者”。
6.2 向Spring Boot迁移：保留业务逻辑，重构技术底座
当你要把这个项目升级为Spring Boot时，不要重写，而是“外科手术式”替换：
- 保留所有DAO、Service、Entity类：它们的业务逻辑完全不变，只是把JDBC操作换成MyBatis-Plus的LambdaQueryWrapper。
- 替换web.xml：用
@SpringBootApplication主类 +@RestController注解替代Servlet，用@Configuration类替代Filter配置。 - 数据源迁移：application.yml里写：
这样Druid的监控页spring: datasource: url: jdbc:mysql://localhost:3306/travel?serverTimezone=GMT%2B8 username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver type: com.alibaba.druid.pool.DruidDataSource/actuator/druid依然可用。
最大的认知跃迁在于：原来在web.xml里配置的10个Filter，在Spring Boot里变成10个@Bean方法，用@Order注解控制执行顺序。原来手动管理的Connection，在Spring Boot里由@Transactional注解自动管理。这种对比，会让你真正明白“框架”二字的分量——它不是魔法，而是对重复劳动的抽象封装。
我个人在实际操作中的体会是：不要急于抛弃传统JavaWeb。就像学开车先练手动挡，理解离合、油门、档位的配合逻辑，再开自动挡才能预判车辆行为。这个“黑马旅游网”项目，就是你的手动挡教练车。当你能闭着眼说出request.getRequestDispatcher().forward()和response.sendRedirect()的区别，能徒手写出Druid连接池的最小可用配置，你就已经站在了JavaWeb工程师的起跑线上。后面的Spring Cloud、微服务，不过是把这辆教练车改装成F1赛车的过程——而底盘，永远是这里打下的。
