IntelliJ IDEA 打包 Web 项目 WAR 包(含 Tomcat 部署+常见问题解决)

IntelliJ IDEA 打包 Web 项目 WAR 包(含 Tomcat 部署+常见问题解决)
在这里插入图片描述

一、引言

对于 IntelliJ IDEA 新手来说,Web 项目 WAR 包打包常因步骤多、配置深而卡壳,且多数教程仅讲“打包”却忽略“部署验证”和“问题排查”。本文将从前置准备→核心配置→打包验证→Tomcat 部署→问题解决,带你完整走通流程,避开 90% 的常见坑。

二、前置准备:确认基础配置(避免起步就错)

在开始打包前,先检查 3 个关键前提,缺失任一环节可能导致后续操作失败:

  1. 确认项目类型:打开项目结构(快捷键 Shift+Ctrl+Alt+S),在「Modules」中查看模块类型是否为「Web Application」,若不是,需右键模块→「Add Framework Support」→勾选「Web Application」。
  2. 配置 JDK/SDK:在「Project Structure」→「Project」中,确认「Project SDK」已选择本地 JDK(建议 1.8 及以上),「Project language level」与 JDK 版本匹配(如 JDK 1.8 对应 level 8)。
  3. 准备 Tomcat(部署用):本地已安装 Tomcat(建议 8.x/9.x 版本),并记住其安装路径(如 D:\apache-tomcat-9.0.60),后续部署需用到。

三、核心配置:Artifacts 配置(打包关键步骤)

此模块是打包核心,按“新建工件→补全目录→关联编译输出”三步拆解,每步附操作目的,避免盲目点击:

3.1 新建 Web Archive 工件(即 WAR 包模板)

  1. 操作步骤:打开「Project Structure」→选择左侧「Artifacts」→点击界面左上角「+」号→依次选择「Web Application: Archive」→「Empty」。
  2. 操作目的:创建一个空的 WAR 包模板,后续将项目文件、编译结果逐步添加到该模板中。

3.2 配置 Web 根目录(确保页面文件能被访问)

  1. 操作步骤:在「Artifacts」右侧「Output Layout」面板中,右键「」→选择「Add Content Directory」→在弹窗中选中项目的 Web 根目录(通常名为 WebContentwebapp,需包含 index.htmlWEB-INF 文件夹)。
  2. 操作目的:Web 根目录是项目对外访问的入口,缺失会导致部署后无法找到页面(如 index.html)。

3.3 补全 WEB-INF/classes 目录(存放编译后的代码)

  1. 操作步骤:
    • 在「Output Layout」面板中,展开已添加的 Web 根目录→找到「WEB-INF」文件夹(若没有则右键 Web 根目录→「New Folder」创建)。
    • 右键「WEB-INF」→「New Folder」→命名为 classes(必须小写,Web 项目标准目录)。
  2. 操作目的:classes 目录用于存放项目编译后的 .class 文件(如 Controller、Service 类),缺失会导致 Tomcat 无法加载业务逻辑代码。

3.4 关联 Module Output(自动导入编译结果)

  1. 操作步骤:在「Output Layout」面板中,右键「classes」目录→选择「Add Module Output」→在弹窗中选择当前 Web 项目的模块(如 demo-web)→点击「OK」。
  2. 操作目的:将项目编译后的 .class 文件自动同步到 classes 目录,无需手动复制,避免遗漏文件。

四、打包与验证:确保 WAR 包可用

4.1 执行打包操作

  1. 操作步骤:点击顶部菜单栏「Build」→「Build Artifacts」→在弹窗中选择已配置的 Artifact(如 unnamed:war)→选择「Build」(首次打包)或「Rebuild」(更新后重新打包)。
  2. 查找 WAR 包:打包完成后,WAR 包默认存放在项目根目录下的 out\artifacts\ 文件夹中(如 demo\out\artifacts\unnamed.war)。

4.2 验证 WAR 包有效性(避免白忙活)

  1. 验证方法:用压缩软件(如 WinRAR)打开 WAR 包,检查以下 3 点:
    • 根目录下是否有 index.html 等页面文件。
    • WEB-INF 文件夹下是否有 classes 目录,且 classes 内有 .class 文件。
    • WEB-INF 文件夹下是否有 web.xml(若项目用注解配置则可无,但传统项目需包含)。
  2. 验证目的:提前排查打包缺陷,避免带着问题去部署,减少后续排错时间。

