三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

IntelliJ IDEA中Java项目打包实战：从普通JAR到Spring Boot可执行JAR

发布时间：2026/8/8 1:45:07 三亩地 编程学习日记
IntelliJ IDEA中Java项目打包实战：从普通JAR到Spring Boot可执行JAR

1. 项目概述：从代码到可执行JAR的旅程

在Java开发的世界里，无论你是在开发一个微服务、一个工具库，还是一个桌面应用，最终都需要将你的源代码“打包”成一个可交付的单元。这个过程，就像是把散落的零件组装成一台可以独立运行的机器。而JAR（Java ARchive）包，就是Java世界里最标准、最通用的“成品”格式。它不仅仅是一个压缩文件，更是一个包含了编译后的类文件、资源文件以及元数据（如清单文件MANIFEST.MF）的完整封装。对于使用IntelliJ IDEA（以下简称IDEA）的开发者来说，虽然IDE提供了便捷的图形化打包按钮，但如果不理解其背后的机制，一旦遇到“打包成功但运行报错”、“依赖找不到”或者“配置文件丢失”等问题，就会陷入困境。这篇文章，我将结合十多年的实战经验，为你彻底拆解在IDEA中，如何将项目代码打包成一个“健壮、可部署、无坑”的JAR包。无论你的项目是普通的Java SE应用、使用了Maven的Spring Boot应用，还是复杂的多模块项目，我们都会一一覆盖，并深入那些官方文档很少提及的细节和陷阱。

2. 打包前的核心认知：JAR包的类型与选择

在动手点击“打包”按钮之前，我们必须搞清楚要打一个什么样的包。不同的打包方式决定了JAR包的运行方式、体积大小和部署复杂度。这一步选错了，后面所有的操作都可能事倍功半。

2.1 三种主流JAR包类型详解

1. 普通JAR（JAR with dependencies）这是我们最常说的“胖JAR”或“可执行JAR”。它的目标是将项目自身的代码和所有第三方依赖库（即lib文件夹下的那些.jar文件）全部打包进同一个JAR文件中。这样产生的JAR包通常体积较大，但部署极其简单，只需要一个JAR文件和Java运行环境（JRE）即可运行。

  • 优点：部署简单，环境依赖少，真正做到“开箱即用”。
  • 缺点：包体积大，依赖库更新麻烦（需要重新打包整个应用），多个应用无法共享相同的依赖库，可能造成磁盘空间浪费。
  • 适用场景：微服务、独立桌面应用、需要快速分发给最终用户的小工具。

2. 瘦JAR（JAR without dependencies）这种JAR包只包含项目自身编译后的类文件和资源，不包含任何第三方依赖。运行时，需要依赖的JAR包必须通过-cp或-classpath参数指定，或者放在特定的目录下（如lib/）。

  • 优点：包体积小，结构清晰，依赖库可以独立管理和共享。
  • 缺点：部署复杂，必须确保运行环境中有所有正确版本的依赖，否则会抛出ClassNotFoundException。
  • 适用场景：作为公共库（Library）被其他项目引用时，必须打瘦JAR。某些对启动速度和包体积有极致要求，且部署环境可控的场景。

3. Spring Boot可执行JAR这是Spring Boot项目特有的打包方式，它本质上也是一种“胖JAR”，但内部结构更为精巧。它使用一个特殊的“嵌套JAR”结构（Nested JAR），将应用本身的代码和所有依赖库打包在一个JAR文件内的BOOT-INF/目录下，同时使用一个独立的“启动加载器”（Launcher）来引导应用。这种结构解决了传统胖JAR中，依赖资源路径冲突的问题（比如多个依赖JAR里都有META-INF/MANIFEST.MF文件）。

  • 优点：继承了胖JAR部署简单的优点，同时解决了资源冲突问题，是Spring Boot应用的官方推荐和默认打包方式。
  • 缺点：结构特殊，直接解压后无法像普通JAR一样通过java -cp直接运行其中的某个类（需要通过启动器）。
  • 适用场景：所有基于Spring Boot框架的Web应用或微服务。

