企业官网建设流程全解析

1. 这个警告到底在说什么

如果你用 IntelliJ IDEA 跑一个 Maven 项目，编译输出里突然冒出一行黄字：

Warning:java: 源值 1.5 已过时, 将在未来所有发行版中删除 Warning:java: 目标值 1.5 已过时, 将在未来所有发行版中删除

先别慌，这不是你代码写错了，也不是依赖冲突，更不是 IDEA 抽风。它说的是：编译器正在用 Java 5 的语言级别（source）和字节码版本（target）来编译你的代码，而 Java 5 这个级别早就被标记为过时了，未来的 JDK 版本会彻底移除对它的支持。

这个警告的本质，是Maven 编译插件（maven-compiler-plugin）没有拿到明确的 source/target 配置，于是它退回到了一个非常古老的默认值。在比较老的 maven-compiler-plugin 版本里，默认的 source 和 target 就是 1.5。你的 JDK 可能是 8、11、17 甚至 21，但编译插件压根没理会，它自顾自地按 1.5 的规则来。

这件事的迷惑性在于：你的项目可能跑起来完全正常。因为大多数业务代码不会用到 Java 5 之后才有的语法特性，所以编译能过、测试能跑、打包能成。但隐患是实打实的——你写的 lambda、try-with-resources、var、switch 表达式、文本块，只要用了新语法，编译就会直接报错，而不是警告。更隐蔽的是，字节码版本停留在 1.5，意味着你没法用上高版本 JVM 的很多优化和特性，某些依赖库如果要求更高的字节码版本，运行时可能抛出UnsupportedClassVersionError。

所以这行警告的正确态度是：必须处理，而且处理起来很简单。它属于那种"不处理也能跑，但处理了才专业"的典型问题。下面我把这个问题的来龙去脉、几种解决方案、以及每种方案背后的取舍，完整地拆一遍。

2. 为什么 Maven 会默认用 1.5

2.1 编译插件的默认值历史包袱

要理解这个警告，得先知道 Maven 的编译插件是怎么演进的。maven-compiler-plugin 在很早期的版本（比如 2.x 系列）里，source和target的默认值就是1.5。这个默认值定下来的时候，Java 5 还是主流，谁也没想到后面会出这么多版本。

后来 Java 6、7、8 陆续发布，但编译插件的默认值一直没改，原因很简单：改默认值会破坏向后兼容。如果某个老项目一直依赖 1.5 的编译行为，插件突然把默认值提到 8，可能会导致一些边缘情况下的编译结果变化。Maven 社区选择了保守策略——默认值不动，让用户在 pom 里显式声明。

到了 maven-compiler-plugin 3.8.0 之后，情况有所变化，默认值开始跟随运行时的 JDK 版本走。但如果你用的是老版本插件，或者项目继承的父 pom 里锁定了老版本，那 1.5 的默认值就会一直生效。这就是为什么同样一个项目，在同事机器上没警告，在你机器上有警告——很可能是因为插件版本或者父 pom 配置不同。

2.2 IDEA 和 Maven 的"双重配置"陷阱

这里有个很多人踩过的坑：IDEA 自己有一套编译配置，Maven 也有一套编译配置，两者是独立的。

你在 IDEA 里打开File -> Project Structure -> Project，看到Language level可能显示的是 8 或者 11，于是你以为没问题。但实际上，当你通过 Maven 的生命周期（比如mvn compile）来编译时，用的是 pom 里 maven-compiler-plugin 的配置，跟 IDEA 的 Project Structure 设置没关系。

反过来也一样。如果你在 IDEA 里直接点运行按钮，IDEA 可能用自己的一套配置来编译，这时候 pom 里的配置又不一定生效。这种"两套配置各管各的"的机制，是导致这个警告反复出现、改了这里那里又冒出来的根本原因。

提示：判断当前到底是谁在编译，看输出日志的前几行。如果看到mvn相关的命令行输出，就是 Maven 在编译；如果是 IDEA 自己的 Build 输出，就是 IDEA 在编译。两者要分别配置。

2.3 父 pom 和依赖传递的隐形影响

还有一种情况：你的项目 pom 里明明没写 compiler 插件配置，但警告还是出现了。这时候要往上查——你的项目可能继承了一个父 pom，而父 pom 里配置了 1.5。

