企业官网建设流程全解析

1. 这不是“背知识点”，而是重建JavaWeb的底层认知地图

很多人打开“JavaWeb知识点复习”这个标题，第一反应是翻笔记、划重点、默写Servlet生命周期——结果复习完还是跑不起来一个最简单的HelloWorld，Tomcat启动后浏览器打不开，控制台一堆红字，连502、404、ClassNotFoundException都分不清哪个该查配置、哪个该查代码、哪个根本就是路径写错了。我带过几十个刚学完理论的实习生，90%卡在同一个地方：他们把JavaWeb当成一堆孤立名词来记，而不是一个有血有肉、环环相扣的请求响应链条。

这恰恰是第一次复习最危险的误区。你不需要记住“HTTP是应用层协议”这种教科书定义，你需要知道：当你在浏览器地址栏敲下http://localhost:8080/hello并按下回车，接下来的1.2秒内，到底发生了什么？Tomcat怎么拿到这个请求？Servlet容器怎么找到你的HelloServlet？doGet()方法里的response.getWriter().println("Hello")，这行字又是如何变成屏幕上那行文字的？中间每一步，都有明确的物理载体（端口、线程、类加载器、IO流）、明确的数据流向（字节→字符串→HTML→渲染树）、明确的失败点（端口被占、web.xml没配对、Maven没拉到依赖、IDE没把class文件编译进target）。

所以这次复习，我们彻底抛弃“知识点罗列”模式。我把整个JavaWeb技术栈拆成四个不可跳过的执行阶段：环境落地 → 请求抵达 → 逻辑执行 → 响应生成。每个阶段对应一个真实可验证的动作，比如“能手动用curl发请求”“能看懂Tomcat日志里哪一行代表Servlet初始化完成”“能改一行代码让响应头多加一个X-Trace-ID”。你不背概念，你只做动作；不做对了，概念自然就长在你脑子里了。热搜词里反复出现的“tomcat安装及配置教程”“eclipse创建基于maven的servlet项目”“tomcat启动后访问404”，全都是这四个阶段里某个环节断掉了。今天我们就把这条链子，一节一节亲手焊牢。

提示：本次复习不依赖任何IDE图形界面。所有操作均以命令行+原始配置文件为基准。因为IDE的“一键部署”会掩盖大量底层细节——比如它自动帮你把src/main/webapp/WEB-INF/web.xml复制到target/mysite/WEB-INF/，而你根本不知道这个target目录在哪、为什么必须叫WEB-INF、为什么里面必须有web.xml。这些，才是第一次复习真正要拿下的硬骨头。

2. 环境落地：从零搭建一个“看得见摸得着”的JavaWeb运行基座

很多人的JavaWeb环境，是跟着某篇博客点点点装出来的：下载Tomcat压缩包、解压、双击startup.bat、看到控制台刷出“Server startup in XXX ms”就以为成功了。结果第二天重启电脑，发现Tomcat打不开了——因为JAVA_HOME没配，或者PATH里多个JDK版本冲突，又或者防火墙把8080端口拦了。这种环境，就像建在沙地上的房子，风一吹就倒。第一次复习，我们必须亲手把地基夯实在水泥地上。

2.1 Tomcat：不止是“解压即用”，关键是理解它的目录契约

Tomcat不是黑盒，它是一套严格遵循Java EE规范的目录结构。你解压后的apache-tomcat-9.0.96目录，每一层都在回答一个问题：

• bin/：放的是启动脚本，不是“程序本体”。startup.bat（Windows）和startup.sh（Linux/macOS）本质只是调用catalina.bat/sh，而后者的核心动作是：

  java -Djava.util.logging.config.file="%CATALINA_BASE%\conf\logging.properties" \ -Dcatalina.base="%CATALINA_BASE%" \ -Dcatalina.home="%CATALINA_HOME%" \ -Dfile.encoding=UTF-8 \ -classpath "%CATALINA_HOME%\lib\bootstrap.jar;%CATALINA_HOME%\lib\tomcat-juli.jar" \ -Djdk.tls.ephemeralDHKeySize=2048 \ -Djava.protocol.handler.pkgs=org.apache.catalina.webresources \ org.apache.catalina.startup.Bootstrap start

  看懂这行命令，你就明白：Tomcat启动的本质，是用java命令运行bootstrap.jar里的Bootstrap类。-Dcatalina.home指向Tomcat安装目录，-Dcatalina.base指向工作目录（默认就是home），-classpath指定了启动所需的jar包。如果你把CATALINA_HOME设错，或者bootstrap.jar被删了，启动必然失败——这不是玄学，是命令行逻辑。

