IDEA 配置 Tomcat 实战：Artifact、热部署与 404 排查

把一个跑得好好的 Web 项目塞进 IDEA 里，然后用本地的 Tomcat 一键启动、断点调试、改完代码浏览器刷新就生效——这套流程听起来平平无奇，但真正第一次动手的人，十个里有六七个会卡在“找不到 Tomcat Server 选项”“Artifact 是空的”“启动起来了访问 404”“控制台一片红”这些地方。我自己带过的新人里，有人在这上面耗掉整整一个下午，最后发现只是 IDEA 装的是社区版。所以这篇东西不打算走“点这里、点那里”的流水账路线，而是把 IDEA 配置 Tomcat 这件事拆成三层：第一层是版本与环境的匹配关系，这一层错了后面全白搭；第二层是 IDEA 内部模型的理解，也就是 Artifact、Application context、Application Server 这几个概念到底在干什么；第三层才是具体的操作步骤和排错。适合刚接触 Java Web 的同学，也适合从 Eclipse 迁过来、对 IDEA 的运行配置逻辑还不太顺手的老手——两边工具的思路差别不小，Eclipse 是“我给服务器加项目”，IDEA 是“我给项目造一个运行配置”，这个心智模型转不过来就会一直别扭。

我会把每一个关键选择背后的理由讲清楚，包括端口怎么算、路径为什么不能带中文、war 和 war exploded 差在哪、热部署为什么时灵时不灵。同时会附上我自己踩过的坑和一套排查顺序，遇到问题可以直接照着查，不用到处翻帖子。

1. 动手之前：先把版本关系和运行环境捋顺

配置失败的人里，超过一半不是操作错了，而是环境本身就不成立。比如拿着 Tomcat 10 去跑一个老项目，或者 IDEA 装的是社区版却一直在找 Tomcat 配置入口。这一节先把这些前置条件讲透，能省掉后面大量的无效折腾。

1.1 Ultimate 和 Community 这两条路，选错就白折腾

这是最容易被忽略、也最致命的一点：**IntelliJ IDEA 的 Community（社区版）从设计上就没有内置的 Tomcat 集成。**它没有 Java EE / Jakarta EE 相关的支持模块，所以你在 Run/Debug Configurations 里点加号，是找不到 Tomcat Server 这一项的。很多人打开面板翻了三遍，怀疑自己眼睛出了问题，其实是版本限制。

那社区版是不是就完全不能用 Tomcat？也不是，有两条替代路线。一条是用 Smart Tomcat 这个第三方插件，在 Settings 的 Plugins 里搜一下就能装，它会在运行配置里加一个 Smart Tomcat 的选项，指定 Tomcat 目录、webapp 目录和 context path 就能跑，功能上满足基本的启动和调试需求。另一条是干脆绕开外部 Tomcat，直接用 Maven 或 Gradle 插件启动，比如用cargo-maven3-plugin或者干脆把项目改成 Spring Boot 的嵌入式方式跑。插件方案的缺点是热部署支持不如官方集成顺滑，某些深度调试场景会有小毛病，但对学习和日常开发完全够用。

Ultimate（旗舰版）则原生支持，配置界面完整，和 Artifact、Facet、热部署这些机制联动得比较好。如果你是在校学生或者做开源项目，可以留意官方的免费授权渠道，能合法拿到 Ultimate 的使用资格。这里我不展开讲授权细节，只提醒一句：别去碰来路不明的激活手段，很多所谓的工具包里塞了别的东西，为省这点钱把开发机搞脏不值得，装个社区版加插件照样干活。

1.2 JDK、Tomcat、IDEA 三者的版本对应关系

版本错配是第二大杀手。核心矛盾在 Servlet 规范的包名变更上：Tomcat 10 开始，Servlet API 的包名从javax.servlet.*改成了jakarta.servlet.*，这是一次彻底的命名空间迁移，不是简单改个名字。后果就是，一个用javax.servlet编译的老项目，扔到 Tomcat 10 上跑，启动时就会报 ClassNotFoundException 或者 NoClassDefFoundError，错误信息里带着javax/servlet/http/HttpServlet这类字样。