注意：选择哪种类型，取决于你的项目类型和部署需求。对于现代Java后端开发，尤其是微服务架构，Spring Boot可执行JAR是绝对的主流。而如果你在开发一个工具库给其他团队用，那么瘦JAR是唯一的选择。

2.2 工具链选择：Maven vs. Gradle vs. IDEA原生

IDEA支持多种构建工具，不同的工具决定了打包配置的方式。

  • Maven：目前Java生态的“事实标准”，配置文件为pom.xml。它的插件体系（如maven-jar-plugin,maven-shade-plugin,spring-boot-maven-plugin）是打包能力的核心。本文将以Maven项目为重点进行讲解，因为其用户基数最大，遇到的问题也最具代表性。
  • Gradle：以灵活和性能著称，使用Groovy或Kotlin DSL编写build.gradle脚本。其打包逻辑与Maven类似，但语法不同。
  • IDEA原生（Artifacts）：在不使用Maven/Gradle的纯Java项目里，你可以通过IDEA的“Project Structure -> Artifacts”来手动配置打包。这种方式更直观，但不够灵活，且难以融入CI/CD流程，不推荐在正式项目中使用。

核心原则：对于任何正经项目，都应该使用Maven或Gradle进行构建和打包管理，IDEA只是提供了一个操作这些构建工具的图形界面。你的打包逻辑，应该固化在pom.xml或build.gradle中，而不是依赖IDE的某个特定配置。

3. 实战演练一：打包普通Java SE项目（含依赖）

假设我们有一个简单的Java SE项目，它使用了commons-lang3和gson这两个第三方库。我们的目标是生成一个可执行的胖JAR。

3.1 项目结构与Maven配置

项目结构如下：

my-app ├── src │ ├── main │ │ ├── java │ │ │ └── com │ │ │ └── example │ │ │ └── App.java (包含main方法) │ │ └── resources │ │ └── config.properties │ └── test │ └── java └── pom.xml

关键的pom.xml配置如下。这里我们使用maven-shade-plugin，它是Apache提供的一个非常强大的Maven插件，专门用于创建包含所有依赖的可执行JAR，并能处理依赖冲突、重命名类等高级操作。

<project ...> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>my-app</artifactId> <version>1.0-SNAPSHOT</version> <properties> <maven.compiler.source>8</maven.compiler.source> <maven.compiler.target>8</maven.compiler.target> </properties> <dependencies> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>3.12.0</version> </dependency> <dependency> <groupId>com.google.code.gson</groupId> <artifactId>gson</artifactId> <version>2.10.1</version> </dependency> </dependencies> <build> <plugins> <!-- 编译插件 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.11.0</version> <configuration> <source>8</source> <target>8</target> </configuration> </plugin> <!-- 核心：打包插件 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>3.5.0</version> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <!-- 创建可执行JAR --> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <!-- 指定主类（程序入口） --> <mainClass>com.example.App</mainClass> </transformer> <!-- 处理Spring的配置文件冲突（如果是Spring项目需要） --> <!-- <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer"> <resource>META-INF/spring.handlers</resource> </transformer> --> </transformers> <!-- 可选：过滤掉不需要的依赖（如测试依赖） --> <filters> <filter> <artifact>*:*</artifact> <excludes> <exclude>META-INF/*.SF</exclude> <exclude>META-INF/*.DSA</exclude> <exclude>META-INF/*.RSA</exclude> </excludes> </filter> </filters> </configuration> </execution> </executions> </plugin> </plugins> </build> </project>

3.2 在IDEA中执行打包操作

配置好pom.xml后，在IDEA中打包就变得非常简单。

  1. 打开IDEA右侧的“Maven”工具窗口（通常在最右边栏，如果没有，可以通过View -> Tool Windows -> Maven打开）。
  2. 展开你的项目，找到Lifecycle生命周期。
  3. 双击package命令。IDEA会开始执行Maven的打包生命周期。

执行过程解读： 当你执行package时，Maven会按顺序执行validate、compile、test、package等阶段。maven-shade-plugin绑定在package阶段，所以它会在此阶段被触发。你会在IDEA的“Run”工具窗口或“Maven”窗口的日志中看到类似下面的输出：