五、Tomcat 部署:从打包到访问全流程

  1. 部署步骤:
    • 将验证通过的 WAR 包复制到 Tomcat 的 webapps 目录下(如 D:\apache-tomcat-9.0.60\webapps)。
    • 进入 Tomcat 的 bin 目录,双击 startup.bat(Windows)或执行 ./startup.sh(Linux/Mac)启动 Tomcat。
    • 访问测试:打开浏览器,输入 http://localhost:8080/[WAR包名]/index.html(如 WAR 包名为 demo.war,则路径为 http://localhost:8080/demo/index.html),能正常显示页面即部署成功。
  2. 注意事项:若 Tomcat 启动失败,可查看 logs 目录下的 catalina.out 文件,排查端口占用、依赖冲突等问题。

六、常见问题解决方案(打包/部署高频坑)

6.1 问题 1:WAR 包内无 lib 依赖(第三方 jar 缺失)

  • 现象:部署后报错“ClassNotFoundException”(找不到 Spring、MyBatis 等依赖类)。
  • 原因:Artifacts 配置中未添加项目依赖的库文件。
  • 解决方案:在「Artifacts」→「Output Layout」中,右键「WEB-INF」→选择「Add Library Files」→勾选项目依赖的库(如 Spring CoreMyBatis)→点击「OK」,重新打包。

6.2 问题 2:classes 目录为空(无 .class 文件)

  • 现象:打开 WAR 包,WEB-INF/classes 目录下无任何文件。
  • 原因:未关联 Module Output,或代码未编译。
  • 解决方案:
    1. 重新执行「3.4 关联 Module Output」步骤,确认模块选择正确。
    2. 先执行「Build」→「Rebuild Project」编译项目,再重新打包。