• conf/：放的是契约文件。其中server.xml定义了Tomcat的“骨架”：

  <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

  这行代码意味着：Tomcat会在本机8080端口监听HTTP请求。如果这里改成port="8081"，而你浏览器还访问8080，必然404。web.xml（位于conf/web.xml）是全局默认配置，它定义了所有Web应用共用的Servlet映射规则，比如.jsp文件默认由JspServlet处理。新手常犯的错误是：自己项目的web.xml没写对，却去改conf/web.xml，结果影响所有应用。

• webapps/：放的是待部署的应用包。Tomcat启动时，会扫描此目录下的每个子目录或war包，将其视为一个独立Web应用。ROOT目录对应根路径/，myapp/目录对应/myapp。如果你把一个名为hello.war的文件丢进去，Tomcat会自动解压成hello/目录，并将http://localhost:8080/hello路由给它。但注意：webapps/是Tomcat的“部署区”，不是你的开发区。你在IDE里写的代码，最终必须编译、打包、复制到这里（或通过IDE自动完成），Tomcat才能看见。

注意：不要用manager应用远程部署！第一次复习，请坚持手动复制war包或目录。因为manager应用本身就是一个Web应用，它依赖webapps/manager/存在且配置正确。如果连基础部署都靠它，等于用一个黑盒调试另一个黑盒，问题永远定位不到根因。

2.2 Maven：不是“下载jar的工具”，而是构建流水线的指挥官

热搜词里“maven是干嘛的”“maven安装与配置”高频出现，说明很多人把它当成“高级版wget”。其实Maven的核心价值，在于标准化构建过程。没有Maven时，你可能这样操作：

1. 手动下载servlet-api-4.0.1.jar
2. 把它复制到WEB-INF/lib/目录
3. 在Eclipse里右键项目→Build Path→Add External JARs
4. 写完代码，手动把classes/目录复制到webapps/myapp/WEB-INF/classes/

这个过程有4个致命缺陷：重复劳动、版本混乱、路径错误、无法复现。Maven用一个pom.xml文件，把所有步骤固化下来：

<project xmlns="http://maven.apache.org/POM/4.0.0"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>my-web-app</artifactId> <version>1.0-SNAPSHOT</version> <packaging>war</packaging> <!-- 关键：告诉Maven这是Web应用 --> <properties> <maven.compiler.source>11</maven.compiler.source> <maven.compiler.target>11</maven.compiler.target> </properties> <dependencies> <!-- Servlet API 是Provided Scope，只在编译和测试时需要，运行时由Tomcat提供 --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> </dependencies> </project>

这段配置的每一行都在解决一个实际问题：

• <packaging>war</packaging>：Maven知道最终要生成.war包，会自动把src/main/webapp/下的内容（包括WEB-INF/）和target/classes/合并。
• <scope>provided</scope>：这是新手最容易踩的坑。它告诉Maven：“这个jar包不用打进war包，因为运行时Tomcat的lib/目录里已经有了”。如果你漏写scope，Maven会把servlet-api.jar也打进war，导致类加载冲突——Tomcat用自己的类加载器加载servlet-api，你的应用又用自己的加载器加载一遍，ClassCastException瞬间爆炸。

Maven的生命周期命令，就是构建流水线的开关：

• mvn clean：删除target/目录，清空上一次构建产物。
• mvn compile：编译src/main/java/下的Java文件，输出到target/classes/。
• mvn package：执行compile后，再把src/main/webapp/和target/classes/打包成target/my-web-app-1.0-SNAPSHOT.war。
• mvn tomcat7:run（需插件）：直接在Maven内嵌Tomcat中运行，跳过手动部署。

