Maven依赖冲突：引入Javax.Mail 1.6.1仍搜旧版1.4.3致类找不到

这明显是Maven依赖传递导致的版本冲突问题，在集成多个第三方库的项目里特别常见，我来给你几个实用的解决办法：

1. 先排查依赖树，找到旧版本的来源 #

先执行这条Maven命令，查看完整的依赖树，定位到底是哪个依赖偷偷引入了1.4.3版本的Javax.Mail：

mvn dependency:tree

在输出结果里搜索javax.mail相关条目，你会看到类似这样的内容：

[INFO] +- some-third-party-lib:jar:2.0.0:test
[INFO] |  \- javax.mail:mail:jar:1.4.3:test

这里的some-third-party-lib就是引入旧版本的根源。

2. 排除旧版本的传递依赖 #

找到问题依赖后，在你的Javax.Mail 1.6.1依赖声明里添加排除规则，阻止Maven自动引入旧版本：

<dependency>
    <groupId>com.sun.mail</groupId>
    <artifactId>javax.mail</artifactId>
    <version>1.6.1</version>
    <exclusions>
        <!-- 排除所有来自javax.mail组的旧版本依赖 -->
        <exclusion>
            <groupId>javax.mail</groupId>
            <artifactId>*</artifactId>
        </exclusion>
    </exclusions>
</dependency>

划重点：Javax.Mail 1.6.1的groupId已经从javax.mail迁移到了com.sun.mail，一定要确保你的依赖声明用的是正确的groupId，不然版本问题还是会出现。

3. 用DependencyManagement强制锁定版本 #

如果不想逐个排查排除，也可以在项目的pom.xml里通过dependencyManagement直接锁定Javax.Mail的版本，让所有依赖都统一使用你指定的1.6.1：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.sun.mail</groupId>
            <artifactId>javax.mail</artifactId>
            <version>1.6.1</version>
        </dependency>
    </dependencies>
</dependencyManagement>

4. 清理Maven缓存，避免旧缓存干扰 #

有时候本地仓库里的旧依赖缓存会打乱依赖解析，执行这条命令清理并重新构建：

mvn clean install -U

-U参数会强制Maven更新所有快照和依赖，确保本地仓库里的都是你指定的新版本。

做完这些步骤后，Maven就会优先使用1.6.1版本的Javax.Mail，ClassNotFoundException的问题应该就能解决了。

内容的提问来源于stack exchange，提问作者Qaddaffi