简介这份PDF资料聚焦IDEA导入JavaWeb项目后Tomcat启动正常却返回404错误的排查与解决面向使用IntelliJ IDEA进行Web开发、从Eclipse等其它IDE迁移项目的初中级Java开发者。资源包共1个PDF文件约180KB内容围绕项目配置检查、Tomcat服务器设置、web.xml被清空等典型诱因展开并给出删除多余webapp配置、重新配置web.xml的完整思路。作者结合自身从Eclipse迁移到IDEA的踩坑经历指出IDEA可能自动生成webapp导致WEB-INF下web.xml配置丢失这一关键细节帮助读者快速定位访问路径、项目名与部署结构之间的对应关系。目前已有32442人学习适合遇到同类404问题、需要一份可对照排查的实战参考的开发者收藏查阅。1. IDEA 里 Tomcat 明明起来了为什么浏览器还是 404导入一个 JavaWeb 项目到 IDEATomcat 控制台刷出Server startup in xxx ms日志干干净净结果浏览器一敲地址就是 404。这个场景几乎每个从 Eclipse 或 MyEclipse 转过来的人都会撞一次也是 IDEA 配置 Tomcat 时最高频的翻车点。它要解决的不是「Tomcat 装没装好」而是「IDEA 到底把哪个目录当成了网站根目录、把哪些 class 部署了进去」。适合正在用 IDEA 跑 JavaWeb 项目、Tomcat 能启动但页面打不开、或者换了机器重新导入项目就 404 的开发者。下面按「先判断 404 是谁返回的再逐层定位部署配置」的顺序讲透。2. 先分清 404 是谁返回的Tomcat 还是应用2.1 两种 404 的页面长得不一样很多人一看到 404 就认定是项目没部署上其实 404 有两个来源处理方式完全不同。第一种是 Tomcat 自己返回的 404。页面通常是 Tomcat 默认的报错页白底黑字标题写着HTTP Status 404 – Not Found下面一行Type Status Report再下面Message The requested resource [/xxx] is not available最底下带Apache Tomcat/9.x.x的版本号。看到这个说明请求根本没进到你的应用Tomcat 在它管理的 Context 列表里没找到匹配的路径。第二种是应用框架返回的 404。比如 SpringMVC 返回的 JSON{timestamp:...,status:404,error:Not Found,path:/xxx}或者你项目自定义的错误页。这说明请求已经进了应用是 Controller 映射没匹配上问题在代码或扫描路径不在 Tomcat 部署。判断方法很直接看响应体里有没有 Tomcat 版本号或者用浏览器 F12 看 Response Headers 里有没有Server: Apache-Coyote/1.1。有就是 Tomcat 层的 404没有基本就是应用层的。2.2 用 Context 路径反推部署是否成功Tomcat 层的 404九成是访问路径和实际部署的 Context path 对不上。IDEA 里配置的Application context决定了你访问时要带的前缀。常见做法是打开 IDEA 的 Run/Debug Configurations找到 Tomcat Server 那一项切到 Deployment 标签页看Application context填的是什么。如果填的是/那访问就是http://localhost:8080/你的接口如果填的是/demo那必须写成http://localhost:8080/demo/你的接口。很多人从别处抄配置context 填了项目名访问时却按根路径敲自然 404。还有一个更隐蔽的情况Deployment 标签页里 artifact 那一列如果是红色的或者压根是空的说明 IDEA 根本没往 Tomcat 里放东西Tomcat 起来了但里面是空的访问任何路径都 404。这时候要先去 Project Structure 的 Artifacts 里把 Web Application: Exploded 建出来。提示Tomcat 启动日志里如果出现Deploying web application archive或Deployment of web application directory字样说明至少有一个应用被部署了如果只有Server startup没有任何部署日志基本可以确定 artifact 没配上。3. Artifact 配置IDEA 部署 JavaWeb 的核心机关3.1 Exploded 和 Archive 到底选哪个IDEA 部署 Web 项目靠的是 Artifact它决定了「哪些文件被复制到 Tomcat 的 webapps 或临时目录」。在 Project Structure → Artifacts 里新建时会看到两个选项Web Application: Exploded和Web Application: Archive。Exploded 是目录形式IDEA 把编译输出、Web 资源、依赖 jar 按目录结构拼好Tomcat 直接指向这个目录。它的好处是改 JSP、改静态资源不用重新打包热更新快开发阶段一律选它。Archive 是打成一个 war 包每次改动都要重新 build只适合最终出包。选 Exploded 之后右侧的 Output Layout 里要确认三样东西都在WEB-INF/classes指向你的编译输出目录WEB-INF/lib里放齐所有依赖 jarWeb 资源根目录通常是 web 或 webapp里的 html、jsp、WEB-INF/web.xml 都在。少任何一样都会出问题classes 不在类加载不到报 500 或 ClassNotFoundlib 不全运行时报 NoClassDefFoundErrorweb.xml 不在Servlet 映射全失效。3.2 一个最小可用的 Artifact 配置流程下面这套步骤是我每次新建 JavaWeb 项目都会走一遍的照着做能避开大部分部署坑。第一步确认模块的编译输出。打开 Project Structure → Modules → 选中你的模块 → Sources 标签把src标记成 Sources把资源目录标记成 Resources。再切到 Paths 标签确认Compiler output指向target/classes或out/production/classes这个路径后面 Artifact 要用到。第二步建 Artifact。Project Structure → Artifacts → 加号 → Web Application: Exploded → From Modules。在弹出的对话框里选中你的模块IDEA 会自动生成一个布局。第三步检查布局。展开生成的 Artifact确认output root下有WEB-INF/classes、WEB-INF/lib以及你的 web 根目录内容。如果WEB-INF/lib是空的点右边的加号 → Library Files把项目依赖的库全选进去。第四步绑定到 Tomcat。Run/Debug Configurations → Tomcat Server → Deployment → 加号 → Artifact选中刚建的 Exploded。把Application context设成/方便本地调试。# 部署后可以去 Tomcat 临时目录确认文件到底有没有被放进去 # IDEA 默认用的是系统临时目录下的 tomcat 工作目录 # Windows 一般在 C:\Users\你的用户名\AppData\Local\JetBrains\... # macOS/Linux 在 /private/var/folders 或 /tmp 下 # 找到形如 tomcat.xxxxx 的目录进去看 webapps 里有没有你的应用目录 ls -l /path/to/tomcat.xxxxx/webapps/这段命令的作用是绕过 IDEA 的界面直接看 Tomcat 实际拿到的部署目录里有什么。如果webapps下是空的或者只有一个ROOT而没有你的应用目录那 404 就找到了根因——artifact 没生效。参数上注意不同 IDEA 版本临时目录命名规则不同认准tomcat前缀加随机串的那个目录即可。3.3 web.xml 版本和 Servlet 映射的坑Artifact 配对了还可能因为 web.xml 出问题导致 404。最常见的是web-app标签的 version 和 schemaLocation 不匹配。比如声明了version4.0却引用了 2.5 的 schemaTomcat 解析时可能静默忽略部分配置Servlet 映射就不生效了。!-- web.xml 头部version 和 schema 必须成对 -- web-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd version4.0 servlet servlet-namehello/servlet-name servlet-classcom.demo.HelloServlet/servlet-class /servlet servlet-mapping servlet-namehello/servlet-name url-pattern/hello/url-pattern /servlet-mapping /web-app这段配置里version4.0对应web-app_4_0.xsd两者必须一致。url-pattern决定访问路径上面配的是/hello那访问就是http://localhost:8080/hello。如果用了注解WebServlet(/hello)就不要再在 web.xml 里重复配同一个 url-pattern否则可能冲突。另外注意metadata-completetrue这个属性一旦写上Tomcat 会忽略所有注解只认 web.xml注解写的 Servlet 全部 404。4. 从 404 到 200一套可复用的排查顺序4.1 按层排查别乱改配置遇到 404 最忌讳东改一下西改一下最后连原来能跑的都跑不起来。我一般按固定顺序排查每步都有明确的判断依据。第一层看 Tomcat 启动日志有没有部署记录。没有部署记录直接去查 Artifact 配置别往下看。第二层看访问的 URL 和 Application context 是否匹配。context 是/demo就必须带/demo前缀这一步用浏览器地址栏就能验证。第三层看 web.xml 或注解里的 url-pattern。把访问路径和配置里的 pattern 逐字对比注意大小写和斜杠。第四层看请求有没有进到应用。在 Servlet 的doGet里打一行日志或者用 F12 看响应头有没有应用特有的 header。进了应用还 404就是框架映射问题。第五层看类有没有被编译进去。去 Artifact 的WEB-INF/classes对应目录下找.class文件找不到就是编译输出路径配错了。4.2 用 Tomcat 自带页面验证根路径一个很实用的技巧先把Application context设成/然后访问http://localhost:8080/。如果能看到 Tomcat 的欢迎页或者你项目的首页说明 Tomcat 和部署链路是通的问题只在具体路径上。如果连根路径都 404那基本是 artifact 没部署或者 context 配错了。还可以访问http://localhost:8080/manager/html进 Tomcat 管理页面需要先在tomcat-users.xml里配好角色在应用列表里看你的应用有没有被列出来、Context path 是什么。这是最权威的「Tomcat 眼里你到底部署成了什么」的答案。!-- conf/tomcat-users.xml 里加一个管理角色用于本地排查 -- role rolenamemanager-gui/ user usernameadmin passwordadmin rolesmanager-gui/配好重启 Tomcat用这个账号登录 manager 页面就能看到所有已部署应用的路径和状态。注意这只用于本地排查别把弱密码带到任何对外环境。4.3 依赖没进 lib 导致的连锁 404有一种 404 很迷惑Tomcat 部署日志正常context 也对但一访问就 404同时日志里可能夹着ClassNotFoundException。这往往是依赖 jar 没进WEB-INF/lib导致 Servlet 类加载失败Tomcat 干脆不注册这个 Servlet 的映射表现就是 404。解决办法是在 Artifact 的 Output Layout 里把WEB-INF/lib补全。如果是 Maven 项目更推荐用pom.xml管理依赖然后在 Artifact 里选From Modules让 IDEA 自动收集。检查方法是部署后去临时目录的WEB-INF/lib下数 jar 数量和项目实际依赖对一下。注意Maven 项目里scopeprovided/scope的依赖比如 servlet-api不会被打进 lib这是对的因为 Tomcat 自带但如果你把业务依赖也标成了 provided就会运行时找不到类。5. 避坑与常见问题排查5.1 现象Tomcat 启动成功访问任何路径都 404原因Artifact 没绑定到 Tomcat或者 Deployment 里 artifact 是空的。Tomcat 起来了但里面没部署任何应用。解决Run/Debug Configurations → Deployment → 确认有 artifact 且不是红色。没有就点加号添加红色就回 Project Structure 重新构建 Artifact。5.2 现象访问根路径正常访问具体接口 404原因Application context 配了前缀但访问时没带或者 url-pattern 和实际访问路径不一致。解决对照 Deployment 里的 context 和 web.xml/注解里的 pattern逐字核对访问 URL。context 是/demo就老老实实带上。5.3 现象改了代码重新运行还是旧的 404 或旧页面原因IDEA 没有重新编译或者 Tomcat 用的是缓存的旧 artifact。热部署没生效。解决Build → Rebuild Project然后在 Tomcat 配置的 Server 标签里确认On Update action设成了Update classes and resources。实在不行就删掉临时 tomcat 工作目录重启。5.4 现象注解写的 Servlet 完全不生效web.xml 里的却正常原因web.xml 里写了metadata-completetrueTomcat 忽略所有注解。解决把这个属性删掉或改成false让 Tomcat 扫描注解。或者干脆统一用注解web.xml 只留版本声明。5.5 现象Maven 项目导入后WEB-INF/lib 里没有依赖 jar原因Artifact 的 Output Layout 没包含 Maven 依赖或者模块没被识别成 Maven 模块。解决右键pom.xml→ Add as Maven Project然后在 Artifact 布局里点加号 → Library Files 全选依赖或者用From Modules重新生成。6. 让 404 不再复发的两个习惯第一个习惯是固定一套「新建项目检查清单」。我每次导入或新建 JavaWeb 项目都会按顺序确认四件事模块的 Sources 和输出路径对不对、Artifact 是不是 Exploded 且布局完整、Tomcat Deployment 里 artifact 绑没绑、Application context 设成了什么。这四步走完404 基本不会出现。这套清单比任何教程都管用因为它把「IDEA 的配置」和「Tomcat 的实际行为」对应起来了。第二个习惯是学会看 Tomcat 的临时工作目录。IDEA 跑 Tomcat 时不会真的用你下载的那个 Tomcat 的 webapps 目录而是在系统临时目录下建一个tomcat.xxxxx的工作目录把 artifact 复制进去再启动。所以「你项目里有什么」和「Tomcat 实际拿到什么」可能不一致。养成去那个目录ls一下的习惯很多玄学问题一眼就能看穿。# 快速定位 IDEA 的 Tomcat 临时工作目录macOS/Linux find /private/var/folders /tmp -maxdepth 3 -type d -name tomcat.* 2/dev/null # Windows 用 PowerShell # Get-ChildItem $env:TEMP -Directory -Filter tomcat.*这个查找命令能帮你直接跳到 Tomcat 真正的工作目录进去看webapps和conf里的实际内容。参数上-maxdepth 3是防止全盘扫描太慢2/dev/null是屏蔽权限报错。找到目录后重点看webapps下有没有你的应用、conf/server.xml里的 Context 配置是什么。最后一个技巧是关于验证的在项目里放一个最简单的静态index.html在 web 根目录部署后先访问它。静态文件能打开说明部署链路通了问题在 Servlet 映射静态文件也 404问题在 artifact 或 context。这个二分法能帮你快速缩小范围比盲目改配置高效得多。我自己在这上面栽过最惨的一次是花了一下午改 web.xml 和注解最后发现只是 Deployment 里 artifact 那一栏是空的。从那以后我养成了一个习惯任何 404先看 Tomcat 启动日志有没有部署记录没有就直接查 artifact绝不先动代码。希望帮到你。本文还有配套的精品资源点击获取