实操心得：第一次复习，请务必在命令行执行mvn clean package，然后手动把生成的war包复制到webapps/，再启动Tomcat。不要用IDE的“Run on Server”功能。因为IDE的自动部署会隐藏target/目录的生成过程、war包的内部结构、甚至Tomcat的日志输出位置。你必须亲眼看到target/my-web-app-1.0-SNAPSHOT.war这个文件被创建，再亲手把它拖进webapps/，才能建立“代码→字节码→归档→部署→运行”的完整因果链。

2.3 JDK与环境变量：那个总在报错信息里闪现的幕后推手

所有JavaWeb问题，最终都会追溯到JDK。但很多人只记得“要装JDK”，却不知道JDK的三个核心组件如何协同工作：

• javac：Java编译器，把.java源文件编译成.class字节码。
• java：Java虚拟机（JVM），负责加载、验证、执行.class文件。
• jre/目录：JVM运行时环境，包含rt.jar（核心类库）和lib/下的本地库。

环境变量JAVA_HOME和PATH的设置，决定了系统用哪个JDK：

• JAVA_HOME：必须指向JDK的根目录（如C:\Program Files\Java\jdk-11.0.20），不能指向jre/子目录。
• PATH：必须包含%JAVA_HOME%\bin（Windows）或$JAVA_HOME/bin（Linux/macOS），这样才能在任意目录下运行javac和java。

验证是否配置成功，不是看“java -version”有没有输出，而是执行：

# 检查javac和java是否指向同一JDK where javac # Windows which javac # Linux/macOS where java which java # 检查JAVA_HOME是否生效 echo %JAVA_HOME% # Windows echo $JAVA_HOME # Linux/macOS

如果javac和java路径不同，或者JAVA_HOME未设置，Tomcat启动时就会报Error: JAVA_HOME is not defined correctly。更隐蔽的问题是：你装了JDK 17，但Tomcat 9要求JDK 8-11，此时Tomcat虽然能启动，但在加载某些老版本Servlet时会抛UnsupportedClassVersionError——因为JDK 17编译的字节码版本（61）高于Tomcat 9支持的最高版本（55）。

踩坑实录：某次线上部署，测试环境一切正常，生产环境启动Tomcat后控制台疯狂刷java.lang.NoClassDefFoundError: javax/servlet/Servlet。排查两小时，最后发现生产服务器PATH里有个旧版JRE路径排在JAVA_HOME/bin前面，导致Tomcat实际调用的是JRE而非JDK，javax.servlet.*包根本不存在。解决方案：在setenv.bat/sh中强制指定JAVA_HOME，并确保PATH只包含%JAVA_HOME%\bin。

3. 请求抵达：HTTP协议不是纸面概念，而是可抓包、可模拟、可篡改的数据流

当浏览器地址栏输入URL并回车，HTTP协议就开始了它真实的物理旅程。热搜词里“http连接复用”“http和https的区别”“http error 404”之所以高频，是因为它们都发生在“请求抵达”这一阶段。但很多人对HTTP的理解还停留在“请求头+请求体+响应头+响应体”的抽象描述，不知道这些文本是如何在网络中流动、如何被Tomcat解析、又如何被你的Servlet代码读取的。

3.1 用curl亲手构造一次HTTP请求，绕过浏览器的“魔法滤镜”

浏览器是一个高度封装的HTTP客户端，它自动处理Cookie、重定向、缓存、HTTPS证书验证等。这让你看不到最原始的请求数据。第一次复习，我们必须用curl——一个命令行HTTP工具，亲手构造每一个字节：