把常见组合整理成一张表，对照着选就不容易出错：

判断标准其实很简单：**看项目依赖里的 Servlet API 是javax还是jakarta。**如果是 Spring Boot 项目，看主版本号——Boot 2.x 配 Tomcat 9，Boot 3.x 配 Tomcat 10.1 以上。我见过有人拿 Tomcat 10 去跑 Boot 2.7 的项目，折腾半天以为是 IDEA 配置问题，其实换成 Tomcat 9 立刻就通了。

另外 IDEA 本身也有版本要求。太老的 IDEA（比如 2018 之前的）在识别 Tomcat 10 的目录结构时可能出问题，因为 Tomcat 10 的内部 jar 组织方式和以前有差异。建议用近两年内的版本，如果版本确实很旧，优先升级 IDEA 而不是降级 Tomcat，因为新版工具对老服务器的兼容性通常更好。

1.3 环境变量到底要不要配

网上大量教程一上来就让你配CATALINA_HOME和JAVA_HOME，其实这里有个认知偏差需要纠正：**在 IDEA 里配置 Tomcat，并不依赖系统级的环境变量。**IDEA 的运行配置里会明确指定两件事——Application server 指向哪个 Tomcat 目录，以及用哪个 JRE 来跑。它会自己读取指定目录下的bin、conf、lib，不关心你系统变量里写了什么。

那为什么还有那么多人强调配环境变量？因为那是脱离 IDEA、在命令行直接启动 Tomcat 时必需的。另外有些构建脚本、Maven 插件会读取CATALINA_HOME，所以配了没坏处。我的建议是：如果你打算同时用命令行做验证和排错，那就配上；如果全程在 IDEA 里点按钮，可以先跳过，等真需要了再补。

配的话记住两点：JAVA_HOME指向 JDK 的安装根目录（不是bin目录，不是jre目录），CATALINA_HOME指向 Tomcat 解压后的根目录。Windows 下改完系统变量记得重开一个终端窗口，老窗口读的还是旧值，这一点经常让人误以为配置没生效。

2. Tomcat 的下载、解压与目录预检

环境版本理清楚之后，就是拿到 Tomcat 本体。这一步没什么技术含量，但有几个细节如果一开始不注意，后面会反复出问题。尤其是安装包类型的选择和落地路径，属于“五分钟决定后面两小时”的事情。

2.1 安装包类型怎么选，别下错了

Tomcat 的发行包大致有这么几类：

• zip 压缩包（Windows）：解压即用，最推荐。不写注册表，删掉就是卸载干净，也方便同时留着好几个版本做对比测试。
• tar.gz 压缩包（Linux / macOS）：服务器上部署的标准形态，本地 macOS 开发也建议用这个。
• Windows Service Installer（exe）：会把 Tomcat 注册成系统服务，开机自启。不推荐在做 IDEA 本地开发时用，因为它会把配置写进注册表和系统目录，多个版本共存时容易打架，卸载也不干净。
• 32 位 / 64 位：现在基本都是 64 位了，除非你的机器特别老。选错了会因为指针宽度的差异启动失败或者性能异常。

下载完之后解压路径这条特别关键：绝对不要放在带中文、空格或者特殊字符的目录里。像D:\我的项目\tomcat 9\这种路径，IDEA 在拼接启动命令时可能因为引号处理不当中断，报出“Cannot find bin\catalina.bat”之类的错，或者那个空格的路径被拆成两段参数。路径里还可能出现乱码导致读取不到配置文件。老老实实放到D:\dev\tomcat9或者C:\tools\apache-tomcat-9.0.85这种纯英文、无空格的位置，能规避掉一大堆玄学问题。

2.2 目录结构拆解，知道每个文件夹在干什么

解压完打开目录，你会看到一堆文件夹。不熟悉的话遇到问题根本不知道去哪找配置，所以这里逐个说清楚：

