企业官网建设流程全解析

简介：apache-tomcat-8.5.38-windows-x64.zip 是 Apache Tomcat 8.5.38 的 Windows 64 位免安装压缩包，面向需要在本地搭建 Java Web 运行环境、学习 Servlet 与 JSP 开发的初学者及 J2EE 应用开发者。它提供轻量级 Servlet/JSP 容器，解压后通过 bin 目录下的启停脚本即可运行，适用于课程实验、项目调试与小型应用部署等场景。压缩包共 645 个文件，整体约 11.08MB，既包含 Manager 管理界面相关的 html、xhtml 页面，也含 Tomcat 自身实现与示例的 class、java、jsp 源码；jar、properties、xml 提供依赖与配置，bat、sh 为启停脚本，gif、png、svg 等则是界面静态资源，共同构成一套可直接运行的完整服务器目录。已有 140 人学习下载，使用者可借此熟悉 conf 下 server.xml、web.xml、tomcat-users.xml 的配置方式，掌握 war 包部署、管理界面使用、SSL 连接器调整与日志排查等实践，为在 IDE 中集成 Tomcat、理解 J2EE 容器机制打下基础。

1. 一个 8.5.38 的 Windows 包，为什么还是很多人接触 J2EE 的第一站

接手一个跑了七八年的 J2EE 老系统做本地排查，对方发过来的往往不是源码仓库，而是一个 apache-tomcat-8.5.38-windows-x64.zip，附一句「你先在本地跑起来看看」。解压、配 JDK、双击启动，三步之内就能判断这台机器到底有没有条件接手这套东西。它实现的是 Servlet 3.1、JSP 2.3 这一代规范，属于容器层面的「最小可运行单元」：不带任何业务代码，但把请求分发、会话、类加载、部署目录这些机制全都摆在你面前。适合两类人：一类是要在 Windows 上快速搭出调试环境、不想折腾构建工具的后端同学；另一类是接手遗留系统、必须搞清楚「war 放进去之后到底发生了什么」的维护者。这份包的价值不在新，而在可预期——目录结构、配置文件、日志格式十年不变，出了问题有据可查。

2. 解压之后先别急着启动：conf 和 bin 两个目录决定了它能跑成什么样

拿到压缩包的第一反应通常是找 startup.bat，但从排错的角度看，先花十分钟把目录结构过一遍，后面能省掉大量「启动黑窗口一闪而过」的时间。Windows 版的分发包是一个完整的 CATALINA_HOME，容器本身、配置、示例应用、日志目录全在里面，改错一个文件就可能起不来，而所有需要动的地方其实集中在 conf 和 bin。

2.1 这份分发包里，哪些目录真的会被改到

解压出来大致是这样一棵树，先把每一层的作用记清楚，比看任何文档都快：

有两个细节值得单独说。第一，lib 下的 servlet-api.jar、jsp-api.jar 是容器提供给应用的接口包，打 war 的时候千万不要把同名 jar 一起打进去，否则会出现两个同名类被不同类加载器加载，报ClassCastException或者过滤器莫名不生效，这类问题查起来非常费时间。第二，work 目录是 JSP 的编译产物缓存，改了 JSP 但页面行为没变、或者报编译错误却看不到新日志时，直接把对应应用子目录删掉重启，多数情况能立刻恢复正常。我一般会在启动脚本旁边放一个清缓存的批处理，排查前端页面类问题时先用一次。

2.2 端口、JVM 参数、编码：解压后最先要动的三处

conf/server.xml 里默认监听两个端口：<Server port="8005" shutdown="SHUTDOWN">是关闭指令端口，HTTP 连接器是 8080。同一台机器上要跑多个实例，或者 8080 已经被别的服务占了，就要从这里改。注意 8005 不改而只改 8080，两个实例同时跑时会因为关闭端口冲突导致后启动的那个关不掉，只能去任务管理器里结束进程。

<!-- conf/server.xml 片段：只改必要项，其余保持默认 --> <Server port="8005" shutdown="SHUTDOWN"> <Service name="Catalina"> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" maxThreads="200" acceptCount="100" /> <Engine name="Catalina" defaultHost="localhost"> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> </Host> </Engine> </Service> </Server>