# 最简GET请求：模拟浏览器访问根路径 curl -v http://localhost:8080/ # -v 参数开启详细模式，你会看到： # * Trying ::1:8080... # * Connected to localhost (::1) port 8080 (#0) # > GET / HTTP/1.1 <-- 这是HTTP请求行 # > Host: localhost:8080 <-- 这是必需的Host头 # > User-Agent: curl/7.81.0 # > Accept: */* # > # < HTTP/1.1 200 OK <-- 这是HTTP响应状态行 # < Content-Type: text/html;charset=ISO-8859-1 # < Content-Length: 11354 # < Date: Mon, 15 Apr 2024 08:22:34 GMT # < # <!DOCTYPE html><html><head><title>Apache Tomcat</title></head>...

关键观察点：

• > GET / HTTP/1.1：请求行。GET是方法，/是请求URI，HTTP/1.1是协议版本。如果你的Servlet映射路径是/hello，这里就必须是GET /hello HTTP/1.1。
• > Host: localhost:8080：Host头。HTTP/1.1强制要求，用于虚拟主机识别。如果Tomcat配置了多个<Host>，Host头决定请求路由给谁。
• < HTTP/1.1 200 OK：状态行。200表示成功。404表示资源未找到（Servlet没注册或URL写错），500表示服务器内部错误（Servlet代码抛异常），502表示网关错误（Tomcat作为反向代理时，后端服务无响应）。

现在，我们故意制造一个404：

curl -v http://localhost:8080/nonexistent # < HTTP/1.1 404 Not Found # < Content-Type: text/html;charset=ISO-8859-1 # < Content-Language: en # < Content-Length: 765 # < # <!doctype html><html><head><title>Apache Tomcat/9.0.96 - Error report</title>...

对比/和/nonexistent的响应，你会发现：404页面也是Tomcat自动生成的HTML，它存在于webapps/ROOT/下的某个错误页配置中。这证明：404不是网络错误，而是Tomcat明确知道“这个路径没有对应的Servlet或静态资源”，并主动返回了一个预设的错误页面。

3.2 Tomcat的请求处理链：从Socket连接到Servlet实例的七步穿越

Tomcat不是一收到字节就调用doGet()。它有一条严格的请求处理链，每一步都可能失败：

1. Acceptor线程监听端口：server.xml中<Connector>配置的port="8080"，由Acceptor线程在操作系统层面调用socket.bind()绑定。如果端口被占用（如另一Tomcat、Skype、MySQL），启动日志会报Address already in use: bind。

2. Poller线程轮询就绪连接：Acceptor接受连接后，把SocketChannel交给Poller线程池。Poller使用epoll（Linux）或kqueue（macOS）高效监听成百上千个连接的读写事件。

3. Executor线程池执行业务逻辑：当Poller检测到某个连接有数据可读，就将SocketProcessor任务提交给Executor线程池（默认maxThreads="200"）。这是Servlet代码实际运行的地方。如果你的doGet()里写了Thread.sleep(10000)，这个线程就被占用了10秒，其他请求只能排队等待。

4. CoyoteAdapter解析HTTP报文：Executor线程拿到原始字节流后，CoyoteAdapter负责解析HTTP协议：提取请求行、请求头、请求体，转换成org.apache.coyote.Request对象。

5. Mapper定位Servlet：Mapper组件根据请求URI（如/hello）和web.xml或注解（@WebServlet("/hello")）的映射关系，找到对应的Wrapper容器（即Servlet包装器）。

6. StandardWrapperValve调用Servlet生命周期：Wrapper容器管理Servlet实例。首次请求时，调用init()；每次请求，调用service()（内部根据HTTP方法分发到doGet()或doPost()）；应用卸载时，调用destroy()。

7. Response对象写入Socket：HttpServletResponse的getWriter()或getOutputStream()，最终把数据写入SocketChannel的发送缓冲区，由操作系统通过TCP协议发回浏览器。

关键洞察：unexpected status 502 bad gateway错误，通常出现在Tomcat作为反向代理（如配合Nginx）时。此时Tomcat本身运行正常，但它转发请求给后端服务（如Spring Boot应用）时，后端服务没响应或返回了非法HTTP报文。502的根因永远在后端服务，不在Tomcat配置。而500 Internal Server Error，则100%是你自己的Servlet代码在第6步抛出了未捕获异常。