[INFO] --- maven-shade-plugin:3.5.0:shade (default) @ my-app --- [INFO] Including org.apache.commons:commons-lang3:jar:3.12.0 in the shaded jar. [INFO] Including com.google.code.gson:gson:jar:2.10.1 in the shaded jar. [INFO] Replacing original artifact with shaded artifact. [INFO] Replacing /path/to/my-app/target/my-app-1.0-SNAPSHOT.jar with /path/to/my-app/target/my-app-1.0-SNAPSHOT-shaded.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS

打包成功后，你可以在项目的target/目录下找到生成的JAR文件：my-app-1.0-SNAPSHOT.jar（注意，shade插件默认会替换掉原始的瘦JAR）。

3.3 验证与运行

打包完成后，务必进行验证。

  1. 检查JAR内容：你可以使用解压软件（如7-Zip）直接打开生成的JAR包，或者使用命令jar tf target/my-app-1.0-SNAPSHOT.jar。你应该能看到：
    • com/example/App.class（你的主类）
    • org/apache/commons/lang3/...（依赖库的类）
    • com/google/gson/...（依赖库的类）
    • META-INF/MANIFEST.MF（清单文件）
  2. 检查清单文件：查看META-INF/MANIFEST.MF，确认Main-Class属性是否正确设置为com.example.App。
  3. 运行测试：打开终端，进入项目根目录，执行：
    java -jar target/my-app-1.0-SNAPSHOT.jar
    如果程序正常启动并输出预期结果，恭喜你，打包成功！

实操心得：

  • 插件版本：尽量使用较新稳定版本的插件，旧版本可能有已知Bug。例如，老版本的maven-shade-plugin在处理某些特定资源文件时可能会出错。
  • 主类确认：<mainClass>一定要填写完整类名（包含包路径），这是最常见的打包成功但无法运行的错误原因之一。
  • 资源文件处理：如果你的resources目录下有配置文件（如.properties,.xml,.yml），maven-shade-plugin默认会将它们打包进去。但如果多个依赖JAR中存在同名资源文件（例如META-INF/services/javax.xml.parsers.SAXParserFactory），可能会被覆盖。这时就需要使用AppendingTransformer（如上面配置中注释掉的部分）或ServicesResourceTransformer来合并这些服务文件，而不是覆盖。

4. 实战演练二：打包Spring Boot项目

Spring Boot项目的打包是当今Java后端开发中最常见的场景。Spring Boot通过spring-boot-maven-plugin插件，让打包变得异常简单，几乎无需额外配置。

4.1 标准Spring Boot项目打包配置

一个标准的Spring Boot项目的pom.xml继承自spring-boot-starter-parent，并引入了Web等起步依赖。

<project ...> <modelVersion>4.0.0</modelVersion> <!-- 继承Spring Boot父POM，统一管理依赖版本 --> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.14</version> <!-- 注意版本号，需与依赖匹配 --> <relativePath/> </parent> <groupId>com.example</groupId> <artifactId>my-spring-boot-app</artifactId> <version>0.0.1-SNAPSHOT</version> <name>my-spring-boot-app</name> <description>Demo project for Spring Boot</description> <properties> <java.version>1.8</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- 其他依赖 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <!-- 核心：Spring Boot Maven 插件 --> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <!-- 通常无需指定版本，由parent管理 --> </plugin> </plugins> </build> </project>

就是这么简单！spring-boot-maven-plugin插件默认绑定了repackage目标，它会在Maven的package阶段之后执行，将Maven生成的普通JAR重新打包成Spring Boot可执行JAR。

4.2 执行打包与结果分析

在IDEA的Maven工具窗口中，同样双击Lifecycle下的package。你会看到日志中出现了spring-boot-maven-plugin的执行信息：

[INFO] --- spring-boot-maven-plugin:2.7.14:repackage (repackage) @ my-spring-boot-app --- [INFO] Replacing main artifact with repackaged archive

打包完成后，target/目录下会生成两个JAR文件：

  1. my-spring-boot-app-0.0.1-SNAPSHOT.jar.original：这是Maven标准插件maven-jar-plugin生成的原始“瘦JAR”。
  2. my-spring-boot-app-0.0.1-SNAPSHOT.jar：这是spring-boot-maven-plugin重新打包后的“胖JAR”，也就是我们最终需要的可执行JAR。