• bin：可执行脚本目录。startup.bat/startup.sh是启动脚本，shutdown是停止脚本，catalina.bat/catalina.sh是底层的主力脚本，IDEA 实际上调用的就是 catalina 脚本而不是 startup。JVM 参数也是在这一层注入的。
• conf：配置文件目录。server.xml管端口和连接器，改端口就是改这里；web.xml是全局的部署描述符，可以配默认欢迎页、Session 超时；logging.properties管日志输出格式和编码，中文乱码经常要动它；tomcat-users.xml管管理页面的账号。
• lib：Tomcat 自身的依赖 jar。注意这里的 jar 对 Web 应用是可见但不可打包的，也就是说你的项目能用它，但打 war 的时候不应该把它塞进去，否则和服务器自带的版本冲突。
• logs：日志输出目录。命令行启动时日志在这里，IDEA 启动时日志默认打在控制台，但某些内部日志还是会写到这里。排查启动失败时这里是第一现场。
• webapps：默认的应用部署目录。往这里扔一个 war 包，Tomcat 会自动解压部署。但 IDEA 的部署机制不一样，它是通过配置把编译产物挂载进去，不一定真的复制到这里，后面会细说。
• temp：临时目录，Tomcat 运行时的中间文件。启动异常时清空这个目录有时候能解决奇怪的问题。
• work：JSP 编译后的字节码存放处。改了 JSP 不生效、或者 JSP 报了莫名其妙的行号错误时，把 work 目录清空再重启，这是实战中非常好用的一招。

2.3 落地前的三个预检动作

在 IDEA 里配置之前，先自己做三个检查，能把问题提前挡掉：

第一，端口占用检查。Tomcat 默认用 8080 作为 HTTP 端口，8005 作为关闭端口，8009 作为 AJP 端口。8080 是最容易被占用，很多开发机上装了别的服务，或者之前启动的 Tomcat 没关干净还在后台挂着。Windows 下执行netstat -ano | findstr :8080，Linux 或 macOS 下执行lsof -i:8080，有输出就说明被占了。找到后面的进程号，能结束就结束，不能结束就在conf/server.xml里把 Connector 的 port 改成 8081 之类的空闲端口。

第二，独立启动验证一次。在配置 IDEA 之前，先手动双击bin/startup.bat启动一次，浏览器访问http://localhost:8080，看到那只猫的默认页面就说明 Tomcat 本体没问题。这一步的价值在于把问题域隔离开——如果手动启动都失败，那问题在 Tomcat 或者 JDK，跟 IDEA 一点关系没有，就不用去 IDEA 里瞎找了。

第三，确认JAVA_HOME可用。命令行里敲java -version和echo %JAVA_HOME%（Linux 用echo $JAVA_HOME），确认输出的是你期望的 JDK 版本。如果 Tomcat 启动时闪退、日志里出现“Neither the JAVA_HOME nor the JRE_HOME environment variable is defined”这类提示，就是这里的问题。IDEA 配置里虽然能独立指定 JRE，但某些场景下 catalina 脚本仍会去读环境变量，两头保持一致最省心。

3. IDEA 里从头配置一个 Tomcat 运行实例

这一节是主体部分。我按真实操作顺序来，每一步都说明“为什么点这里”，而不是单纯列步骤。因为 IDEA 的配置项一旦理解了它的设计意图，后面遇到变体就不会慌。

3.1 建立项目并让 Artifact 正确生成

IDEA 的部署模型和 Eclipse 不一样。Eclipse 是“服务器是个大容器，我把项目塞进去”，IDEA 是“项目编译产出一个叫 Artifact 的东西，然后把这个 Artifact 挂到服务器上跑”。所以先有 Artifact，才能配部署，这个顺序不能颠倒。

怎么让 Artifact 出来？两种情况：

如果是 Web 项目，在Project Structure（Ctrl+Alt+Shift+S）的Facets里应该能看到一个 Web Facet，它指定了web.xml的位置和 Web 资源根目录（通常是src/main/webapp）。如果 Facets 里没有，说明 IDEA 没把这个模块识别成 Web 模块，需要在Modules里给模块添加 Web Facet，或者在创建项目时就选择正确的模板。