3.3 Servlet映射的三种方式：哪一种在什么时候生效？

Servlet不是自动被调用的，它必须通过明确的URL映射规则告诉Tomcat：“当用户访问/hello时，请调用我的HelloServlet”。映射方式有三种，优先级和适用场景完全不同：

新手常见错误：

• 在Servlet类上写了@WebServlet("/hello")，但web.xml的<web-app>版本是2.5（默认值），导致注解完全不生效，访问/hello返回404。
• web.xml里写了<url-pattern>/hello</url-pattern>，但Servlet类名是HelloWorldServlet，而<servlet-class>写成了com.example.HelloServlet，类找不到，启动时报ClassNotFoundException。

实操验证：写一个最简Servlet，用三种方式分别映射，然后用curl -v测试。观察Tomcat启动日志：对于web.xml方式，你会看到Initializing Spring FrameworkServlet 'dispatcher'（如果有Spring）；对于@WebServlet，你会看到Servlet HelloServlet configured successfully；对于动态注册，日志里只有contextInitialized的打印。日志是唯一的真相来源。

4. 逻辑执行：Servlet不是“写个类就行”，而是受容器严格管控的组件

很多人以为写个继承HttpServlet的类，再重写doGet()，就完成了Servlet开发。但实际运行中，doGet()方法里的每一行代码，都运行在Tomcat容器的严密管控之下。热搜词里“servlet”“体验servlet调用大模型api接口”背后，是HttpServletRequest和HttpServletResponse这两个对象如何被容器注入、如何被安全使用、又如何引发常见陷阱。

4.1 HttpServletRequest：不只是“获取参数”，更是请求上下文的完整快照

HttpServletRequest对象，是Tomcat在每次HTTP请求到达时，为你创建的一个不可变的请求上下文快照。它包含了从原始字节流解析出的所有信息：

• 请求行信息：request.getMethod()返回"GET"，request.getRequestURI()返回"/hello"，request.getQueryString()返回"name=zhangsan&age=25"（GET参数）。
• 请求头信息：request.getHeader("User-Agent")获取浏览器标识，request.getHeader("Content-Type")获取POST请求体类型（如application/json）。
• 请求体信息：request.getInputStream()获取原始字节流（适合处理文件上传、JSON），request.getReader()获取字符流（适合处理表单文本）。二者互斥，只能调用一次。如果先调用getInputStream()，再调用getReader()，会抛IllegalStateException。
• 请求参数：request.getParameter("name")获取单个参数值（GET或POST表单），request.getParameterMap()获取所有参数的Map<String, String[]>。注意：getParameter()对application/json无效，因为JSON数据在请求体里，不是表单编码。

一个经典陷阱：中文乱码。原因在于HTTP协议本身不规定字符编码，Tomcat默认用ISO-8859-1解码URL和表单参数。解决方案分两步：

1. GET请求：在server.xml的<Connector>中添加URIEncoding="UTF-8"：

   <Connector port="8080" protocol="HTTP/1.1" URIEncoding="UTF-8" ... />

2. POST请求：在Servlet的doGet()或doPost()开头，调用request.setCharacterEncoding("UTF-8")。必须在调用getParameter()之前执行，否则已解码的乱码无法挽回。

实操技巧：在doGet()开头加一行System.out.println("Request URI: " + request.getRequestURI() + ", QueryString: " + request.getQueryString());，然后用curl "http://localhost:8080/hello?name=张三"测试。你会看到控制台输出name=%E5%BC%A0%E4%B8%89（UTF-8 URL编码），如果没加URIEncoding，getParameter("name")就会返回"å¼ ä¸‰"（ISO-8859-1解码的乱码）。

4.2 HttpServletResponse：不只是“写响应”，而是控制浏览器行为的指令集

HttpServletResponse对象，是Tomcat为你准备的一个响应指令集。调用它的方法，不是在“写数据”，而是在向浏览器下达指令：

