简介：apache-tomcat-7.0.103-windows-x64.zip 是面向 Java Web 初学者与中小型项目开发者的免安装 Tomcat 运行环境，解压即可使用，省去繁琐的配置步骤，适合本地调试 Servlet、JSP 及部署轻量级 Web 应用。压缩包共 648 个文件，约 10.38MB，以 237 个 html 文档、106 个 class 字节码、78 个 java 源码、58 个 jsp 页面为主，另含 30 个 jar 依赖库、15 个 xml 配置、11 个 properties 属性文件，以及 bat 启动脚本、tld 标签库、xsd 校验文件等，完整覆盖 Tomcat 的文档、源码与运行组件。目前已有 573 人学习下载，说明该版本在 Windows 环境下具备稳定的使用基础。借助这份资源，读者可直接获得可运行的 Tomcat 7.0.103 目录结构，对照 conf 配置、webapps 示例与 bin 脚本理解容器启动流程，快速搭建本地 Java Web 调试环境，并借助自带文档排查端口占用、部署路径等常见问题。

1. Tomcat 7.0.103 Windows 版：一个老版本压缩包为什么还在被反复下载

apache-tomcat-7.0.103-windows-x64.zip这个文件名，做 Java Web 的人大概率在某个目录里见过。它不是一个新东西，Tomcat 7 这条线早在多年前就停止了功能迭代，7.0.103 是这条线上最后几个维护版本之一。但现实是，很多内网系统、老政务项目、教学实验环境、遗留 ERP 的部署文档里，写的还是这个包名。原因很直接：老项目跑在 JDK 7 或 JDK 8 上，Servlet 3.0 规范够用，升级 Tomcat 8/9 反而可能因为 API 变动、配置项改名、JSP 编译行为差异导致启动失败。

这个 zip 是 Windows 64 位免安装版，解压即用，不需要跑安装程序，也不写注册表。它解决的核心问题是：在一台 Windows 机器上快速拉起一个能跑 war 包和 JSP 的 Servlet 容器，且不污染系统环境。适合谁？维护遗留系统的后端、要交课程设计的学生、需要在本地复现生产环境问题的运维。如果你手上是全新项目，我不会建议你从 7.0.103 起步；但如果你面对的是一个只能跑在 Tomcat 7 上的老 war 包，那这个压缩包就是最省事的路径。

2. 解压之后先别急着 startup：目录结构与三个环境变量

2.1 解压路径的选择直接决定后续会不会翻车

把 zip 解压到哪，看起来是小事，实际是后面一半问题的根源。我一般会固定放在一个没有空格、没有中文、路径尽量短的目录，比如D:\server\tomcat7。原因有三个：第一，CATALINA_HOME里带空格时，某些老版本启动脚本拼接 classpath 会出问题；第二，中文路径在 JSP 编译、日志输出、临时文件写入时容易出现编码异常；第三，路径太深会让 Windows 的路径长度限制在嵌套部署时被触发。

解压完成后，你会看到这些目录：

work目录值得单独说一句。JSP 第一次访问会被编译成 Java 再编译成 class，产物就在work下。当你改了 JSP 但页面没变化，或者报一些莫名其妙的类找不到，八成是work里的缓存和当前代码对不上。血泪经验：删work再重启，能解决相当一部分“我明明改了”的问题。

2.2 三个环境变量和 setenv.bat 的写法

Tomcat 在 Windows 上依赖两个核心环境变量：JAVA_HOME和CATALINA_HOME。JAVA_HOME指向 JDK 根目录，注意是 JDK 不是 JRE，因为 JSP 编译需要tools.jar（JDK 8 及以前）或对应的编译器模块。CATALINA_HOME指向 Tomcat 解压根目录。

# 在系统环境变量里设置（示例路径，按实际改） JAVA_HOME = D:\java\jdk1.8.0_xxx CATALINA_HOME = D:\server\tomcat7 # PATH 里追加 %JAVA_HOME%\bin %CATALINA_HOME%\bin

设置完之后，验证一下：