有了 Web Facet 之后，去Artifacts标签页，点加号，选Web Application: Exploded，再从模块导入。这时你会看到一个结构，里面包含编译输出目录（classes）和 Web 资源目录（webapp下的内容）。这个默认生成的 Artifact 对绝大多数场景就够用了，不需要手动折腾。

这里有个很常见的坑：Maven 项目如果在pom.xml里把 packaging 设成了war，但没有正确配置maven-war-plugin，或者依赖的 scope 用错了，Artifact 的WEB-INF/lib里可能是空的。表现出来就是启动不报错，一访问就 ClassNotFoundException。解决办法是在Artifacts面板里展开WEB-INF/lib，确认你项目依赖的第三方 jar 都在里面。如果是 Maven 项目，通常 IDEA 会自动同步，但手动改过 pom 之后需要点一下 Maven 面板的刷新，让 IDEA 重新拉取依赖关系。

还有一个细节：编译输出路径。在Project Structure的Project标签页里能看到Project compiler output，默认是项目下的out目录或者 Maven 的target/classes。如果这个路径和你预期的不一样，会导致 Artifact 里挂载的 class 文件是旧的，改了代码不生效。这个后面讲热部署的时候还会遇到。

3.2 把本地 Tomcat 登记到 Application Servers

点Run菜单下的Edit Configurations，或者直接点工具栏的配置下拉框。在左侧点加号，展开Tomcat Server，选Local。

注意：如果你只看到Remote而没有Local，基本可以确认你用的是社区版，回到第 1.1 节看替代方案。

新建之后先改个名字，比如叫Tomcat9-Dev，方便区分不同环境。然后在Server标签页里找Application server这一项，点右边的Configure...，在弹出的窗口里把Tomcat Home指向你解压的 Tomcat 根目录。IDEA 会自动识别出版本号显示在旁边，如果识别不出来，多半是目录选错了——要选的是根目录，不是bin目录。

登记好之后，IDEA 会把这个服务器记录到全局配置里，以后新建别的运行配置可以直接从下拉里选，不用再指路径。这个全局登记的地方在Settings→Build, Execution, Deployment→Application Servers，如果哪天路径变了、Tomcat 换位置了，要去这里改，光改运行配置里的有时候不生效。

如果是 Maven 多模块项目，还要留意Use classpath of module这一项。它决定了运行时用哪个模块的类路径。选错了会出现“明明代码里有这个方法，运行时报 NoSuchMethodError”，因为加载的是另一个模块的旧版本 class。多模块项目里这个坑相当常见，尤其是几个模块都依赖同一个工具类的时候。

3.3 Server 选项卡里那几个参数的真实含义

Server标签页看起来项很多，其实真正需要动的就那么几个，剩下的保持默认就好。逐项说一下：

HTTP port：这是 Tomcat 对外提供 Web 服务的端口，默认 8080。前面预检查如果发现 8080 被占，这里改成 8081 即可。注意这个改动只影响 IDEA 启动的这个实例，不会写回conf/server.xml，所以你在 IDEA 里改了端口，手动启动 Tomcat 时还是 8080，两边不一致是正常现象，别搞混。

JMX port：Java 管理扩展端口，用于监控 Tomcat 内部状态。本地开发基本用不到，保持默认的 1099 就行。如果这个端口被占，IDEA 会提示你改，也会影响启动。

JRE：选择运行用的 Java 运行环境。这里有个点值得说：它可以和JAVA_HOME指向的 JDK 不一样。如果你想测试项目在特定 JDK 版本下的表现，可以在这里单独指定。选的时候注意，如果项目是 JDK 8 编译的，但 JRE 选了 JDK 17，可能因为模块化或者反射限制报错，这就是所谓的“跨版本运行问题”。保险起见，JRE 版本和项目编译版本保持一致。

On 'Update' action和On frame deactivation：这两个是热部署的核心配置，下一节单独展开讲。