• response.setStatus(200)：设置HTTP状态码。200是默认值，404表示资源未找到，302表示临时重定向（需配合response.setHeader("Location", "/newpath")）。
• response.setContentType("text/html;charset=UTF-8")：设置Content-Type响应头，告诉浏览器：“接下来的数据是HTML，用UTF-8解码”。必须在调用getWriter()之前设置，否则getWriter()会按默认ISO-8859-1编码，导致中文乱码。
• response.getWriter()：获取字符输出流。Tomcat内部会根据setContentType设置的字符集，创建对应的PrintWriter。response.getOutputStream()获取字节输出流，用于下载文件、图片等二进制数据。二者互斥。
• response.addCookie(new Cookie("user", "zhangsan"))：向响应头添加Set-Cookie，浏览器下次请求会自动带上Cookie: user=zhangsan。

一个高频错误：java.lang.IllegalStateException: getWriter() has already been called for this response。原因是你在同一个Servlet方法里，既调用了getWriter()，又调用了getOutputStream()，或者在forward()之后又试图写响应。Tomcat的响应对象是单例的，一旦选择了字符流或字节流，就不能切换。

踩坑实录：某次开发，需求是“用户登录成功后，返回JSON数据，并设置Cookie”。代码如下：

response.setContentType("application/json;charset=UTF-8"); PrintWriter out = response.getWriter(); out.print("{\"code\":200,\"msg\":\"ok\"}"); Cookie cookie = new Cookie("token", "abc123"); response.addCookie(cookie); // 这行会抛IllegalStateException！

原因：getWriter()调用后，Tomcat认为响应体已经开始写入，此时再添加Set-Cookie头（属于响应头）已不允许。正确做法：先设置所有响应头（包括Cookie），再获取输出流写响应体。

4.3 Servlet生命周期：init()、service()、destroy()不是摆设，而是性能与安全的分水岭

Servlet实例由Tomcat容器管理，其生命周期严格遵循init()→service()→destroy()三步：

• init(ServletConfig config)：Servlet第一次被请求时调用，且只调用一次。适合做一次性初始化：加载配置文件、创建数据库连接池、初始化缓存。config.getInitParameter("db.url")可读取web.xml中<servlet><init-param>定义的参数。
• service(HttpServletRequest req, HttpServletResponse resp)：每次HTTP请求都调用。Tomcat内部根据req.getMethod()分发到doGet()或doPost()。这是唯一可以处理业务逻辑的方法。
• destroy()：Web应用停止（如Tomcat关闭或应用重新部署）时调用，且只调用一次。适合做资源清理：关闭数据库连接、释放线程池、保存缓存到磁盘。

新手最大误区：在service()里创建耗资源对象（如new SimpleDateFormat("yyyy-MM-dd")）。SimpleDateFormat不是线程安全的，多个请求并发调用doGet()，共享同一个SimpleDateFormat实例会导致格式化错乱。正确做法：

• 在init()里创建线程安全的对象（如DateTimeFormatter）；
• 或者在service()里每次新建（但有性能开销）；
• 或者用ThreadLocal隔离（推荐）：

  private static final ThreadLocal<SimpleDateFormat> sdfHolder = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));

经验总结：init()和destroy()是Servlet的“出生证”和“死亡证明”，它们的存在，让Servlet天然支持单例模式和资源池化。而service()是它的“工作日志”，记录每一次与用户的交互。第一次复习，务必在init()里加System.out.println("HelloServlet init...")，在destroy()里加System.out.println("HelloServlet destroy...")，然后启动、访问、关闭Tomcat，亲眼见证这三个方法的调用时机和次数。这是理解容器化编程的基石。

5. 响应生成：从字节流到浏览器渲染，中间隔着Tomcat的缓冲与编码

当response.getWriter().println("Hello World")执行完毕，你以为结束了？不，这只是响应生成的开始。这行代码产生的字符串，还要经过Tomcat的字符编码、缓冲区管理、HTTP头组装、TCP分包传输，最后才被浏览器接收、解析、渲染。热搜词里“tomcat启动出现”“tomcat部署web项目”“tomcat怎么安装”背后，是响应生成阶段的无数细节决定成败。

5.1 字符编码的三重校验：源头、管道、终点