Maven 的 pom 继承机制意味着，父 pom 里的<build><plugins>配置会被子项目继承。如果父 pom 是公司内部的基础 pom，或者某个开源项目的 parent，里面锁定了老版本的编译插件和 1.5 的 source/target，那你子项目不显式覆盖的话，就会一直用 1.5。

排查方法很简单，在项目根目录执行：

mvn help:effective-pom

这个命令会打印出合并了所有继承关系之后的"最终生效 pom"。在里面搜索maven-compiler-plugin，看source和target到底是什么值。如果显示 1.5，那就找到源头了。

3. 四种解决方案的对比与选择

解决这个警告，核心就是告诉 maven-compiler-plugin 用哪个 Java 版本。但具体怎么告诉，有四种常见做法，各有适用场景。我先把它们列出来，再逐个分析。

3.1 方案一：用 properties 声明版本（最推荐）

这是最简洁、最通用的做法。在 pom 的<properties>节点里加两行：

<properties> <maven.compiler.source>8</maven.compiler.source> <maven.compiler.target>8</maven.compiler.target> </properties>

maven-compiler-plugin 会自动读取这两个属性，把它们作为 source 和 target 的值。这个机制从插件 3.0 版本开始就支持了，所以兼容性很好。

为什么推荐这个方案？因为它不依赖具体的插件配置块，即使父 pom 里配置了插件，properties 里的值通常也能覆盖（取决于父 pom 的配置方式）。而且它足够直观，任何人打开 pom 一眼就能看到项目用的 Java 版本。

把8换成你实际使用的版本，比如11、17、21。这里要注意：source 和 target 最好保持一致，不要一个 8 一个 11，否则可能出现编译能过但运行报错的情况。

3.2 方案二：直接配置编译插件

如果你需要更精细的控制，比如同时指定编码、开启某些编译参数，那就直接配置插件：

<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.11.0</version> <configuration> <source>17</source> <target>17</target> <encoding>UTF-8</encoding> </configuration> </plugin> </plugins> </build>

这个方案的好处是所有编译相关的配置都集中在一处，包括编码、source、target、是否显示警告等。缺点是配置块比较长，而且如果父 pom 里也配了这个插件，可能出现配置合并的复杂情况。

这里我特意加了<encoding>UTF-8</encoding>，因为中文项目里编码问题也是高频坑。不指定编码的话，Maven 会用平台默认编码，在 Windows 上可能是 GBK，导致中文注释乱码或者编译报错。

3.3 方案三：IDEA 设置里改（只治标）

如果你只是想让 IDEA 里的警告消失，不想动项目文件，可以在 IDEA 设置里改：

File -> Settings -> Build, Execution, Deployment -> Compiler -> Java Compiler，把Target bytecode version改成你想要的版本。

或者在File -> Project Structure -> Project里改Language level。

但这个方案有个致命问题：它只对你本地的 IDEA 生效，不改项目文件。也就是说，同事拉下代码后，警告照样出现；CI 服务器上跑 Maven 构建，警告也照样出现。所以这个方案只适合临时调试，不适合作为团队项目的正式解决方案。

3.4 方案四：升级编译插件版本

如果你的项目用的是很老的 maven-compiler-plugin（比如 2.x 或 3.0 以下），升级到新版本也能解决问题，因为新版本的默认值会跟随 JDK：

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.13.0</version> </plugin>

但升级插件版本要谨慎，因为新版本可能对某些编译行为有调整。建议先在本地跑一遍完整构建和测试，确认没问题再提交。

4. 完整实操：从排查到验证

光看方案还不够，我把完整的操作流程走一遍，你可以直接照着做。

4.1 第一步：确认当前生效的配置

在项目根目录执行：

mvn help:effective-pom | grep -A 10 "maven-compiler-plugin"

如果输出里能看到<source>1.5</source>或者压根没有 source 配置，那就确认了问题所在。同时留意插件的<version>，如果是 3.0 以下，建议一并升级。

4.2 第二步：修改 pom

打开项目根目录的 pom.xml，在<properties>里加上版本声明。假设你的 JDK 是 17：

<properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> </properties>