Startup / Connection：这里有启动和停止的超时时间，默认通常是 45 秒。大项目启动慢的时候，这个超时经常不够用，控制台会打印“Artifact is not deployed”或者干脆启动中断。把Start script那个 timeout 从 45 改到 120 甚至更大，是解决“启动莫名其妙失败”的一个高频手段。改完记得点 Apply。

还有个Deploy applications configured in Tomcat instance的勾选项，意思是让 IDEA 去加载 Tomcat 自己webapps目录下已有的应用。本地开发建议不勾，避免服务器自带的示例应用和你的项目混在一起互相干扰，启动也会快一些。

3.4 Deployment 选项卡：Artifact 和访问路径的关系

切到Deployment标签页，点右边的加号，选Artifact，把刚才那个war exploded加进来。加进来之后右侧会显示一个Application context，默认可能是/项目名_war_exploded这种带后缀的形式。

**这个 Application context 就是你访问时的路径前缀，它和端口拼起来才是完整 URL。**如果 context 是/demo_war_exploded，那访问地址就是http://localhost:8080/demo_war_exploded/，直接访问http://localhost:8080/会看到 404，很多新手就是被这个坑到的，以为自己部署失败了，其实只是路径没写对。

想要访问根路径http://localhost:8080/就能打开项目，把 Application context 改成单个斜杠/就行。不过要注意，一个 Tomcat 实例里只能有一个应用占据根路径，如果你同时配了两个运行实例，第二个也想用/就会冲突。

Deployment面板下面还有个Deploy at the server startup的列表，可以调整部署顺序。多应用场景下，如果应用之间有依赖关系（比如一个要先启动提供基础服务），这个顺序要手动排。

另外，Artifact类型有两种可选：war exploded和war。开发阶段一律选 exploded，原因下一节会详细对比。

4. 启动验证、热部署与打包上线

配置完成之后就是启动和验证。但“能启动”和“开发体验顺畅”是两回事，真正的效率差距在热部署这一块。改一行代码要重启一次容器，一天下来光是等重启就能耗掉一两个小时，这个成本必须想办法压下去。

4.1 首次启动日志怎么看

点绿色三角启动，IDEA 下面会弹出运行窗口。日志是分几段的，每一段透露的信息不同。

开头几行是 JVM 参数和类路径信息，这部分内容很长，正常情况可以忽略。接着会出现 Tomcat 版本信息、CATALINA_BASE和CATALINA_HOME的路径——这两个路径要扫一眼，确认指向的是你期望的 Tomcat 目录，如果指到了别的地方，说明 Application Server 配错了。

然后是各种 Listener 和 Filter 的初始化日志，Spring 项目在这里会打印 Bean 加载信息。这一段如果报错，通常是依赖问题或者配置文件问题，不是 Tomcat 本身的锅。

最后是最关键的一行：类似Server startup in [1234] milliseconds，看到它就说明容器启动成功了。如果没看到这一行，或者控制台停在某处不动然后超时，那就是启动失败，往上翻日志找第一个出现的SEVERE或Exception，第一个错误往往才是根因，后面的一堆报错都是连锁反应。

启动成功后，浏览器访问对应的 URL。建议用 IDEA 配置里那个可以直接点击的链接，它会自动带上正确的 context path，避免自己拼错。第一次访问如果 404，先确认 URL 里有没有带 context path，再确认web.xml里有没有配欢迎页，或者项目根目录下有没有index.jsp/index.html这类默认文件。

4.2 改代码不重启：热部署的正确配法

回到Server标签页，把两个下拉框都设置一下：

• On 'Update' action：选Update classes and resources
• On frame deactivation：选Update classes and resources

这两个选项的区别在于触发时机。On 'Update' action是你手动按Ctrl+F10（或点那个更新按钮）时触发；On frame deactivation是IDEA 窗口失去焦点时自动触发，比如你 Alt+Tab 切到浏览器，它就会自己更新一次。

选Update classes and resources的含义是：重新编译改动的 Java 类并替换到运行中的容器里，同时同步 Web 资源文件（JSP、HTML、CSS 等）。这样改 Java 方法和改页面样式都能生效，不用重启。