# 打开新的 cmd 窗口，必须新开，否则读不到新变量 echo %JAVA_HOME% echo %CATALINA_HOME% java -version

java -version要能正常输出，且版本要和 Tomcat 7 兼容。Tomcat 7.0.103 建议跑在 JDK 7 或 JDK 8 上，用 JDK 11 及以上会有模块化相关的坑，比如javax.xml.bind被移除导致启动报 ClassNotFoundException。

比环境变量更灵活的做法是在bin目录下新建setenv.bat，把 JVM 参数写进去，这样不污染系统变量，换机器也好迁移：

# D:\server\tomcat7\bin\setenv.bat set "JAVA_OPTS=-Xms512m -Xmx1024m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m" set "JAVA_OPTS=%JAVA_OPTS% -Dfile.encoding=UTF-8" set "CATALINA_OPTS=-Djava.awt.headless=true"

逻辑说明：JAVA_OPTS在启动和停止时都会生效，CATALINA_OPTS只在启动时生效，所以内存参数放哪个都行，但只给启动用的参数（比如 headless）放CATALINA_OPTS更干净。-Xms和-Xmx分别是最小和最大堆，老项目内存泄漏常见，-Xmx别设太大，否则出问题时机器直接卡死而不是抛 OOM，反而不好定位。-Dfile.encoding=UTF-8是防中文乱码的第一道保险，但注意它不能解决所有乱码，后面还会讲。

3. 端口、编码、内存：server.xml 里必须改的几处

3.1 改端口和关闭不必要的连接器

conf/server.xml是 Tomcat 的主配置。默认监听 8080，如果被占用（比如装了其他中间件），启动会报Address already in use。改法：

<!-- conf/server.xml 片段 --> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" maxThreads="200" minSpareThreads="10" acceptCount="100" />

参数说明：port是监听端口，改成你要的；URIEncoding="UTF-8"决定 GET 请求参数和 URL 路径的解码方式，不设的话默认是 ISO-8859-1，中文参数会乱码，这是老版本最经典的坑之一；maxThreads是最大工作线程数，默认 200，内网小系统够用，高并发要结合压测调；acceptCount是等待队列长度，队列满了新连接直接被拒。connectionTimeout单位毫秒，超时断开。

另外，server.xml里默认有一个 AJP 连接器（8009 端口），如果你不用 Apache HTTP Server 做前端转发，可以注释掉，少开一个端口少一份风险：

<!-- 不用 AJP 就注释掉 <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> -->

3.2 内存参数和编码参数到底该写在哪

很多人把内存参数写进catalina.bat，这是不推荐的，因为升级或替换脚本时会被覆盖。正确位置是setenv.bat，前面已经给了写法。这里补充一个判断内存是否够用的方法：启动后访问一个压力页面，同时用jconsole或jvisualvm连上去看堆曲线。如果老年代持续上涨且 Full GC 后不回落，就是内存泄漏，加-Xmx只是拖延，得去查代码。

编码问题要分三层看：第一层是 JVM 的file.encoding，影响日志和文件读写；第二层是 Connector 的URIEncoding，影响 URL 解码；第三层是应用自己的request.setCharacterEncoding和响应头Content-Type。三层里任何一层没对齐，中文就会出问题。我一般会在setenv.bat里加-Dfile.encoding=UTF-8，Connector 加URIEncoding="UTF-8"，应用层用过滤器统一设UTF-8，三管齐下。

3.3 用 startup.bat 启动并确认真的起来了

配置改完，双击bin\startup.bat或者在 cmd 里执行。注意：不要直接关掉那个黑窗口，关掉等于停服务。启动过程会新开一个窗口显示日志，看最后有没有Server startup in xxx ms。

# 在 cmd 里启动，方便看输出 cd /d D:\server\tomcat7\bin startup.bat # 验证端口是否监听 netstat -ano | findstr :8080 # 验证 HTTP 是否响应 curl http://localhost:8080/

如果netstat有输出但浏览器打不开，先看 Windows 防火墙是不是拦了；如果netstat没输出，看启动窗口的报错。常见的是JAVA_HOME没配好，报The JRE_HOME environment variable is not defined correctly。停止服务用shutdown.bat，别直接叉掉窗口，否则可能留下僵尸进程占着端口，下次启动就报端口占用。

