1. 为什么这套JavaWeb笔记值得反复翻看1.1 从“能跑就行”到“知道为什么能跑”的分水岭很多人学JavaWeb的经历都差不多跟着视频敲完代码Tomcat一启动浏览器里蹦出个页面就觉得自己会了。可一旦换个环境、改个需求或者面试官多问一句“Servlet生命周期里初始化阶段到底干了什么”立马卡壳。这套笔记最值钱的地方不是把代码抄给你而是把“为什么这么写”讲透了。我见过太多人卡在JavaWeb门口不是智商问题是学习路径出了问题。有人上来就啃Spring全家桶结果连HTTP请求怎么被容器接住、怎么被Servlet处理、响应怎么回到浏览器都说不清楚。这就像学开车直接上高速连油门刹车都没摸熟。这套笔记的价值在于它把JavaWeb这条链路从底层到应用层完整串了一遍Tomcat怎么接收请求、Servlet怎么被调用、JSP怎么被翻译成Servlet、Session和Cookie怎么配合、过滤器怎么拦截、监听器怎么感知容器事件。每一个环节都有可运行的代码和对应的解释。适合谁来参考如果你是刚学完JavaSE、准备往Web方向走的学生这套笔记能帮你建立完整的知识框架如果你已经工作但基础不牢想回头补课它也能当速查手册用甚至你已经在用Spring Boot了回头看看Servlet规范很多“魔法”就不再是魔法了。我个人的习惯是每隔一段时间就翻一遍Servlet和HTTP相关的章节每次都有新收获因为随着工作经验增长你对同一段代码的理解深度是不一样的。1.2 这套笔记的知识地图长什么样整套内容大致可以分成几个层次。最底层是HTTP协议和Tomcat容器这是所有JavaWeb应用的运行基础。往上一层是Servlet规范包括Servlet接口、生命周期、请求响应对象、会话管理。再往上是JSP和EL表达式、JSTL标签库这一层现在虽然用得少了但理解它有助于明白模板引擎的演进逻辑。然后是过滤器、监听器这些横切关注点的处理机制。最后是JDBC和数据库操作把数据持久化这一环补上。整个体系是层层递进的每一层都依赖下一层的能力。我建议的学习顺序是先搞懂HTTP请求响应模型再学Servlet然后学会话管理接着学JSP和EL最后学过滤器和监听器。JDBC可以穿插在Servlet之后学因为很多例子需要存数据。这个顺序不是随便定的它符合“先理解请求怎么来、怎么处理、怎么回去”的认知逻辑。如果你反过来先学JSP很容易变成只会写页面但不懂背后原理的“页面仔”。2. 核心细节拆解那些视频里一闪而过但至关重要的点2.1 Servlet生命周期别只会背“初始化、服务、销毁”Servlet的生命周期三个阶段的说法随便搜都能搜到。但真正理解它要结合容器行为来看。第一次请求到达时容器会加载Servlet类、实例化、调用init方法。这里有个关键点init方法只调用一次而且是在多线程环境下被调用的。这意味着如果你在init里做了非线程安全的操作比如给一个非final的成员变量赋值后续所有请求都会共享这个变量可能出现数据错乱。service方法是每次请求都会调用的它根据请求方法类型分发到doGet或doPost。这里有个常见的坑很多人直接在service里写业务逻辑然后发现doGet和doPost里重复代码太多。正确的做法是把业务逻辑抽到单独的方法里doGet和doPost都调用它。另外HttpServlet的service方法默认实现会根据HTTP方法来分发如果你重写了service就不会再走doGet/doPost了这一点在排查“为什么我的doPost不执行”这类问题时特别有用。destroy方法在容器关闭或应用卸载时调用用来释放资源。但要注意如果容器被强制杀掉destroy可能不会执行。所以重要的资源清理不能只依赖destroy还要考虑用try-with-resources或者连接池的关闭钩子来兜底。注意Servlet实例是单例的但容器可能为同一个Servlet创建多个实例比如配置了load-on-startup且容器实现不同不要依赖单例假设来写代码。更稳妥的做法是把所有状态都放在方法局部变量或线程安全的容器里。2.2 请求转发与重定向一字之差行为天壤之别request.getRequestDispatcher().forward()和response.sendRedirect()的区别是面试高频题也是实际开发中容易用错的点。转发是服务器内部行为浏览器地址栏不变只有一次请求请求域中的数据可以传递。重定向是服务器告诉浏览器“你去访问另一个地址”浏览器会发起第二次请求地址栏改变请求域数据丢失。我踩过的坑是这样的在一个登录功能里登录成功后想跳转到主页并显示用户名。如果用重定向request里存的用户信息就没了页面显示空白。后来改成转发问题解决。但转发也有局限它只能转发到同一个应用内部的资源不能跨应用。而且转发后浏览器的URL还是登录页的URL用户刷新页面会重复提交登录请求。所以更合理的做法是登录成功后重定向到主页用户信息存到Session里主页从Session取。这样既避免了重复提交又能跨请求共享数据。还有一个细节转发是在服务器端完成的所以转发目标可以是WEB-INF目录下的资源这些资源浏览器无法直接访问只能通过转发到达。这个特性常用来做权限控制把受保护的页面放在WEB-INF下只有经过Servlet转发才能访问。2.3 Session与Cookie会话管理的双刃剑Session和Cookie是会话管理的两种手段它们经常配合使用。Cookie是客户端存储Session是服务端存储。默认情况下容器会创建一个名为JSESSIONID的Cookie里面存的是Session的ID浏览器每次请求都会带上这个Cookie服务端根据ID找到对应的Session对象。这里有几个容易忽略的点。第一Session的创建时机。很多人以为访问页面就会创建Session其实不是只有调用了request.getSession()或者getSession(true)才会创建。如果只是读取Session而不创建应该用getSession(false)这样没有Session时返回null避免无谓地创建Session浪费内存。第二Session的过期时间。默认是30分钟可以在web.xml里配置。但要注意这个时间是“最大不活动间隔”不是“从创建开始算的总时长”。每次请求都会刷新这个计时器。如果你的应用需要更精确的控制可以在代码里手动设置setMaxInactiveInterval。第三Cookie的安全属性。HttpOnly可以防止JavaScript读取Cookie降低XSS攻击风险Secure表示只在HTTPS连接中发送CookieSameSite可以控制跨站请求是否携带Cookie。这些属性在web.xml或代码里都可以设置。我建议至少设置HttpOnly成本很低但收益很大。第四分布式环境下的Session问题。单机Session在集群环境下会失效因为请求可能被分发到不同的服务器。解决方案有Session粘滞、Session复制、Session集中存储等。现在更推荐用Token机制如JWT来替代Session把状态放在客户端服务端无状态扩展性更好。但Token也有自己的问题比如无法主动失效、需要处理续期等选型时要根据业务场景权衡。2.4 JSP的本质它就是一个Servlet很多人把JSP当成一种“高级HTML”这是误解。JSP在第一次被访问时会被容器翻译成一个Java类这个类继承自HttpServlet然后编译成class文件后续请求就由这个Servlet处理。你可以在Tomcat的work目录下找到这些生成的Java文件和class文件打开看看就明白了。理解这一点后很多JSP的“怪现象”就解释得通了。比如为什么JSP里可以写Java代码因为翻译后的Servlet里那些代码就在_jspService方法里。为什么JSP内置对象可以直接用因为翻译时容器帮你声明并赋值了。为什么JSP第一次访问慢因为要经历翻译和编译过程。现在实际开发中JSP已经很少用了前后端分离是主流。但理解JSP的翻译机制对理解模板引擎的原理很有帮助。Thymeleaf、Freemarker这些模板引擎本质上也是把模板文件翻译成Java代码或解释执行只是它们不依赖Servlet容器更灵活。2.5 过滤器与监听器AOP思想的雏形过滤器Filter可以在请求到达Servlet之前和响应返回客户端之前插入处理逻辑典型应用包括编码设置、登录校验、日志记录、敏感词过滤等。它的工作方式和Servlet很像也是单例多线程也要注意线程安全问题。过滤器的链式调用是重点。多个过滤器会按照web.xml中配置的顺序或者注解的Order顺序组成一个链每个过滤器调用chain.doFilter()后请求才会继续往下走。如果在某个过滤器里没有调用doFilter请求就被截断了。这个特性常用来做权限控制未登录的请求直接重定向到登录页不往下传递。监听器Listener用来监听Web应用中的事件比如ServletContext的创建和销毁、Session的创建和销毁、属性的增删改等。常见的应用场景包括应用启动时加载配置、Session创建时记录在线用户、Session销毁时清理资源。监听器是单例的也要注意线程安全。这两个组件体现了面向切面编程AOP的思想把横切关注点从业务逻辑中抽离出来集中处理。Spring的AOP本质上也是这个思路只是实现方式不同。理解了过滤器和监听器再学Spring的拦截器和AOP就会轻松很多。3. 实操过程从零搭一个可运行的JavaWeb项目3.1 环境准备与项目结构规划先明确工具链JDK建议用8或11这两个版本在企业中仍然大量使用Tomcat用9.x兼容性好IDE用IntelliJ IDEA社区版就够配合Maven管理依赖数据库用MySQL 5.7或8.0。这些版本组合经过大量项目验证踩坑概率低。项目结构建议采用标准的Maven Web项目布局src/main/java/ Java源码 src/main/resources/ 配置文件 src/main/webapp/ Web资源 WEB-INF/ web.xml 部署描述符 lib/ 第三方jarMaven项目一般不需要 index.jsp 首页 pom.xml Maven配置pom.xml里需要引入javax.servlet-api和javax.servlet.jsp-apiscope设为provided因为Tomcat已经提供了这些库。如果要用JSTL还需要引入jstl和standard依赖。数据库驱动mysql-connector-java的scope设为runtime因为编译时不需要运行时才需要。提示Maven的provided scope表示依赖由运行环境提供打包时不会打进去。如果误设为compile可能导致jar包冲突出现ClassNotFoundException或NoSuchMethodError。3.2 第一个Servlet从配置到运行先写一个最简单的HelloServlet。继承HttpServlet重写doGet方法输出一段文字。然后在web.xml里配置servlet和servlet-mapping或者在类上加WebServlet注解。两种方式都可以注解更简洁但web.xml更灵活可以配置初始化参数、加载顺序等。启动Tomcat后访问对应的URL如果看到输出说明环境没问题。如果报404检查URL路径是否和servlet-mapping一致如果报500看控制台异常堆栈通常是类找不到或方法签名不对。这里有个细节WebServlet注解的value属性是访问路径必须以斜杠开头。如果配置了多个路径用数组形式。loadOnStartup属性控制是否在容器启动时就加载Servlet值越小优先级越高。如果设为负数或不设则第一次请求时才加载。3.3 会话管理实战登录功能的完整实现登录功能是练习会话管理的好例子。流程是这样的用户提交用户名密码Servlet验证通过后把用户信息存到Session然后重定向到主页。主页从Session取用户信息如果取不到就跳转回登录页。关键代码在登录Servlet里User user userService.login(username, password); if (user ! null) { HttpSession session request.getSession(); session.setAttribute(currentUser, user); response.sendRedirect(request.getContextPath() /home); } else { request.setAttribute(error, 用户名或密码错误); request.getRequestDispatcher(/login.jsp).forward(request, response); }主页Servlet里HttpSession session request.getSession(false); if (session null || session.getAttribute(currentUser) null) { response.sendRedirect(request.getContextPath() /login.jsp); return; } User user (User) session.getAttribute(currentUser); request.setAttribute(user, user); request.getRequestDispatcher(/WEB-INF/home.jsp).forward(request, response);注意getSession(false)的用法避免无谓创建Session。还有转发到WEB-INF下的页面这样浏览器无法直接访问必须经过Servlet。3.4 过滤器实现统一编码和登录校验编码问题是最常见的乱码来源。可以在每个Servlet里设置request.setCharacterEncoding(UTF-8)但这样重复代码太多。更好的做法是用过滤器统一处理public class EncodingFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request (HttpServletRequest) req; HttpServletResponse response (HttpServletResponse) resp; request.setCharacterEncoding(UTF-8); response.setContentType(text/html;charsetUTF-8); chain.doFilter(request, response); } }登录校验过滤器可以拦截所有需要登录的路径检查Session里有没有用户信息没有就重定向到登录页。配置时要注意排除登录页和静态资源否则会陷入死循环。过滤器的顺序很重要。编码过滤器应该放在最前面确保后续所有处理都使用正确的编码。登录校验过滤器放在编码之后业务Servlet之前。在web.xml中filter-mapping的顺序决定了过滤器的执行顺序用注解的话可以用Order或者实现Ordered接口来控制。3.5 JDBC操作与连接池配置直接使用DriverManager获取连接的方式每次都要建立和关闭连接性能很差。实际项目中必须用连接池。常用的连接池有HikariCP、Druid、DBCP等。HikariCP性能最好配置简单Spring Boot默认用它。Druid功能丰富自带监控页面国内用得比较多。以HikariCP为例配置如下HikariConfig config new HikariConfig(); config.setJdbcUrl(jdbc:mysql://localhost:3306/test?useSSLfalseserverTimezoneUTC); config.setUsername(root); config.setPassword(password); config.setMaximumPoolSize(10); config.setMinimumIdle(5); config.setConnectionTimeout(30000); config.setIdleTimeout(600000); config.setMaxLifetime(1800000); HikariDataSource dataSource new HikariDataSource(config);参数解释maximumPoolSize是最大连接数根据数据库承载能力和应用并发量来定一般10到20够用minimumIdle是最小空闲连接数保持一定数量的热连接避免频繁创建connectionTimeout是获取连接的超时时间超过就抛异常idleTimeout是空闲连接存活时间maxLifetime是连接最大生命周期要小于数据库的wait_timeout避免连接被数据库端关闭后应用还在用。注意连接池的关闭要在应用停止时执行可以在ServletContextListener的contextDestroyed方法里调用dataSource.close()。否则可能导致连接泄漏数据库连接数耗尽。4. 常见问题与排查技巧实录4.1 乱码问题的系统排查思路乱码是JavaWeb开发中最常见的问题但排查起来有章可循。首先要区分乱码发生的环节是请求参数乱码、响应内容乱码还是数据库存储乱码。请求参数乱码通常是客户端编码和服务端解码不一致。GET请求的参数在URL里Tomcat 8之后默认用UTF-8解码一般没问题Tomcat 7及之前默认用ISO-8859-1需要在server.xml的Connector里加URIEncodingUTF-8。POST请求的参数在请求体里需要调用request.setCharacterEncoding(UTF-8)而且必须在读取任何参数之前调用否则无效。响应内容乱码是服务端编码和浏览器解码不一致。用response.setContentType(text/html;charsetUTF-8)设置响应类型和编码或者用response.setCharacterEncoding(UTF-8)单独设置编码。注意setContentType要在getWriter之前调用否则不生效。数据库乱码涉及多个环节数据库、表、字段的字符集连接URL的字符集参数JDBC驱动的字符集处理。建议统一用utf8mb4连接URL加上useUnicodetruecharacterEncodingUTF-8。如果还是乱码检查数据库和表的字符集设置用SHOW VARIABLES LIKE character%查看。4.2 404和500错误的快速定位404表示资源找不到常见原因有URL路径写错、servlet-mapping配置错误、项目部署路径不对、web.xml配置错误导致应用启动失败。排查时先看Tomcat日志确认应用是否成功启动然后在浏览器开发者工具里看实际请求的URL和配置对比最后检查WEB-INF/web.xml是否有语法错误。500表示服务器内部错误通常是代码抛异常了。看控制台异常堆栈从最底部的Caused by开始看那里通常是根因。常见原因包括空指针、类型转换异常、数据库连接失败、SQL语法错误、类找不到等。如果是ClassNotFoundException检查依赖是否引入、scope是否正确如果是SQLException检查数据库是否启动、连接参数是否正确、SQL语句是否有误。4.3 Session失效与Cookie禁用场景Session失效的常见原因超过最大不活动时间、服务器重启、调用invalidate方法、Cookie被禁用导致JSESSIONID无法传递。如果用户禁用了CookieSession就无法正常工作因为JSESSIONID没法存。解决方案是URL重写用response.encodeURL()把JSESSIONID拼到URL后面。但这种方式现在很少用了因为URL会变得很长且不安全。另一个坑是Session的序列化。如果Session里存的对象没有实现Serializable接口在Session持久化或集群复制时会报错。所以往Session里放的对象最好都实现Serializable。4.4 数据库连接泄漏的排查与预防连接泄漏表现为应用运行一段时间后数据库连接数达到上限新请求获取连接超时。排查方法是查看连接池的监控数据看活跃连接数和空闲连接数的变化趋势。如果活跃连接数持续增长不下降基本可以确定有泄漏。常见泄漏原因获取连接后没有在finally块里关闭、异常导致关闭代码没执行、连接被包装后忘记关闭底层连接。预防措施用try-with-resources自动关闭、用连接池的泄漏检测功能如HikariCP的leakDetectionThreshold、定期检查代码中的资源关闭逻辑。问题现象可能原因排查方法解决方案请求参数乱码编码不一致检查请求头和setCharacterEncoding调用时机统一UTF-8过滤器设置编码响应内容乱码响应编码未设置查看响应头Content-TypesetContentType设置charset404错误路径或配置错误看Tomcat日志和实际请求URL核对servlet-mapping和部署路径500错误代码异常看异常堆栈的Caused by根据根因修复代码或配置Session失效超时或Cookie禁用检查Session配置和浏览器Cookie设置调整超时时间或用URL重写连接泄漏资源未关闭监控连接池活跃连接数try-with-resources或泄漏检测4.5 实操心得与避坑清单第一个心得不要迷信“最新版本”。JDK、Tomcat、MySQL的版本组合要选经过验证的稳定组合最新版本可能有兼容性问题。我见过用JDK 17配Tomcat 8出问题的案例换成JDK 11就正常了。第二个心得日志比调试更重要。System.out.println只能临时用正式项目要用日志框架如Logback、Log4j2配置合理的日志级别和输出格式。出问题时日志是唯一的线索。第三个心得理解原理比记住配置重要。web.xml的配置项很多死记硬背记不住。理解每个配置项的作用和容器如何处理它才能灵活应对各种场景。第四个心得多动手改代码。看视频觉得懂了自己写可能写不出来。把例子代码改一改加点新功能或者故意制造错误看看报什么异常这样学得最扎实。第五个心得学会看官方文档和源码。Servlet规范、Tomcat文档、JDBC规范都是权威资料遇到不确定的问题查文档比搜博客靠谱。源码能让你看到实现细节理解“为什么是这样”。第六个心得建立自己的代码片段库。常用的过滤器、监听器、连接池配置、工具类整理成模板下次直接用省时省力。第七个心得不要跳过异常处理。很多初学者为了省事catch块里只写e.printStackTrace()这是不负责任的。至少要记录日志能处理的处理不能处理的往上抛让调用者知道出了问题。第八个心得定期回顾和重构。学完一个阶段后回头看看之前的代码往往能发现可以改进的地方。重构不是浪费时间是提升代码质量的过程。5. 从JavaWeb到现代框架的平滑过渡5.1 Servlet规范是Spring MVC的基石很多人学完JavaWeb直接跳到Spring Boot觉得Servlet那一套过时了。其实Spring MVC的核心DispatcherServlet就是一个Servlet它拦截所有请求然后根据HandlerMapping找到对应的Controller方法调用并返回ModelAndView最后用ViewResolver解析视图。整个流程和原生Servlet的处理链路是一脉相承的。理解了Servlet的请求响应模型、过滤器和监听器再学Spring MVC的拦截器、AOP、事务管理就会发现很多概念是相通的。比如Spring的CharacterEncodingFilter就是Servlet过滤器的封装OpenSessionInViewFilter也是过滤器。Spring Boot只是把Tomcat内嵌了把配置自动化了底层的Servlet容器和规范没有变。5.2 前后端分离后的角色转变前后端分离后Java后端不再负责渲染页面而是提供RESTful API。Servlet的角色从“返回HTML”变成“返回JSON”。这时候JSP和EL表达式用得少了但Servlet的请求处理、参数绑定、会话管理、过滤器这些能力依然重要。Spring Boot的RestController本质上就是Servlet的doGet/doPost的封装RequestParam对应request.getParameterRequestBody对应读取请求体并反序列化。理解原生Servlet的处理方式能帮你更好地理解Spring Boot的注解和自动配置。5.3 学习路径建议与资源推荐如果你正在学JavaWeb建议按这个路径走先花一周搞懂HTTP和Tomcat基础再花两周学Servlet和会话管理然后一周学JSP和EL接着一周学过滤器和监听器最后两周学JDBC和连接池。整个周期大概六到八周每天投入两到三小时。学完之后可以尝试用原生Servlet写一个小项目比如简易博客、通讯录、任务管理。不要用框架就用ServletJSPJDBC把增删改查、登录注册、分页搜索都实现一遍。这个过程会很痛苦但收获很大。写完后再学Spring Boot你会发现很多配置和概念都能对应上学习曲线会平缓很多。资源方面除了这套笔记Servlet规范文档、Tomcat官方文档、MySQL参考手册都是必备的。遇到问题先查文档再搜技术社区最后才问人。养成独立解决问题的习惯比学会某个具体技术更重要。我个人在实际操作中的体会是JavaWeb基础打得越扎实后面学框架越轻松。那些觉得Spring Boot“魔法”太多的人往往是因为不了解底层原理。一旦你把Servlet那一层看透了Spring Boot的自动配置就不再神秘你甚至能猜到它大概是怎么实现的。这种“看透”的感觉是单纯学框架给不了的。