解构Spring Boot JAR： 用解压软件打开最终的可执行JAR，你会看到其独特的内部结构：

my-spring-boot-app-0.0.1-SNAPSHOT.jar ├── META-INF/ │ └── MANIFEST.MF (包含Main-Class: org.springframework.boot.loader.JarLauncher) ├── BOOT-INF/ │ ├── classes/ (你的应用类文件和资源，如com/example/Application.class, application.yml) │ └── lib/ (所有的第三方依赖JAR包) └── org/ └── springframework/ └── boot/ └── loader/ (Spring Boot的JarLauncher类)

这个结构完美解决了传统胖JAR的资源冲突问题，因为所有依赖库都被隔离在了BOOT-INF/lib/下。

4.3 运行与部署

运行Spring Boot JAR和运行普通胖JAR一样：

java -jar target/my-spring-boot-app-0.0.1-SNAPSHOT.jar

应用会启动内嵌的Tomcat服务器并开始监听端口（默认8080）。

关于“未解析的依赖项”错误： 在配置过程中，你可能会遇到类似未解析的依赖项: 'org.springframework.boot:spring-boot-starter-web:jar:2.7.14的错误。这几乎总是由以下原因之一造成的：

  1. 网络问题：Maven无法从中央仓库或你配置的镜像仓库下载依赖。检查网络，或尝试使用阿里云等国内镜像。
  2. 版本不匹配：<parent>中定义的Spring Boot版本与依赖中显式指定的版本冲突。最佳实践是依赖项不要写版本号，由父POM统一管理。如果非要写，必须确保一致。
  3. 本地仓库损坏：删除本地Maven仓库（默认在~/.m2/repository）中对应的依赖目录（如org/springframework/boot/spring-boot-starter-web/2.7.14/），然后让Maven重新下载。
  4. IDE缓存：在IDEA中，尝试File -> Invalidate Caches and Restart...。

5. 高级配置与深度优化

掌握了基础打包后，我们来看看如何应对更复杂的需求和进行优化。

5.1 定制化MANIFEST.MF文件

清单文件包含了JAR包的元数据。除了主类，我们经常需要添加一些自定义属性。

  • 在普通Maven项目中（使用maven-jar-plugin）：

    <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>3.3.0</version> <configuration> <archive> <manifest> <mainClass>com.example.App</mainClass> <addClasspath>true</addClasspath> <!-- 将依赖添加到Class-Path属性 --> <classpathPrefix>lib/</classpathPrefix> <!-- 指定依赖目录前缀 --> </manifest> <manifestEntries> <Built-By>${user.name}</Built-By> <Implementation-Version>${project.version}</Implementation-Version> <Build-Time>${maven.build.timestamp}</Build-Time> </manifestEntries> </archive> </configuration> </plugin>

    这样打出的瘦JAR，其MANIFEST.MF会包含Class-Path，指导JVM从lib/目录下寻找依赖JAR。

  • 在Spring Boot项目中：spring-boot-maven-plugin会自动生成必要的清单信息。如果你想添加自定义属性，可以通过配置实现：

    <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <mainClass>com.example.MyApplication</mainClass> <layout>JAR</layout> <!-- 添加自定义清单条目 --> <manifest> <addDefaultEntries>false</addDefaultEntries> <addClasspath>true</addClasspath> </manifest> <manifestEntries> <Built-By>MyTeam</Built-By> </manifestEntries> </configuration> </plugin>

5.2 排除不必要的依赖与资源