但这里有几个现实中的限制，必须说清楚，否则你会觉得热部署“时灵时不灵”：

**第一，改方法签名、加新方法、改字段类型这类结构性改动，热部署无效。**JVM 的类重定义机制对类结构变化是有限制的，新增方法、修改方法签名这些操作无法在线替换，必须重启。表现出来就是你改了代码，Ctrl+F10之后访问发现行为没变，或者报NoSuchMethodError。这种情况老老实实重启，别硬刚。

**第二，JSP 改动通常没问题，但偶尔会缓存。**如果改了 JSP 不生效，去把 Tomcat 的work目录清空再试。IDEA 内部也有缓存，File→Invalidate Caches可以清一下，不过这个操作比较重，会重建索引，慎用。

第三，On frame deactivation用起来爽，但有代价。每次切窗口都触发一次编译和同步，项目大的时候会有明显卡顿，尤其是你频繁在 IDEA 和浏览器之间来回切的时候。我个人的习惯是只配On 'Update' action，需要更新的时候手动按一下，节奏可控，也不会因为误触切窗口导致不必要的编译。

**第四，浏览器记得关缓存。**开发时把浏览器开发者工具打开，勾上Disable cache，否则你看到的是浏览器缓存的旧页面，会误以为是热部署没生效。这个坑我踩过不止一次，排查半天最后发现是浏览器缓存。

4.3 war 和 war exploded 到底差在哪

这两个词在 Deployment 配置里反复出现，很多人选的时候是凭感觉。实际区别是这样的：

war exploded本质上是把 Artifact 的目录结构直接挂到 Tomcat 上，容器读的就是你编译输出目录里的文件，所以改了立刻能反映出来。war则是先打成一个完整的压缩包，再交给容器解压部署，中间多了一道工序，热部署自然就断了。

所以结论很明确：**开发阶段用 exploded，交付上线用 war。**打包的时候在 Maven 里执行mvn clean package，或者在 IDEA 的 Maven 面板双击package生命周期，产物在target目录下。如果你在 IDEA 里也想验证 war 包的部署效果，可以额外建一个运行配置，Deployment 里选 war 类型，但那个配置只用来做最终验证，日常开发别用它。

顺带说一个打包相关的坑：**依赖 scope 用错会导致 war 包体积异常或者运行时缺 jar。**像servlet-api、jsp-api这些，Tomcat 自带，项目里应该用provided而不是compile，否则打进去会和服务器的版本冲突，出现LinkageError或者方法找不到的诡异问题。同理，tomcat-embed-*系列的包如果出现在一个非 Spring Boot 项目里，也要检查一下是不是引入错了。

5. 报错排查速查与踩坑复盘

配置过程顺利的话，到这基本就结束了。但现实是，出错的概率不低。我把这些年遇到的高频问题按“启动类”和“访问类”分开整理，配上排查思路，遇到问题可以对照着查。

5.1 启动阶段就挂掉：几类典型症状

症状一：控制台提示端口被占用，Address already in use: bind。

这是最常见的。8080 被别的进程占了，可能是上一个没关干净的 Tomcat，也可能是其他软件。Windows 下用netstat -ano | findstr :8080找到 PID，然后在任务管理器里结束对应进程；Linux 下lsof -i:8080拿到 PID 后kill -9（注意确认这个进程确实该杀，别误伤）。懒得处理的话直接把 IDEA 里的 HTTP port 改成 8081。

症状二：启动卡住，最后提示超时。

前面提过，去Server标签页把Startup / Connection里的 timeout 调大。另外要看是不是项目本身启动就慢——比如 Spring 项目在扫包阶段耗时过长，或者数据库连接池在等一个连不上的数据库。日志停在连接数据库那一步的话，问题在数据库不在 Tomcat，别往容器方向查。

症状三：提示找不到 catalina 脚本。

错误信息里通常带Cannot find bin\catalina.bat或Cannot run program ... CreateProcess error=2。原因基本是 Application server 路径配错了，或者 Tomcat 目录不完整（下载中断导致文件缺失）。重新指定路径，或者重新解压一份干净的 Tomcat。

