简介：适合Java Web开发人员在64位Windows电脑上使用的Tomcat服务器版本，可用来部署运行基于Servlet和JSP的网站程序，也能作为学习Java Web开发的本地实验环境。压缩包内有六百四十个文件，总大小约为十点一兆字节，其中既有源代码和编译后的字节码，也有网页页面、Java归档库、可扩展标记语言配置文件，以及用于启动和关闭服务的批处理脚本，覆盖了运行一个Web应用服务器所需的主要组件。目前已有二百二十五人学习下载。解压后可以得到规范的服务器目录，例如配置目录、部署目录和日志目录，配置文件中预置了端口、连接器等内容，方便使用者根据自己的项目进行调整。该版本支持异步处理和并发请求，带有网页管理界面，既能帮助初学者快速跑通第一个Java Web项目，也能满足开发者日常调试和测试的需要。
1. apache 下载里最容易被低估的 Tomcat 版本：7.0.108 到底还能干什么
如果你维护过几个上了年纪的 Java Web 系统，就一定见过这样的现场：生产环境跑的还是 Tomcat 7，代码从不敢轻易换容器，因为一升到 Tomcat 9、10 就报各种 javax 包名不存在的错。apache 官方在 2021 年发布 7.0.108 之后，这一个分支就基本收尾了，而这个 Windows x64 的压缩包，恰好是能稳定跑 Java EE 6 / Servlet 3.0 老项目的最后一个顺手版本。它解压即用、没有安装器、不写注册表，适合三类人：要给老旧系统做迁移验证的运维，需要固定容器版本跑课程设计的在校生，以及想在一个干净 Tomcat 上搭本地调试环境的开发。这篇笔记不聊虚的，直接按我实际拆过的流程讲清楚怎么配、怎么起、踩在哪。
2. 安装前的三个决策：JDK 选型、目录规范和包完整性
2.1 JDK 版本选型：Tomcat 7 与 JDK 8 的兼容边界
很多人一听到 Tomcat 7，第一反应是必须配 JDK 7。这是一个常见的误解。Tomcat 7.0.x 官方要求的最低运行版本是 JDK 6，但 7.0.108 这个收尾版在编译时用的是更高版本的字节码，实际意义不大，因为生产上几乎没人会在 JDK 6 上跑它。我一般会直接用 JDK 8，理由有三条：
第一，JDK 8 是当前老系统存量最大的运行时，几乎每个公司的机器上都能找到；第二，Tomcat 7 的设计目标就是兼容 Java EE 6 规范，而 JDK 8 运行 Servlet 3.0 应用没有兼容性问题；第三，JDK 8 默认移除了 PermGen，改用 Metaspace，配合 Tomcat 7 反而少了一类内存溢出的坑，这一点后面避坑章节会展开。
开装之前先确认 java 命令可用，命令行执行：
java -version如果输出里出现java version "1.8.0_xxx"就是对的。如果提示不是内部或外部命令，说明 JAVA_HOME 没配好，或者 PATH 里没加%JAVA_HOME%\bin。这时候不要急着解压 Tomcat，先把 JDK 装好、环境变量配置好，再继续。不要指望 Tomcat 自带的启动脚本能帮你找 JDK，它只是从环境变量里读，找不到就直接报错退出。
还有一个容易被忽略的细节：如果机器上同时装了 JDK 和 JRE，Tomcat 的catalina.bat会优先读 JRE_HOME，其次才读 JAVA_HOME。某些软件安装时会擅自把 JRE_HOME 指向一个旧版本 JRE，导致 Tomcat 起来后版本不对。为了避免这种问题，在 setenv.bat 里显式指定 JRE_HOME 指向 JDK 目录即可，这个习惯能省掉很多排错时间。
2.2 目录规范：CATALINA_HOME 不能放在带空格或中文路径
下载回来的压缩包是 zip 格式，双击解压后会得到一个apache-tomcat-7.0.108目录。很多人随手解压到桌面或 Downloads，这在自己的电脑上跑 demo 没问题，但要是放到服务器上、写成 Windows 服务或者做脚本调用，路径里的空格和特殊字符就是定时炸弹。
我的习惯是统一解压到一个无空格的根目录，比如：
D:\apps\tomcat\apache-tomcat-7.0.108这里有两个要点。第一，目录层级不要太深，Tomcat 启动脚本里很多相对路径硬编码了CATALINA_HOME，路径太长或者有中文，脚本解析可能出现莫名其妙的“找不到文件”。第二，CATALINA_HOME这个环境变量指向的是 Tomcat 的根目录，而不是 bin 目录。很多人第一次配的时候指向了D:\apps\tomcat\apache-tomcat-7.0.108\bin，结果启动脚本找不到 lib 和 conf，直接抛CATALINA_HOME environment variable is not set correctly。
解压完看一眼目录结构，应该能看到 bin、conf、lib、logs、temp、webapps、work 这七个目录。其中 lib 目录存放的是 Tomcat 自身的 jar 包，不要把你项目的 jar 往这里塞；webapps 目录是默认的应用部署位置；work 目录存放 JSP 编译后的临时 class，如果发现改完 JSP 不生效，清掉 work 目录是第一步。
2.3 压缩包完整性检查与版本确认
从网上下载的压缩包，我建议解压前先做一次结构检查。Windows 下直接双击 zip 打开，确认第一层就是apache-tomcat-7.0.108目录而不是一长串嵌套路径。有些第三方打包站点会包一层多余目录，解压出来找不到 bin 就慌，实际是路径多套了一层。
解压完成后，可以到 bin 目录下跑一次版本确认：
D:\apps\tomcat\apache-tomcat-7.0.108\bin\version.bat正常输出里会明确显示Server version: Apache Tomcat/7.0.108，以及使用的 JVM 版本和操作系统架构。这一步能同时确认两件事：一是包本身没损坏，二是 Tomcat 能正确找到 JDK。如果 version.bat 报错，问题几乎都出在 JAVA_HOME 或 JRE_HOME 配置上，先别继续配 server.xml，回头排查环境变量。
这一步做完，安装的前置工作就干净了。接下来进入核心环节：怎么让这个 Tomcat 在你的机器上稳定跑起来。
3. 配置与启动：让 7.0.108 在 Windows 上稳定跑起来
3.1 环境变量：setenv.bat 比系统变量更省心
Tomcat 7 在 Windows 下的启动脚本是catalina.bat，它从两个地方读环境变量：一是系统/用户环境变量，二是 bin 目录下可选的 setenv.bat。很多教程会让你去“我的电脑 → 属性 → 高级系统设置”里配 CATALINA_HOME 和 JAVA_HOME，这个做法可行，但有一个代价：换一台机器部署时要重新配一遍系统变量，而且会把环境搞得很乱。
我更推荐用 setenv.bat。这个文件默认不存在，需要自己新建，复制下面的内容保存到 bin 目录下：
set "CATALINA_HOME=D:\apps\tomcat\apache-tomcat-7.0.108" set "JRE_HOME=C:\Program Files\Java\jdk1.8.0_202" set "CATALINA_OPTS=-Xms512m -Xmx1024m -Dfile.encoding=UTF-8"这三个配置的含义要理清。CATALINA_HOME 是 Tomcat 根目录，启动脚本靠它定位其他目录；JRE_HOME 指向 JDK 根目录，注意不是 jre 子目录，Tomcat 7 在 JDK 8 下会用到编译器相关功能，指到纯 JRE 目录虽然能起，但 JSP 编译功能会受限；CATALINA_OPTS 是 JVM 参数，只会作用于 Tomcat 本身启动的 JVM，不会影响环境变量，所以在这里设置堆内存最合适。
这里有一个关键认知：startup.bat 执行时会调用 catalina.bat，而 catalina.bat 如果发现 bin 目录下存在 setenv.bat，会自动先执行它。因为 setenv.bat 位于 Tomcat 目录内，换机器时跟着整个目录走，环境变量配置也就带走了，不用在每台机器上重新设置系统变量。这也解决了团队协作时“为什么他那台能起我这台起不来”的疑难杂症。
3.2 server.xml 端口矩阵：8080、8009、8005 各自的作用
启动之前先打开 conf 目录下的 server.xml，这是 Tomcat 7 的主配置文件。不用全文看懂，但三个端口必须心里有数。
第一个是 HTTP 连接器，默认监听 8080：
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />这个端口负责接收浏览器发来的 HTTP 请求。connectionTimeout 是建立连接后等待请求数据的超时时间，单位毫秒，20000 就是 20 秒。如果机器负载高、请求处理慢，可以把这个值调大，但不要超过 30000，否则连接堆积会拖垮线程池。
第二个是 AJP 连接器，默认监听 8009：
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />AJP 是 Apache HTTP Server 与 Tomcat 之间的专用通信协议，如果你不用 Apache 做前置 Web 服务器，这个端口其实用不上。但不要手贱删掉，因为某些框架的部署脚本会检测这个端口是否存在，删了可能导致启动报错。留着，保证默认值就行。
第三个是 shutdown 端口，默认是 8005：
<Server port="8005" shutdown="SHUTDOWN">这个端口负责接收关闭命令，任何人只要能连上这个端口并发送字符串SHUTDOWN，Tomcat 就会立即关闭。生产环境里明文发送关闭指令是很危险的事，我一般会改成一个随机端口，或者把 shutdown 指令改成长字符串。这一步放在最后一章的加固部分讲，现在先保持默认，确保第一次启动顺利。
3.3 首次启动与日志验证
配置完成后的第一次启动，我建议不要直接用 startup.bat，而是用前台模式：
D:\apps\tomcat\apache-tomcat-7.0.108\bin\catalina.bat run前台运行的好处是控制台直接输出启动日志，任何配置错误都会第一时间暴露。如果你直接双击 startup.bat，它会新开一个窗口并在 3 秒后关闭，要是启动失败你连错误信息都看不到，只能去翻 logs 目录，对新手很不友好。
启动日志的关键观察点有两个。一个是看是否出现Server startup in [xxx] milliseconds，出现这句话说明 Tomcat 已经成功启动；另一个是看有没有严重或SEVERE级别的红色日志。Tomcat 7 的日志文件会按日期切分，存放在 logs 目录下，catalina.<日期>.log是主日志，localhost.<日期>.log是应用相关日志，manager.<日期>.log是管理端日志。
启动成功后，打开浏览器访问：
http://localhost:8080看到默认首页那只猫，说明 HTTP 连接器工作正常。如果页面打不开，先确认启动日志有没有报错，再用下面的命令排查端口占用：
netstat -ano | findstr 8080如果看到 LISTENING 状态且 PID 不是 Tomcat 进程，说明端口被其他程序占用了，这就是下一章要讲的第一个坑。
4. 避坑与排查：Tomcat 7 部署现场最常见的 6 个问题
4.1 现象：startup.bat 启动后窗口一闪而过，访问 8080 无响应
原因：绝大多数情况是 8080 端口被占用，Tomcat 启动时绑定端口失败，脚本主动退出。另一个常见原因是 JAVA_HOME 配置错误，启动脚本在初始化 JVM 时就崩了。
解决：先跑一次前台模式看报错信息。如果是端口占用，用netstat -ano | findstr 8080找到占用进程的 PID，再在任务管理器里定位到对应程序，关掉它或者给 Tomcat 换端口。如果是环境变量问题，控制台会明确提示找不到 JAVA_HOME，回到第 3.1 节检查 setenv.bat 的路径是否正确。切忌一上来就重装软件，九成问题出在这两个点。
4.2 现象：明明配置了 JAVA_HOME，Tomcat 还是报找不到 JDK
原因：机器上同时存在多个 Java 版本，或者某个安装程序把 JRE_HOME 指向了一个不存在的目录。Tomcat 7 的启动脚本读取环境变量的优先级是先 JRE_HOME 后 JAVA_HOME，JRE_HOME 一旦被设置为错误路径，java 命令就会失效。
解决：在命令行执行echo %JRE_HOME%查看当前值，如果输出为空，直接给 setenv.bat 里加上一行显式配置。这个问题的本质是环境变量优先级造成的黑匣子，所以我前面反复强调 setenv.bat 是为了让配置跟着 Tomcat 走，不依赖系统全局变量。
4.3 现象：启动日志正常，但控制台输出中文乱码
原因：Windows 控制台默认编码是 GBK，而 Tomcat 的日志输出默认是 UTF-8，两者不一致导致中文信息变成乱码。这不会影响功能，但会干扰排错，尤其是需要从日志里读取中文文件名或异常信息时。
解决：编辑 conf 目录下的 logging.properties，把java.util.logging.ConsoleHandler.encoding从 UTF-8 改成 GBK，同时把java.util.logging.FileHandler.encoding保持为 UTF-8，这样文件日志仍是 UTF-8，便于在编辑器里查看，控制台则按 Windows 本地编码显示。这个技巧对 JDK 8 和 Windows 10/11 都有效。
4.4 现象：能正常访问页面，但服务器毫无征兆地自己关掉了
原因：如果你用的是默认配置，8005 端口上明文监听着SHUTDOWN指令。某些内网扫描工具或者运维巡检脚本会探测这个端口，一旦发了这个字符串进程就退出。我在内网环境遇到过数次类似情况，都怀疑是扫描器导致的。
解决：修改 server.xml 中的 shutdown 属性，改成一段不容易被猜中的字符串，同时把端口从 8005 改成一个不常用端口。注意改完要重启 Tomcat 才生效，且 CATALINA_HOME 内如果有多个实例，端口不能冲突。
4.5 现象：运行一段时间后出现内存溢出，日志提示 PermGen space
原因：如果用的是 JDK 7，PermGen 空间默认只有几十 MB，部署多个应用或者频繁热部署时极易打满。JDK 8 下默认使用 Metaspace，所以这个问题在 JDK 8 上出现的概率大幅下降，但老环境里仍常见。
解决：在 setenv.bat 的 CATALINA_OPTS 里加上-XX:MaxPermSize=256m（仅限 JDK 7），JDK 8 环境则加-XX:MaxMetaspaceSize=256m。同时检查是否开启了自动部署，conf 目录下的 context.xml 里autoDeploy属性默认是 true，频繁扫描热部署会加剧内存碎片，生产环境建议改成 false。
4.6 现象：改了 server.xml 里的端口或参数，重启后配置不生效
原因：改错了文件。Tomcat 7 的 conf/server.xml 只有一个，但如果你把文件复制到 conf/Catalina/localhost 目录，某些配置会以这个目录下的片段优先。另外 Windows 下记事本另存为可能导致文件编码变成带 BOM 的 UTF-8，XML 解析器遇到 BOM 会直接忽略文件或报错，配置就相当于没改。
解决：用不带 BOM 的编辑器（比如 Notepad++ 或 VS Code）修改 server.xml，保存时选择 UTF-8 无 BOM 编码。修改后先执行catalina.bat configtest检查配置文件语法，这个命令不会启动服务，只验证配置，能省掉大量来回重启的时间。
5. 进阶与收尾：用一轮“体检”确认安装结果并完成最小加固
Tomcat 7.0.108 跑通之后，我习惯做一轮完整验证，确保这个环境是可信赖的，而不是“能打开首页就行”。
先确认版本和编译信息。bin 目录下的 version.bat 只输出版本号，如果想要更详细的 JVM 参数和构建信息，可以用：
catalina.bat version它会输出当前使用的 JVM 路径、JVM 版本、操作系统架构以及 Tomcat 的构建时间。记录下这一行输出，等于给这个环境建立了一个基线，以后排查“是不是换过 JDK”这类问题时，直接对比基线就知道有没有变化。
然后是端口健康检查。除了 8080 之外，8009 和 8005 也要确认状态。用一条命令把三个端口全部看一遍：
netstat -ano | findstr "8080 8009 8005"确认 HTTP 连接器是 LISTENING，AJP 如果不需要可以不用管，shutdown 端口只要存在即可。这一步能提前发现端口被其他服务抢占的隐患。
第三步是最小化加固。打开 conf/tomcat-users.xml，把默认的管理员配置全部注释掉，按需添加最低权限用户。如果你不需要通过 Web 界面管理应用，就把 manager 和 host-manager 两个应用从 webapps 目录下重命名或删除。我一般会保留 manager 但加上强密码，毕竟有些运维操作还是需要通过它完成：
<role rolename="manager-gui"/> <user username="admin" password="替换为强密码" roles="manager-gui"/>同时把 server.xml 里的 shutdown 端口和指令改为随机值，避免本机端口探测造成的误关。
最后做一次 JVM 参数验证。打开浏览器访问任意一个 JSP 页面，然后看 logs 目录下最新的 catalina 日志，正常会记录一次请求处理。如果你在 setenv.bat 里配了-Xmx1024m，可以通过 JDK 自带的 jinfo 工具确认生效：
jinfo -flags <Tomcat进程PID>看到-Xmx1024m出现在输出里，说明内存参数真的被 JVM 吃到了，不是只在脚本里写了却没生效。
这套流程走完之后，这个 Tomcat 7.0.108 的 Windows x64 环境才算真正立住了。从那以后我每次装完 Tomcat 都会强制走一遍“版本回显 + 端口自查 + 配置语法检查”的流程，跑一遍只需要两分钟，但能省掉后续排错的两小时。希望帮到你。
本文还有配套的精品资源，点击获取