为了减小JAR包体积，我们需要排除一些仅在开发或测试阶段需要的依赖和文件。

  • 排除依赖：在pom.xml中，通过<scope>标签管理依赖作用域。
    • test：仅用于测试，不会被打包。
    • provided：由运行环境（如Tomcat服务器、JDK）提供，打包时排除。
    <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <scope>provided</scope> <!-- 编译时需要，运行时不需要 --> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <scope>test</scope> <!-- 仅测试 --> </dependency>
  • 排除资源文件：在pom.xml的<build>部分配置资源过滤。
    <build> <resources> <resource> <directory>src/main/resources</directory> <excludes> <exclude>**/*.keystore</exclude> <!-- 排除密钥文件 --> <exclude>**/test-*.yml</exclude> <!-- 排除测试配置文件 --> </excludes> <filtering>true</filtering> <!-- 是否启用属性过滤（如${}替换） --> </resource> </resources> </build>
  • 使用Maven Profile进行环境隔离：这是一个非常实用的技巧。你可以为开发、测试、生产环境定义不同的Profile，打包时激活对应的Profile，从而引入不同的配置或依赖。
    <profiles> <profile> <id>dev</id> <activation> <activeByDefault>true</activeByDefault> <!-- 默认激活 --> </activation> <properties> <env>dev</env> </properties> <build> <resources> <resource> <directory>src/main/resources</directory> <includes> <include>application.yml</include> <include>application-${env}.yml</include> <!-- 包含application-dev.yml --> </includes> </resource> </resources> </build> </profile> <profile> <id>prod</id> <properties> <env>prod</env> </properties> <!-- 生产环境可能排除开发工具依赖 --> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>provided</scope> <!-- 或者直接不引入 --> </dependency> </dependencies> </profile> </profiles>
    打包时，在IDEA的Maven工具窗口的Profiles里勾选prod，或者使用命令mvn clean package -P prod。

5.3 多模块项目的打包策略

对于大型项目，我们通常采用多模块（Multi-Module）结构。父pom.xml中<packaging>为pom，子模块可以是jar或war。

  • 聚合模块（父POM）：只负责管理公共依赖和插件版本，不包含源代码，也不打包。
  • 子模块：每个子模块是一个独立的可编译、可打包的单元。例如，一个common工具模块打jar包供其他模块依赖；一个web应用模块使用spring-boot-maven-plugin打可执行jar包。
  • 打包操作：在父项目根目录执行mvn clean package，Maven会依据模块依赖关系，按顺序编译和打包所有子模块。最终，每个子模块的target/目录下会生成自己的JAR包。对于需要部署的应用模块（如web），直接取用其生成的JAR即可。

关键点：确保子模块间的依赖在pom.xml中正确定义。在打包应用模块时，Maven会将其依赖的其他模块JAR（如果它们也被打包为JAR）以及第三方依赖，一并处理（对于Spring Boot项目，会打包进BOOT-INF/lib）。

6. 常见问题排查与实战技巧

即使按照步骤操作，打包路上依然坑洼不断。这里记录了我踩过的一些典型问题和解决思路。

6.1 打包后运行报“找不到主清单属性”或“主类”

这是最常见的问题，没有之一。

  • 症状：java -jar your-app.jar提示no main manifest attribute, in your-app.jar或Error: Could not find or load main class com.example.App。
  • 排查步骤：
    1. 检查MANIFEST.MF：用解压工具或jar tf your-app.jar | grep META-INF/MANIFEST.MF找到并查看该文件。确认Main-Class属性是否存在且值正确。
    2. 确认插件配置：检查pom.xml中是否正确配置了maven-shade-plugin（普通项目）或spring-boot-maven-plugin（Spring Boot项目）的<mainClass>。
    3. 检查打包结果：对于Spring Boot项目，确认你运行的是your-app.jar而不是your-app.jar.original。后者是瘦JAR，没有启动器。
    4. 类名拼写：确保<mainClass>的值与项目中实际包含public static void main(String[] args)方法的类完全一致，包括大小写。