参数含义按改动的优先级说：port是监听端口；protocol="HTTP/1.1"在 8.5 这一代默认走 NIO 实现，不用显式写Http11NioProtocol；connectionTimeout是连接建立后等待请求行的毫秒数，默认值 20000 够用，压测时不要为了「响应快」把它调到几百毫秒，那只会把慢客户端直接掐断；maxThreads与acceptCount是并发处理的核心，前者是工作线程上限，后者是等待队列长度，队列满了之后的连接会被直接拒绝，这两个值的关系在第 4 章展开；URIEncoding="UTF-8"在 8.x 的 HTTP 连接器上默认已经是 UTF-8，显式写出来主要是防后续有人改回旧值，属于「写死比默认值可信」的那一类配置。

JVM 参数不要直接改 catalina.bat，那是升级或替换版本时一定会被覆盖的文件。正确做法是在 bin 下新建 setenv.bat，启动脚本会自动调用它：

@echo off rem bin/setenv.bat —— 只在当前实例生效，不污染系统环境变量 set "CATALINA_HOME=D:\server\apache-tomcat-8.5.38" set "CATALINA_BASE=D:\server\apache-tomcat-8.5.38" set "JAVA_HOME=C:\Java\jdk1.8.0" set "CATALINA_OPTS=-Xms512m -Xmx1024m -XX:MaxMetaspaceSize=256m -Dfile.encoding=UTF-8 -Duser.timezone=GMT+08" set "JAVA_OPTS=%JAVA_OPTS% -Djava.awt.headless=true"

这里有两个容易混的变量。CATALINA_OPTS只在启动容器时传给 JVM，适合放堆大小、时区、文件编码这类运行期参数；JAVA_OPTS会被 shutdown、version 等命令一并带上，放内存参数会导致关闭脚本也去申请同样大小的堆，机器内存紧张时关闭动作会变慢甚至失败。我的习惯是内存参数一律进 CATALINA_OPTS，只有确实需要所有命令共享的属性才写 JAVA_OPTS。-Dfile.encoding=UTF-8在 Windows 中文环境下尤其重要，控制台默认代码页是 GBK，日志里的中文如果出现乱码，第一嫌疑就是它没设。-XX:MaxMetaspaceSize是给类元数据兜底的，热部署频繁的调试环境不设上限，几天后可能把机器吃满。

2.3 解压路径的三条硬约束，踩过就知道疼

路径这件事看起来无关技术，实际上是最常见的一类「启动失败」。第一条，不要解压到 Program Files 或 Program Files (x86) 下面。这些目录默认需要管理员权限写入，而 Tomcat 启动时要在 logs 下创建当天的日志文件、在 work 下写编译产物，权限不足时的报错往往藏在日志深处，表现却是「窗口一闪就没了」。放在 D:\server 这类普通目录下最省心。

第二条，路径里不要有中文和空格。catalina.bat 内部对路径做了引号处理，大部分情况没问题，但一些第三方脚本、服务安装工具、以及从别的机器拷过来的启动脚本，对空格和中文的处理并不可靠。第二条的变体是路径别太深，Windows 的路径长度限制还在，war 包解压到多层级目录时，超过长度会抛The filename or extension is too long，这个报错跟 Tomcat 本身没关系，但报在部署阶段，很容易被误判成包坏了。

第三条，如果要在同一台机器上跑多个实例，用 CATALINA_HOME 与 CATALINA_BASE 分离的方式：把解压目录当作 HOME 只读共享，每个实例建一个自己的 BASE，里面放 conf、logs、webapps、work、temp 五个目录，启动前设好这两个变量。这样升级容器版本时只换 HOME，各实例的配置和部署物不受影响。单实例调试没必要这么麻烦，但一旦开始做多环境验证，这个习惯能省掉大量复制粘贴。

3. 从零跑起第一个 J2EE 应用：JDK 匹配、启动方式与部署路径

环境配好之后，真正的动作只有三个：确认 JDK 版本对得上、用能看到报错的方式启动、把应用放到容器认识的位置。这三步里任何一步用「双击试试」的方式糊过去，后面出问题都只能靠猜。

3.1 JDK 版本与 class 文件版本，先对齐再谈部署

8.5 这一代容器要求 Java 7 及以上，跑在 Java 8 上是最常见的组合。但「装了 JDK」不等于「Tomcat 用对了 JDK」，机器上装了三四个版本、PATH 里的是 11 而项目是 8 编译的，这种情况非常普遍。先验证：

rem 在 cmd 中执行，确认当前生效的 JDK 版本 java -version javac -version rem 查看 Tomcat 实际使用的 JAVA_HOME echo %JAVA_HOME%