顺手把project.build.sourceEncoding也加上，这是 Maven 官方推荐的做法，能避免很多编码相关的诡异问题。

4.3 第三步：刷新 Maven 并重新编译

在 IDEA 右侧的 Maven 面板里点一下刷新按钮（那个循环箭头图标），或者执行：

mvn clean compile

观察输出，如果警告消失了，说明配置生效。如果还在，检查一下是不是父 pom 里用了<configuration>硬编码了 1.5，这种情况下 properties 可能覆盖不了，需要改用方案二直接配置插件。

4.4 第四步：验证字节码版本

编译完成后，可以验证一下生成的 class 文件到底是什么版本：

javap -verbose target/classes/你的类名.class | grep "major version"

major version 和 Java 版本的对应关系是：52 对应 Java 8，55 对应 Java 11，61 对应 Java 17，65 对应 Java 21。如果显示 49，那就是 Java 5，说明配置还没生效。

这个验证步骤很多人会跳过，但它能帮你确认"警告消失"和"实际生效"是两回事。有时候警告被抑制了，但字节码版本还是老的，这种"假修复"更危险。

5. 那些年我踩过的坑

5.1 改了 properties 还是报 1.5

有一次我明明在 pom 里加了maven.compiler.source=11，警告还是顽固地出现。查了半天发现，父 pom 里是这样配的：

<plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin>

父 pom 用了<configuration>硬编码，这种情况下子项目的 properties 优先级不够，覆盖不了。解决办法是在子项目的 pom 里显式重新配置这个插件，把 source/target 写死成新版本。

5.2 IDEA 缓存导致的"幽灵警告"

还有一种情况：pom 改对了，mvn compile也没警告了，但 IDEA 的 Build 输出里还是老警告。这通常是 IDEA 的缓存没刷新。解决办法是File -> Invalidate Caches -> Invalidate and Restart，重启后一般就好了。

5.3 多模块项目的配置位置

多模块项目里，properties 应该配在父 pom里，这样子模块自动继承。如果每个子模块单独配，维护起来很痛苦。但要注意，如果某个子模块需要不同的 Java 版本（比如一个模块要用 8，另一个要用 17），那就在子模块里单独覆盖。

5.4 source 和 target 不一致的坑

有人为了兼容老环境，把 source 设成 8，target 设成 11。这种配置下，编译器允许你用 Java 8 的语法，但生成 Java 11 的字节码。听起来很美好，实际上可能导致运行时行为不一致，因为某些 API 在 8 和 11 之间是有变化的。最佳实践是 source 和 target 保持一致，需要兼容低版本就都设低，需要新特性就都设高。

6. 常见问题速查

7. 关于 Java 版本选择的一点个人看法

处理完这个警告之后，很多人会纠结：到底该把 source/target 设成哪个版本？

我的经验是，跟着项目实际运行环境走，而不是跟着你本地的 JDK 走。如果你本地装了 JDK 21，但生产环境是 JDK 8，那把 source/target 设成 21 就是给自己挖坑——本地编译通过，部署上去直接UnsupportedClassVersionError。

比较稳妥的做法是：先确认生产环境的 JDK 版本，然后把 source/target 设成那个版本。如果生产环境短期内不会升级，就别贪图新语法。如果生产环境已经是 17 或 21，那就大胆用新特性，同时把编译插件的 release 参数也用上：

<plugin> <artifactId>maven-compiler-plugin</artifactId> <version>3.13.0</version> <configuration> <release>17</release> </configuration> </plugin>

<release>是 Java 9 之后引入的参数，它比 source/target 更严格——不仅控制语法和字节码版本，还会校验你调用的 API 是否真的存在于目标版本中。用<release>能避免"编译通过但运行报 NoSuchMethodError"的尴尬。不过它要求编译时的 JDK 版本不低于 release 指定的版本，所以 JDK 8 上用不了。

这个警告本身不复杂，但它背后牵扯出的"IDEA 与 Maven 双配置""父 pom 继承""字节码版本验证"这些点，才是真正值得花时间搞清楚的东西。下次再看到类似的编译警告，别急着搜"怎么消除警告"，先想想"为什么会有这个警告"，往往能顺藤摸瓜发现更多配置层面的问题。