4. 部署 war 包与 JSP 编译：从放到跑通的完整链路

4.1 war 包部署的两种方式和自动解压行为

部署一个 war 最简单的方式是把它复制到webapps目录下。Tomcat 启动时会自动解压 war 成同名目录，并部署。如果你的 war 叫myapp.war，访问路径就是http://localhost:8080/myapp/。

# 复制 war 到 webapps copy D:\build\myapp.war D:\server\tomcat7\webapps\ # 重启 Tomcat（或等自动扫描，但重启最稳） cd /d D:\server\tomcat7\bin shutdown.bat startup.bat

逻辑说明：Tomcat 默认的Host配置里autoDeploy="true"、unpackWARs="true"，所以放进去会自动解压部署。但自动部署有延迟，且热部署在老应用上容易出类加载器泄漏，生产环境我一般关掉自动部署，改成手动重启。关掉的方法是在server.xml的<Host>标签里设autoDeploy="false"、unpackWARs="true"。

部署后如果访问 404，先确认三件事：war 是否真的解压出了目录、目录名和访问路径是否一致、webapps下有没有残留的同名旧目录。旧目录不删，新 war 解压时可能合并出问题。

4.2 用 manager 应用做可视化部署（可选但好用）

Tomcat 自带一个manager应用，可以在浏览器里上传 war、启动停止应用。默认它是被限制访问的，需要配用户。改conf/tomcat-users.xml：

<!-- conf/tomcat-users.xml --> <tomcat-users> <role rolename="manager-gui"/> <user username="admin" password="换成你的强密码" roles="manager-gui"/> </tomcat-users>

注意：manager-gui角色只能从本机访问，远程访问需要额外配context.xml的RemoteAddrValve，但我不建议对公网开放 manager，风险太高。配好后访问http://localhost:8080/manager/html，输入账号密码即可看到部署界面。这个方式适合调试阶段频繁换包，省去反复复制重启。

4.3 JSP 编译报错怎么定位

JSP 出问题，报错信息往往很长，但关键就几行。定位顺序是：先看浏览器页面上的异常栈最底部（根因通常在Caused by后面），再去看logs目录下对应的日志文件。logs里localhost.yyyy-mm-dd.log是应用级日志，catalina.yyyy-mm-dd.log是容器级日志。

# 实时看日志（Windows 没有 tail，用 powershell） powershell Get-Content D:\server\tomcat7\logs\catalina.out -Wait -Tail 50

如果报Unable to compile class for JSP，常见原因是 JDK 版本和 Tomcat 不匹配，或者work目录里的旧编译产物冲突。解决：停服务，删work\Catalina整个目录，重启。如果报The absolute uri ... cannot be resolved，是 taglib 声明或 jar 缺失，检查WEB-INF/lib里有没有对应的标签库 jar。

5. 避坑与排查：老版本 Tomcat 在 Windows 上的五个高频翻车点

5.1 启动一闪而过，窗口关了但服务没起来

现象：双击startup.bat，黑窗口闪一下就没了，浏览器访问不了。原因：startup.bat本身只是调用catalina.bat start，真正的启动日志在新开的窗口里，如果新窗口因为配置错误秒退，你就什么都看不到。解决：不要双击，在 cmd 里执行catalina.bat run，这样日志直接打在當前窗口，报错一目了然。最常见的报错是JAVA_HOME路径带引号或结尾多了反斜杠，改成不带引号的纯路径即可。

5.2 端口占用但找不到占用进程

现象：启动报Address already in use: JVM_Bind，但任务管理器里看不到明显的 java 进程。原因：可能是上一次没正常关闭留下的僵尸进程，也可能是别的软件占了 8080。解决：用netstat -ano | findstr :8080找到 PID，再用tasklist | findstr <PID>确认是什么进程，确认是残留的 java 后用taskkill /F /PID <PID>杀掉。注意别误杀系统进程。