输出里java version "1.8.0_xxx"说明运行时是 8。如果编译用的是更高版本，部署后会直接抛出java.lang.UnsupportedClassVersionError，报错信息里会带两个数字，比如compiled by a more recent version of the Java Runtime (class file version 55.0), this version only recognizes ... 52.0。这两个数字就是 class 文件版本号，对照关系是：52 对应 Java 8，53 对应 Java 9，55 对应 Java 11。看到这个错不要去改 Tomcat 配置，那是编译目标版本和运行版本不一致，要么换 JDK，要么在构建里把 source 和 target 降到 8。

如果机器上必须保留多个 JDK，就在 setenv.bat 里显式写死 JAVA_HOME，不要依赖系统环境变量。系统变量是全局的，改一次影响所有程序，而 setenv.bat 只影响这一个实例，出问题范围可控。

3.2 用 catalina.bat run 启动，日志直接打在控制台

startup.bat 会另开一个窗口，出错时窗口一闪而过，什么都看不到。调试阶段我一般直接用 run 模式，日志全部输出到当前控制台，报错第一行就能看见：

cd /d D:\server\apache-tomcat-8.5.38\bin catalina.bat run

启动过程里值得盯住的几行日志：Using CATALINA_BASE和Using CATALINA_HOME告诉你容器到底加载了哪个目录的配置，多个实例环境下这是排查「改了配置不生效」的第一证据；Server version name: Apache Tomcat/8.5.38确认版本没拿错；Deploying web application archive [...]说明 war 被识别到了；最后一行Server startup in [xxxx] milliseconds出现，才代表启动完成。如果卡在某个应用部署上不动，通常是那个应用的ServletContextListener里做了阻塞操作，比如连数据库超时、读远程配置没设超时，这时候日志会停在部署那一行，需要用 jstack 看线程栈。

run与start的区别只在前台还是后台，配置完全一样。确认能正常启动之后再用 startup.bat 挂到后台，日常开发用 run 更利于观察。停止时用catalina.bat stop，或者在 run 的窗口里按 Ctrl+C，后者更干脆，但会跳过应用里的销毁回调，调试阶段无所谓，做优雅停机验证时要用 stop。

3.3 war 包、解压目录与 context path：部署路径到底怎么算

把应用放进 webapps 之后，访问路径由文件名决定，这条规则很多人是靠试出来的。war 叫 demo.war，访问路径就是/demo；想挂到根路径，必须叫 ROOT.war。部署有两条路：

rem 方式一：拷贝 war 包，让容器自己解压 copy /Y D:\build\demo.war D:\server\apache-tomcat-8.5.38\webapps\ rem 方式二：直接放解压后的目录（调试期改 JSP 更快） xcopy /E /I /Y D:\build\demo D:\server\apache-tomcat-8.5.38\webapps\demo

Host 上的三个属性决定行为：unpackWARs="true"让容器把 war 解压成目录再加载，改 JSP 能立刻生效；autoDeploy="true"让容器定时扫描 webapps，发现新增或更新就热部署；deployOnStartup="true"控制启动时是否全量扫描。开发环境三个都开着最方便，但要注意热部署会重新加载整个应用，静态变量全部重置，会话默认也会失效，调试有状态的功能时容易误判成 bug。生产环境常见做法是关掉 autoDeploy，用重启或外部脚本控制发布节奏，避免容器在不可预期的时刻重新加载应用。

另一条容易忽略的规则：war 包和同名目录同时存在时，容器优先用目录，war 包会被忽略。改了 war 拷进去没生效，先看看旁边是不是还留着一个旧的解压目录，删掉它再重启，比反复检查 war 内容快得多。

4. server.xml 与 web.xml：把默认配置改成能扛住真实流量的样子

默认配置是给开发用的，能跑通不等于能用。真正上线前，需要调整的地方集中在三块：连接器的并发参数、虚拟主机与上下文映射、以及从请求到页面这条链路上的编码设置。三块都改错过的代价，远比读一遍配置高。

4.1 Connector 参数：maxThreads 和 acceptCount 到底是什么关系

这两个值经常被一起改，但作用完全不同。maxThreads是实际处理请求的工作线程上限，默认 200；acceptCount是操作系统的等待队列长度，线程全忙时新连接在这里排队，队列满了就直接拒绝，默认 100。所以单实例能同时接住的连接数大致是两者之和，超出部分拿不到响应而是连接重置，客户端看到的是Connection reset，很容易被误判成网络问题。