症状四：控制台正常的启动日志走完了，但立刻又打印停止日志。

这种“启动即停止”的情况，多半是conf/server.xml里的配置有问题，比如端口冲突导致 Connector 初始化失败。日志里往前翻，找带SEVERE的那几行，通常会有明确提示。

5.2 启动成功但访问异常：404、500 和乱码

404 是最多的，而且九成不是部署失败。

第一步先看 URL。http://localhost:8080/项目名和http://localhost:8080/是两个不同的地址，前者需要 context path，后者对应根路径部署。回头确认 Application context 的配置，和你访问的地址对不对得上。

如果 context 是对的还 404，检查欢迎页。web.xml里的<welcome-file-list>配了哪些文件，项目里是不是真的存在这些文件。或者干脆访问一个具体的路径，比如http://localhost:8080/项目名/hello，绕过欢迎页直接测。如果具体路径能通，说明就是欢迎页配置的问题。

还有一种 404 是静态资源路径问题。比如 CSS 引用写的是绝对路径/css/style.css，在 context 不是根路径的情况下就会 404，因为浏览器会去http://localhost:8080/css/style.css找，而不是带 context 的路径。这种要在 JSP 里用${pageContext.request.contextPath}拼前缀，或者在配置里把 context 设成/。

500 错误看堆栈。

500 是服务器内部错误，控制台或者日志里一定有完整的异常堆栈。从最上面的Caused by开始看，那通常才是真正的根因，下面的几层是包装。比如ClassNotFoundException说明缺 jar，NullPointerException说明某个对象没初始化，FileNotFoundException说明配置文件路径不对。别被一大片红色吓到，重点就那么几行。

中文乱码分三种情况，要对症下药。

第一种，页面上的中文变成问号或方块。这是响应编码问题，在 JSP 顶部加<%@ page contentType="text/html;charset=UTF-8" %>，或者在 Servlet 里设置response.setContentType("text/html;charset=UTF-8")。

第二种，控制台日志里的中文乱码。改conf/logging.properties，把java.util.logging.ConsoleHandler.encoding设成 UTF-8。如果是在 IDEA 里看日志乱码，还要在运行配置的 VM options 里加-Dfile.encoding=UTF-8。

第三种，表单提交的中文在后台接收时乱码。这是请求体编码问题，Tomcat 8.5 之后URIEncoding默认就是 UTF-8 了，但 POST 请求体的编码还是要靠request.setCharacterEncoding("UTF-8")来处理，而且这行代码必须在读取任何参数之前调用，否则不生效。这个顺序问题坑过很多人，代码明明写了但还是乱码，就是因为在它之前先调用了getParameter。

5.3 一份排查速查表

把上面这些整理成表，遇到问题按行对照，能省不少时间：

除了这些，还有两个我自己的经验值得单独说。

一个是善用Run窗口的红色停止按钮旁边的“重新部署”。有些问题重启 Tomcat 就解决了，但如果你只是点停止再点启动，有时候旧的类加载器还挂着。真正的“重启”应该点那个带刷新箭头的按钮（Redeploy），它会先卸载再重新部署，清得比较干净。

另一个是日志级别调整。Tomcat 的conf/logging.properties默认级别比较高，很多时候看不到详细的调试信息。排查疑难问题时，可以把对应 Logger 的级别临调到FINE，能看到更细的内部流程。但别长期开着，日志量会爆炸，磁盘和性能都吃不消，问题解决就调回去。

最后补一句我的心气话。IDEA 配 Tomcat 这件事，第一次做确实有点绕，因为它不像 Eclipse 那样“所见即所得”，Artifact 和 Application context 这两层抽象需要花点时间建立直觉。但只要完整走通一遍，把每个配置项和它的作用对应起来，后面换项目、换版本、加模块都不会再卡。我自己的做法是维护一份自己的配置清单，装新机器的时候照着走一遍，十分钟就能把开发环境搭起来，比到处翻记忆靠谱得多。