6.3 问题 3:部署后访问 404(页面找不到)

  • 现象:浏览器输入地址后显示“404 Not Found”。
  • 原因:WAR 包未被 Tomcat 解压,或访问路径错误,或 Tomcat 端口被占用。
  • 解决方案:
    1. 检查 webapps 目录:启动 Tomcat 后,若 WAR 包未自动解压(无同名文件夹),删除 WAR 包,重启 Tomcat 重试。
    2. 核对访问路径:确保路径中包含 WAR 包名(如 http://localhost:8080/demo/index.html,而非 http://localhost:8080/index.html)。
    3. 检查端口:打开 conf/server.xml 文件,查看 <Connector port="8080" 是否被占用,若占用则修改端口(如改为 8081),重启 Tomcat。

七、场景扩展:适配 Maven/多模块项目

7.1 Maven 项目打包(更简洁,无需手动配置 Artifacts)

  1. 操作步骤:打开右侧「Maven」面板→展开项目→「Lifecycle」→双击「package」,Maven 会自动编译、打包,WAR 包存放在 target 目录下。

自定义配置:若需修改 WAR 包名称,在 pom.xml 中添加:

<build><finalName>my-demo</finalName><!-- 自定义 WAR 包名 --></build>

7.2 多模块项目打包(仅打包 Web 模块)

  • 操作要点:多模块项目(如 demo-parent 下有 demo-servicedemo-web),仅需对 demo-web 模块(Web 类型)执行上述打包步骤,无需处理父模块或服务模块。

八、总结

本文从“配置→打包→验证→部署→排错”覆盖 WAR 包全流程,核心是确保「Artifacts 配置完整」和「提前验证打包结果」。若遇到其他问题,可在评论区留言,我会及时补充解决方案。

你只需将模板中的「示例名称」(如 demo-webunnamed.war)替换为实际项目信息,再补充对应步骤的截图,就能生成一篇逻辑清晰、实用性强的新版博客。需要我帮你针对某一模块(如“Maven 项目打包”)补充更详细的操作截图说明吗?

Read more

前端环境配置(nvm、nodejs、npm)

前端环境配置(nvm、nodejs、npm)

一、安装nvm 1. 下载vnm url: https://nvm.uihtm.com/doc/download-nvm.html 2. 解压文件后双击exe文件进行安装 3. 选择nvm的安装地址,我是安装在D:\App\nvm 4. 选择nodejs的安装地址,我是安装在C:\Program Files\nodejs 5. 点击next 一直点击 完成安装; 6. 找到nvm的settings.txt文件打开后: 给该文件添加这两行命令: node_mirror: https://npmmirror.com/mirrors/node/ npm_mirror: https://npmmirror.com/mirrors/npm/ 二、环境变量配置 1.

【DeepSeek R1部署至RK3588】RKLLM转换→板端部署→局域网web浏览

【DeepSeek R1部署至RK3588】RKLLM转换→板端部署→局域网web浏览

本文为DeepSeek R1 7B 以qwen为底座的LLM在瑞芯微RK3588 SoC上的完整部署流程,记录从开发板驱动适配烧录开始,到最终的开发板终端访问模型和局域网web访问模型的完整流程,有不足之处希望大家共同讨论。 文章目录 * 一、项目背景介绍 * 二、所需工具介绍 * 1.硬件工具 * 1.X86 PC虚拟机Ubuntu20.04 * 2. 准备NPU驱动为0.9.8的RK3588开发板 * 2.软件工具 * 三、获取.safetensors模型权重 * 四、safetensors转RKLLM * 1.转换环境搭建 * 2.模型转换 * 五、RKLLM模型板端部署及推理 * 六、集成开源gradio工具实现web访问 一、项目背景介绍 先来介绍下项目背景吧,目前有一个空闲的firefly出厂的搭载瑞芯微RK3588 SoC的arm64开发板,样式如图所示: 博主之前主要进行CV领域的模型的RK开发板部署,对于LLM和VLM的接触并不算多,但现在大模型是趋势所向,并且瑞芯微及时的完成了针对各开源

想做多语言项目?试试Hunyuan-MT-7B-WEBUI快速部署方案

想做多语言项目?试试Hunyuan-MT-7B-WEBUI快速部署方案 你有没有遇到过这样的情况:手头有个跨境项目,要同时处理日语产品说明、西班牙语用户反馈、维吾尔语政策文件,甚至还有藏文古籍数字化需求——可翻来翻去,不是翻译质量差强人意,就是部署起来像在解一道高数题?在线工具不敢传敏感数据,本地跑模型又卡在CUDA版本、依赖冲突、显存爆炸上……最后只能靠人工硬啃,进度一拖再拖。 Hunyuan-MT-7B-WEBUI 就是为这种真实困境而生的。它不讲大道理,不堆参数,不做“实验室里的冠军”,而是把腾讯混元团队打磨出的最强开源翻译模型,连同网页界面、一键脚本、预装环境,全打包进一个镜像里。你不需要懂Transformer结构,不用查PyTorch兼容表,甚至不用打开终端敲命令——点一下,等两分钟,就能在浏览器里开始翻译38种语言。 这不是又一个“需要调参、需要写代码、需要配环境”的AI工具。这是你今天下午就能用上的多语言工作台。 1. 为什么这款翻译镜像值得你立刻试试? 1.1 它真能覆盖你没想过的语言 很多翻译模型标榜“支持多语言”,但实际打开列表一看:英、法、

前端实现Word文档在线编辑与导出:基于mammoth.js与Blob对象的完整解决方案

如何在浏览器中直接编辑Word文档并导出?本文将深入探索一种基于mammoth.js和Blob对象的完整技术方案。 在当今的Web应用开发中,实现文档的在线编辑与导出已成为常见需求。无论是企业内部系统、教育平台还是项目管理工具,都迫切需要让用户能够在浏览器中直接编辑Word文档,而无需安装桌面软件。本文将详细介绍如何利用mammoth.js和Blob对象实现这一功能,并对比其他可行方案。 一、为什么选择mammoth.js与Blob方案? 在Web前端实现Word文档处理,主要有三种主流方案:浏览器原生Blob导出、mammoth.js专业转换和基于模板的docxtemplater方案。它们各有优劣,适用于不同场景。 mammoth.js的核心优势在于它能将.docx文档转换为语义化的HTML,而非简单复制视觉样式。这意味着它生成的HTML结构清晰、易于维护和样式定制。配合Blob对象,我们可以轻松将编辑后的内容重新导出为Word文档。 与直接使用Microsoft Office Online或Google Docs嵌入相比,mammoth.js方案不依赖外部服务,能更好地