调参的前提是有观测。没有 access log 和线程数监控的情况下加线程，只是在延长排队的队伍，并不能提高吞吐。我一般的顺序是：先开 access log 看响应时间分布，确认瓶颈在应用侧还是连接侧，再决定动 maxThreads，最后才考虑 acceptCount。把 maxThreads 从 200 直接改到 1000 而数据库连接池还是 20，结果一定是线程全堵在拿连接上，机器负载飙高、吞吐反而下降。

调整后要验证的是「拒绝行为是否符合预期」，而不是「能不能起来」。用压测工具把并发打到超过 maxThreads + acceptCount，观察日志里是否出现连接被拒、响应时间是否陡增，这一步在准生产环境里做一次，比上线后半夜被叫起来强。

4.2 Host 与 Context：路径映射到底谁说了算

应用挂在哪个路径上，由三层配置逐级决定。最外层是 Engine 的defaultHost，指向默认虚拟主机；中间是 Host 的name和appBase，决定域名和部署根目录；最内层是应用自己的 context path，默认由 war 文件名推导。

<!-- conf/server.xml：一个 Engine 下挂多个 Host 的写法 --> <Engine name="Catalina" defaultHost="localhost"> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t &quot;%r&quot; %s %b %D" /> </Host> <Host name="app.internal" appBase="webapps_app" unpackWARs="true" autoDeploy="false" /> </Engine>

这段配置里有两个关键点。第一，pattern末尾的%D是处理耗时（毫秒），排查「哪个接口慢」时比默认格式有用得多，默认的 access log Valve 在分发包里是注释状态，需要手工放开。第二，增加一个 Host 就要增加一个 appBase 目录，两个 Host 指向同一个 appBase 会导致应用被重复加载，启动日志里出现两份Deploying记录，会话和静态资源都会串。

有些老项目会习惯在 server.xml 里直接写<Context path="/xxx" docBase="...">。这种方式在 8.5 上仍然可用，但一旦 Host 开了 autoDeploy，容器会重新扫描并覆盖你手工写的 Context，表现为「配置明明改了，访问路径还是旧的」。更稳的做法是把 context 配置放到应用自己的META-INF/context.xml里，跟着应用走，升级容器不用改 server.xml。

4.3 编码链路：GET、POST、JSP 三处各有各的开关

中文乱码在 J2EE 项目里几乎是必现问题，原因是编码设置分散在三个层面，缺一处就断链。第一处是 URL 和查询串的解码，由连接器的 URIEncoding 决定，8.x 默认 UTF-8，一般不用管。第二处是请求体的解码，POST 表单提交的内容由request.setCharacterEncoding()决定，而它必须在读取任何参数之前调用，写在业务代码里很容易漏。