中文乱码是JavaWeb第一大拦路虎，根源在于字符编码在三个环节的不一致：

1. 源头（浏览器/客户端）：HTML表单的<meta charset="UTF-8">或AJAX请求的contentType: "application/json; charset=utf-8"，告诉浏览器“我发送的数据是UTF-8编码”。
2. 管道（Tomcat）：server.xml的URIEncoding="UTF-8"（GET）和request.setCharacterEncoding("UTF-8")（POST），确保Tomcat用UTF-8解码。
3. 终点（响应）：response.setContentType("text/html;charset=UTF-8")，告诉浏览器“我返回的数据是UTF-8编码”。

三者缺一不可。一个典型场景：前端用fetch发POST请求，body是JSON：

fetch('/api/user', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ name: '张三' }) });

后端Servlet：

// 错误：没设置请求体编码，且没指定响应编码 String json = IOUtils.toString(request.getInputStream(), "UTF-8"); // 手动指定UTF-8 // 正确：先设置编码，再读取 request.setCharacterEncoding("UTF-8"); BufferedReader reader = request.getReader(); // 自动按UTF-8读取

5.2 缓冲区（Buffer）：为什么response.getWriter().flush()有时是救命稻草？

HttpServletResponse内部维护一个输出缓冲区（默认8KB）。println()写入的是缓冲区，不是直接发给浏览器。只有当缓冲区满、response.flushBuffer()被调用、或Servlet方法执行完毕时，缓冲区内容才会真正写入Socket。

这带来两个问题：

• 实时性问题：你想实现“进度条”，每处理1%就输出一个"1%"，但如果不flush()，浏览器要等到整个Servlet执行完才看到所有输出。
• 超时问题：Tomcat的connectionTimeout="20000"（20秒）是从连接建立到响应开始写入的时间。如果Servlet花了15秒处理，又花了10秒才flush()，第25秒才开始写响应，那么前5秒就超时了，浏览器收到503。

解决方案：在需要实时输出的场景，显式调用response.flushBuffer()：

PrintWriter out = response.getWriter(); for (int i = 0; i <= 100; i++) { out.print(i + "%"); out.flush(); // 强制刷新缓冲区，让浏览器立刻看到 Thread.sleep(100); }

5.3 WAR包结构：为什么你的class文件死活不生效？

一个标准WAR包，是JavaWeb应用的交付物。它的目录结构是Tomcat识别应用的唯一依据：

myapp.war ├── WEB-INF/ │ ├── web.xml # 部署描述符（可选，Servlet 3.0+可用注解） │ ├── classes/ # 编译后的.class文件（对应src/main/java/） │ └── lib/ # 依赖的jar包（对应pom.xml的<dependencies>） ├── index.html # 根路径的静态资源 └── css/ └── style.css

Maven的mvn package命令，就是严格按照这个结构生成WAR。如果你手动创建WAR，必须确保：

• WEB-INF/必须是大写，且必须在根目录下。
• web.xml必须放在WEB-INF/下，不能是WebContent/WEB-INF/（Eclipse旧项目结构）。
• classes/目录必须包含完整的包路径，如com/example/HelloServlet.class，对应src/main/java/com/example/HelloServlet.java。

常见错误：用WinRAR直接压缩整个项目文件夹，结果WAR包里是myapp/src/main/java/...，Tomcat根本找不到class文件，启动时报ClassNotFoundException。

实操验证：用jar -tf target/my-web-app-1.0-SNAPSHOT.war命令查看WAR包内部结构。你应该看到WEB-INF/classes/com/example/HelloServlet.class。如果看到src/或pom.xml，说明Maven配置有误，<packaging>war</packaging>没生效。

6. 故障排查：从502 Bad Gateway到404 Not Found，一条链路的逆向追踪

复习的终极目标，不是记住所有知识点，而是当问题发生时，你能像侦探一样，沿着HTTP请求的完整链路，逐层向下排查。热搜词里“unexpected status 502 bad gateway”“http error 404”“tomcat启动出现”都是信号，告诉你链路的某个环节断了。下面