6.2 依赖冲突与类找不到（NoClassDefFoundError/ClassNotFoundException）

  • 症状：程序在IDEA里运行正常，打包后运行抛出NoClassDefFoundError或ClassNotFoundException。
  • 原因分析：
    • 瘦JAR问题：打了瘦JAR，但运行时没有将依赖JAR放入classpath。
    • 依赖作用域错误：某个必需的依赖被错误地声明为test或provided作用域，导致打包时被排除。
    • 依赖传递冲突：两个依赖引入了不同版本的同名JAR，Maven根据“最近原则”选择了其中一个，导致另一个版本中的类缺失。
  • 解决方案：
    1. 检查依赖树：在项目根目录执行mvn dependency:tree，查看最终的依赖关系，确认所需的JAR是否在列表中，版本是否正确。
    2. 检查作用域：在dependency:tree的输出中，注意每个依赖后面的compile,runtime,test,provided标识。
    3. 排除冲突依赖：如果发现冲突，可以在引入依赖时排除掉不需要的传递依赖。
      <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <!-- 例如，排除Tomcat改用Jetty --> </exclusion> </exclusions> </dependency>
    4. 使用maven-shade-plugin重命名：对于无法排除的底层库冲突（如不同组件依赖了不同版本的asm），可以使用shade插件重命名其中一个包。
      <configuration> <relocations> <relocation> <pattern>org.objectweb.asm</pattern> <!-- 原包名 --> <shadedPattern>com.example.shaded.asm</pattern> <!-- 重命名后的包名 --> </relocation> </relocations> </configuration>

6.3 资源文件（配置文件）丢失或读取错误

  • 症状：代码中通过ClassLoader.getResource()或getResourceAsStream()读取src/main/resources下的文件，在IDEA中运行正常，打包后却返回null。
  • 原因与解决：
    1. 路径问题：打包后资源文件位于JAR的根目录或BOOT-INF/classes/下。使用ClassLoader.getResource("filename")时，路径前不要加/。正确的做法是假设资源文件与你的类文件在同一“目录”下。
    2. 资源未被包含：检查pom.xml的<resources>配置，看是否通过<excludes>无意中排除了该文件。
    3. Spring Boot特定资源：Spring Boot应用通常使用@Value或@ConfigurationProperties来注入配置，或者通过ResourceLoader加载。确保你的配置文件（如application.yml）位于src/main/resources下，并且没有被过滤掉。Spring Boot在打包后能正确识别BOOT-INF/classes/下的资源。

6.4 打包速度优化与JAR瘦身

项目大了之后，打包会变得很慢，JAR包也动辄上百MB。

  • 跳过测试：打包时使用mvn clean package -DskipTests可以跳过单元测试，大幅提升速度。在IDEA的Maven执行配置中也可以永久设置。
  • 使用并行构建：在~/.m2/settings.xml中配置<parallel>true</parallel>可以启用并行构建（对多模块项目效果明显）。
  • JAR瘦身：
    • 使用spring-boot-thin-launcher：对于Spring Boot，可以考虑使用Thin Launcher，它只打包应用代码，依赖在运行时从Maven仓库下载或缓存。这能极大减小初次部署的包体积。
    • 排除开发依赖：严格检查所有依赖的<scope>，确保test和provided的依赖不会被打包。
    • 清理无用资源：定期清理src/main/resources中不再使用的图片、文档等。
    • 使用maven-dependency-plugin分析：执行mvn dependency:analyze可以分析出项目中声明了但未使用的依赖（Unused declared dependencies），以及使用了但未声明的依赖（Used undeclared dependencies），帮助优化pom.xml。

6.5 IDEA特定问题排查

  • “Maven项目打包报错”：首先检查IDEA右侧Maven工具窗口顶部，是否选择了正确的Maven版本（推荐使用自带的Bundled (Maven 3)或你本地安装的版本）和settings.xml。然后，尝试点击Maven工具窗口的刷新按钮（Reimport All Maven Projects）。很多时候，问题在于IDEA的索引和Maven的实际状态不同步。
  • “程序包不存在”但Maven命令可以编译：这是IDEA的模块编译问题。尝试File -> Invalidate Caches and Restart...。如果不行，检查File -> Project Structure -> Modules，看是否所有源目录（Sources）和依赖（Dependencies）都正确配置了。
  • 打包时编码警告：在pom.xml中全局设置编码，避免中文乱码。
    <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> </properties>

打包看似是开发的最后一步，但一个稳定、高效的打包配置却是项目可维护、可交付的基石。理解背后的原理，善用Maven/Gradle插件，掌握排查问题的基本方法，就能让你在交付环节从容不迫。记住，最好的配置是那些写在pom.xml或build.gradle里，与代码一起被版本管理的配置，而不是依赖某个开发人员IDE里的一次性操作。

编程学习 学习日记 实战经验
← 返回列表