<!-- WEB-INF/web.xml：用容器自带的过滤器统一设置请求体编码 --> <filter> <filter-name>encodingFilter</filter-name> <filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> <init-param> <param-name>ignore</param-name> <param-value>false</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <filter-mapping>/*</filter-mapping> </filter-mapping>

ignore=false表示强制覆盖，即使业务代码里已经设过别的编码也会被改成 UTF-8，这一点在接手老项目时很有用，能把散落在各处的重复设置统一掉。需要注意这个过滤器来自容器的 lib 目录，跟着容器走；如果应用未来要迁到别的容器，自己写一个等价的 Filter 更稳妥，逻辑就是先 setCharacterEncoding 再放行。

第三处是 JSP 页面的输出编码，由页面指令控制，<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8" %>两个属性都要写：pageEncoding 决定源文件按什么编码读取，contentType 里的 charset 决定响应头里的字符集。只写一个，在中英文混排的页面上就可能出现一半正常一半乱码。响应侧的字符集如果被过滤器或业务代码提前设置过，JSP 里的设置不生效，排查时先看响应头里的Content-Type实际值。

5. 排查清单：Windows 下 Tomcat 起不来的五类典型故障

这几条基本覆盖了我在 Windows 环境里遇到的绝大多数「起不来」和「起来了但不对」。顺序按发生阶段排，从启动到运行，每条都写清楚现象、原因和处置动作。

5.1 启动阶段：闪退、端口占用、类版本不匹配

现象一：双击 startup.bat，黑窗口一闪就消失，什么提示都没有。原因是启动脚本在真正拉起 JVM 之前就失败了，常见于 JAVA_HOME 未设置、路径里带空格或中文、或者 JRE_HOME 指向了一个不存在的目录。解决方式是不要再双击，打开 cmd 执行cd /d ...\bin再catalina.bat run，如果第一行就提示The JAVA_HOME environment variable is not defined correctly，说明变量问题；如果执行到一半才报错，报错信息会完整留在控制台。顺带检查 setenv.bat 里有没有写错的路径，这个文件是自己加的，最容易带着笔误。

现象二：控制台报java.net.BindException: Address already in use: bind，启动中断。原因是 8080 或 8005 被占用，可能是上一个 Tomcat 进程没退干净，也可能是别的服务占了。解决分两步：netstat -ano | findstr :8080找到 PID，tasklist | findstr <PID>确认是什么进程，确认可以结束后taskkill /PID <PID> /F；如果占用者是必须保留的服务，就改 server.xml 里的端口。注意 8005 冲突时表现为启动成功但shutdown.bat无效，很多人会误以为关闭脚本坏了。

现象三：部署后访问报UnsupportedClassVersionError。原因是编译用的 JDK 版本高于运行容器的 JDK，class 文件版本号对不上。解决方式是统一版本：要么把运行时换成更高版本（注意 8.5 这一代对高版本 JDK 的兼容性有限，不要盲目上），要么在构建配置里把编译目标降到 8。改完记得清掉 work 目录和应用的 classes，否则可能还是加载旧产物。

5.2 运行阶段：404、乱码、会话丢失

现象四：容器启动正常，浏览器访问返回 404，日志里没有任何异常。这是最容易被误判成「容器坏了」的一类。原因通常有三个：应用名大小写不对（Windows 文件系统不敏感，但 URL 路径敏感，/Demo和/demo是两回事）；war 包没被解压，而应用依赖解压目录里的资源；或者 server.xml 里 Host 的 appBase 被改过，应用实际没在那个目录下。排查顺序是先看启动日志里有没有Deploying web application archive对应的那条记录，没有就是没被扫到；有记录但访问 404，就去 webapps 下确认目录结构和WEB-INF/web.xml是否存在。

现象五：页面中文乱码，或者登录后下一次请求就掉线。这两个现象常被当成两个问题，其实同源。乱码按第 4.3 节的三层链路依次查：响应头字符集、请求体编码、JSP 页面指令。会话丢失则先看应用有没有配置sessionCookiePath或者自定义了 cookie 名，多应用同域部署时 cookie 互相覆盖是典型原因；再检查web.xml里的<session-config><session-timeout>是不是被设成了很小的值。还有一个隐蔽原因：war 包热部署时容器会重建应用，默认不持久化会话，调试期间频繁改文件就会出现「刚登录就掉线」，把autoDeploy关掉或者接受这个代价即可。

补充一条经常被忽略的：日志文件不生成。现象是 logs 目录空的，控制台却有输出。原因是 logging.properties 里配置的 handler 指向了别的目录，或者目录权限不足写不进去。Windows 上从别处拷过来的 Tomcat 目录经常带着只读属性，整个目录右键属性里去掉只读，或者用管理员权限跑一次启动脚本生成文件后再恢复正常权限，问题基本能解。

6. 把 8.5.38 固化成可复现基线：三个自检动作和一个改不掉的习惯

同一个包在不同机器上表现不一致，八成不是包的问题，而是基线没有固化。我的做法是把它当成一个固定环境来维护：配置只通过 setenv.bat 和 conf 下的三个文件改，其余目录保持原样；换机器时把整个目录打包带走，而不是在新机器上重新解压再凭记忆配一遍。

启动之后先做三个自检，确认这套环境是「可复现」的，而不是「这次碰巧能跑」：

rem 自检一：确认容器用的 JDK 与预期一致 catalina.bat version rem 自检二：确认部署路径与 context path curl -I http://localhost:8080/demo/ rem 自检三：确认 access log 已经在写，且带耗时字段 type D:\server\apache-tomcat-8.5.38\logs\localhost_access_log.*.txt

第一条输出里会打印 JVM 版本和 CATALINA_BASE，多实例环境下这是唯一可信的来源；第二条只看状态码和响应头，不做业务校验，能区分「容器没起来」和「应用没部署好」；第三条确认日志真的落盘并且格式里有%D，没有耗时数据的日志在排性能问题时价值有限。

几个值得固化的具体项列在下面，都是踩过之后加进去的：

最后说一个改不掉的习惯：每次在别人的机器上接手环境，我都不先问「你装了什么」，而是先跑一遍catalina.bat version和curl -I，把输出截图存进排查记录。有太多次是因为对方环境里 JAVA_HOME 指向了另一个 JDK、或者 webapps 里躺着一个同名旧目录，导致排查方向整整偏了两小时。从那以后我每次起环境都强制走一遍这三个自检，宁可多花三分钟，也不要在错误的前提上做推理。希望帮到你。

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