把一个跑得好好的 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这类字样。把常见组合整理成一张表对照着选就不容易出错组件推荐版本最低 JDK 要求说明Tomcat 8.58.5.xJDK 7老项目兼容首选javax命名空间Tomcat 99.0.xJDK 8目前最稳的过渡选择javax命名空间Tomcat 10.110.1.xJDK 11jakarta命名空间配 Spring Boot 3.xTomcat 1111.xJDK 17最新规范新项目尝鲜用IDEA2021.3 及以上视项目而定太老的版本对高版本 Tomcat 支持不全判断标准其实很简单**看项目依赖里的 Servlet API 是javax还是jakarta。**如果是 Spring Boot 项目看主版本号——Boot 2.x 配 Tomcat 9Boot 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 Installerexe会把 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管管理页面的账号。libTomcat 自身的依赖 jar。注意这里的 jar 对 Web 应用是可见但不可打包的也就是说你的项目能用它但打 war 的时候不应该把它塞进去否则和服务器自带的版本冲突。logs日志输出目录。命令行启动时日志在这里IDEA 启动时日志默认打在控制台但某些内部日志还是会写到这里。排查启动失败时这里是第一现场。webapps默认的应用部署目录。往这里扔一个 war 包Tomcat 会自动解压部署。但 IDEA 的部署机制不一样它是通过配置把编译产物挂载进去不一定真的复制到这里后面会细说。temp临时目录Tomcat 运行时的中间文件。启动异常时清空这个目录有时候能解决奇怪的问题。workJSP 编译后的字节码存放处。改了 JSP 不生效、或者 JSP 报了莫名其妙的行号错误时把 work 目录清空再重启这是实战中非常好用的一招。2.3 落地前的三个预检动作在 IDEA 里配置之前先自己做三个检查能把问题提前挡掉第一端口占用检查。Tomcat 默认用 8080 作为 HTTP 端口8005 作为关闭端口8009 作为 AJP 端口。8080 是最容易被占用很多开发机上装了别的服务或者之前启动的 Tomcat 没关干净还在后台挂着。Windows 下执行netstat -ano | findstr :8080Linux 或 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 StructureCtrlAltShiftS的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 portJava 管理扩展端口用于监控 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 resourcesOn frame deactivation选Update classes and resources这两个选项的区别在于触发时机。On Update action是你手动按CtrlF10或点那个更新按钮时触发On frame deactivation是IDEA 窗口失去焦点时自动触发比如你 AltTab 切到浏览器它就会自己更新一次。选Update classes and resources的含义是重新编译改动的 Java 类并替换到运行中的容器里同时同步 Web 资源文件JSP、HTML、CSS 等。这样改 Java 方法和改页面样式都能生效不用重启。但这里有几个现实中的限制必须说清楚否则你会觉得热部署“时灵时不灵”**第一改方法签名、加新方法、改字段类型这类结构性改动热部署无效。**JVM 的类重定义机制对类结构变化是有限制的新增方法、修改方法签名这些操作无法在线替换必须重启。表现出来就是你改了代码CtrlF10之后访问发现行为没变或者报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 explodedwar物理形态目录形式散开的文件单个压缩包文件部署速度快直接挂载慢需要解压支持热部署支持不支持适合场景本地开发调试服务器上线部署修改资源文件直接替换即可生效需要重新打包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 error2。原因基本是 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说明缺 jarNullPointerException说明某个对象没初始化FileNotFoundException说明配置文件路径不对。别被一大片红色吓到重点就那么几行。中文乱码分三种情况要对症下药。第一种页面上的中文变成问号或方块。这是响应编码问题在 JSP 顶部加% page contentTypetext/html;charsetUTF-8 %或者在 Servlet 里设置response.setContentType(text/html;charsetUTF-8)。第二种控制台日志里的中文乱码。改conf/logging.properties把java.util.logging.ConsoleHandler.encoding设成 UTF-8。如果是在 IDEA 里看日志乱码还要在运行配置的 VM options 里加-Dfile.encodingUTF-8。第三种表单提交的中文在后台接收时乱码。这是请求体编码问题Tomcat 8.5 之后URIEncoding默认就是 UTF-8 了但 POST 请求体的编码还是要靠request.setCharacterEncoding(UTF-8)来处理而且这行代码必须在读取任何参数之前调用否则不生效。这个顺序问题坑过很多人代码明明写了但还是乱码就是因为在它之前先调用了getParameter。5.3 一份排查速查表把上面这些整理成表遇到问题按行对照能省不少时间现象最可能的原因优先检查的地方找不到 Tomcat Server 选项用了社区版换 Smart Tomcat 插件或升级版本启动超时中断默认超时太短Server 标签页的 Startup timeout端口被占用8080 被其他进程占命令行查端口改配置端口访问根路径 404context path 不是/Deployment 标签页的 Application context具体路径也 404资源路径或欢迎页配置web.xml 欢迎页、静态资源引用ClassNotFoundException依赖没进 ArtifactArtifacts 面板检查 WEB-INF/lib改代码不生效热部署配置没开On Update action 设置改了类结构不生效JVM 类重定义限制只能重启别无他法JSP 改动不生效work 目录缓存清空 Tomcat 的 work 目录中文乱码编码设置不一致页面声明、VM options、logging.properties除了这些还有两个我自己的经验值得单独说。一个是善用Run窗口的红色停止按钮旁边的“重新部署”。有些问题重启 Tomcat 就解决了但如果你只是点停止再点启动有时候旧的类加载器还挂着。真正的“重启”应该点那个带刷新箭头的按钮Redeploy它会先卸载再重新部署清得比较干净。另一个是日志级别调整。Tomcat 的conf/logging.properties默认级别比较高很多时候看不到详细的调试信息。排查疑难问题时可以把对应 Logger 的级别临调到FINE能看到更细的内部流程。但别长期开着日志量会爆炸磁盘和性能都吃不消问题解决就调回去。最后补一句我的心气话。IDEA 配 Tomcat 这件事第一次做确实有点绕因为它不像 Eclipse 那样“所见即所得”Artifact 和 Application context 这两层抽象需要花点时间建立直觉。但只要完整走通一遍把每个配置项和它的作用对应起来后面换项目、换版本、加模块都不会再卡。我自己的做法是维护一份自己的配置清单装新机器的时候照着走一遍十分钟就能把开发环境搭起来比到处翻记忆靠谱得多。