5.3 中文乱码，改了 URIEncoding 还是乱

现象：GET 请求中文参数乱码，POST 有时正常有时乱。原因：乱码可能发生在三个环节——浏览器编码、Connector 解码、应用解码。只改URIEncoding只解决 URL 部分，POST body 的解码由应用层控制。解决：确认URIEncoding="UTF-8"已加且重启生效；应用里加一个 CharacterEncodingFilter 强制request.setCharacterEncoding("UTF-8")和response.setCharacterEncoding("UTF-8")；数据库连接串也带上characterEncoding=utf8。三层都对齐才行。

5.4 内存溢出，加了 Xmx 还是 OOM

现象：运行一段时间后报java.lang.OutOfMemoryError: Java heap space或Metaspace。原因：如果是 heap，多半是应用有内存泄漏（比如静态集合只增不减、连接没关）；如果是 Metaspace，是动态生成类太多（频繁热部署、大量 JSP 或反射）。解决：先用jmap -histo:live <PID>看什么对象最多，定位到代码；Metaspace 问题可以适当调大-XX:MaxMetaspaceSize，但根治要减少热部署频率。加-Xmx只是给泄漏争取时间，不是解决。

5.5 改了配置不生效，怀疑人生

现象：改了server.xml或web.xml，重启后行为没变。原因：一是改错了文件（比如改了conf下的但应用用的是WEB-INF下的）；二是work或临时目录有缓存；三是根本没重启成功，旧进程还在。解决：确认改的文件路径正确；停服务后确认进程真的没了（tasklist | findstr java）；删work目录；再启动。养成改配置前先备份、改完看启动日志确认加载了新配置的习惯。

6. 让 7.0.103 跑得更稳：日志切割、连接池与一个验证习惯

老版本 Tomcat 默认的日志策略比较粗放，catalina.out会一直涨，时间长了能把磁盘写满。Windows 下没有 logrotate，我一般用两种办法：一是配logging.properties里的FileHandler做按大小切割，二是写一个计划任务定期归档。改conf/logging.properties：

# conf/logging.properties 关键行 # 限制单个日志文件大小和数量 1catalina.org.apache.juli.FileHandler.limit = 10485760 1catalina.org.apache.juli.FileHandler.count = 10 1catalina.org.apache.juli.FileHandler.formatter = java.util.logging.SimpleFormatter

limit单位字节，这里设 10MB；count是保留文件数，超过就滚动覆盖。这样catalina日志不会无限增长。注意catalina.out是catalina.bat重定向产生的，不受这个配置控制，要单独处理，可以在setenv.bat里把输出重定向到带日期的文件，或者用外部工具切割。

数据库连接池方面，Tomcat 7 自带 DBCP，在context.xml或应用的META-INF/context.xml里配：

<Context> <Resource name="jdbc/myDB" auth="Container" type="javax.sql.DataSource" maxTotal="50" maxIdle="10" minIdle="5" maxWaitMillis="10000" username="dbuser" password="dbpass" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://127.0.0.1:3306/mydb?useUnicode=true&amp;characterEncoding=utf8"/> </Context>

参数说明：maxTotal是最大连接数，别设太大，数据库端也有连接上限；maxWaitMillis是获取连接的最长等待时间，超时抛异常，设太小高峰期容易报错，设太大请求会堆积；minIdle保持最小空闲连接，避免每次新建连接的开销。老项目里连接泄漏很常见，配一个removeAbandoned="true"和removeAbandonedTimeout="300"能兜底回收被遗忘的连接，但这是补救不是根治。

最后说一个我自己的验证习惯：每次改完配置或部署新包，不要只看浏览器首页能不能打开，要跑一遍「启动日志无 ERROR → 关键接口返回正确 → 日志里没有异常栈 → 内存曲线平稳」这四步。老版本 Tomcat 的很多问题不会在首页暴露，而是藏在某个特定请求或运行几小时之后。我吃过亏，曾经一个配置改完首页正常，结果定时任务跑起来才发现连接池不够，半夜报警。从那以后，改完必看日志、必压一下关键路径。希望帮到你。

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