发送邮件出现NoSuchProviderException(smtp)异常，已尝试方案仍未解决

Hey there, I feel your frustration—dealing with exceptions that stick around even after trying all the usual fixes is the worst. Let’s break down this NoSuchProviderException for SMTP and figure out what’s going wrong.

First, a quick recap: this error almost always means the JavaMail API can’t find the implementation class for the SMTP protocol. The most common culprits are missing/mismatched dependencies, dependency conflicts, or classloading issues. Let’s go through the key checks step by step:

1. Verify Your JavaMail/Jakarta Mail Dependencies #

This is the #1 cause of this exception. You need two parts: the API jar and the actual implementation jar. And crucially, they need to be version-matched, and you can’t mix old javax.mail packages with new jakarta.mail packages.

Example Valid Dependency Sets #

For Legacy JavaMail (javax namespace):

<dependency>
    <groupId>javax.mail</groupId>
    <artifactId>mail-api</artifactId>
    <version>1.4.7</version>
</dependency>
<dependency>
    <groupId>com.sun.mail</groupId>
    <artifactId>javax.mail</artifactId>
    <version>1.4.7</version>
    <scope>runtime</scope>
</dependency>

For Jakarta Mail (modern Jakarta EE):

<dependency>
    <groupId>jakarta.mail</groupId>
    <artifactId>jakarta.mail-api</artifactId>
    <version>2.1.2</version>
</dependency>
<dependency>
    <groupId>com.sun.mail</groupId>
    <artifactId>jakarta.mail</artifactId>
    <version>2.1.2</version>
    <scope>runtime</scope>
</dependency>

Check your pom.xml to make sure you have both the API and implementation, and their versions are identical. If you only have the API jar, the runtime has no code to handle SMTP requests—that’s a super common mistake.

2. Hunt for Dependency Conflicts #

Even if you have the right dependencies, conflicting versions can break things. Run this Maven command to generate a dependency tree:

mvn dependency:tree

Search the output for any entries related to mail or jakarta.mail. If you see multiple versions of the same artifact (e.g., one from your project, one pulled in by another dependency), you’ll need to exclude the conflicting one. For example, if a third-party library brings in an old JavaMail version:

<dependency>
    <groupId>some.thirdparty</groupId>
    <artifactId>their-library</artifactId>
    <version>x.y.z</version>
    <exclusions>
        <exclusion>
            <groupId>javax.mail</groupId>
            <artifactId>mail-api</artifactId>
        </exclusion>
    </exclusions>
</dependency>

3. Double-Check Your Code Configuration #

While less likely, a typo or misconfiguration can sometimes trigger this error:

• Make sure you’re requesting the SMTP provider correctly (no typos!):

  // Correct
  Transport transport = session.getTransport("smtp");
  // Wrong (typo)
  Transport transport = session.getTransport("smt");
  

• Ensure your Session properties don’t accidentally override the provider lookup (though this is rare). Stick to standard properties like mail.smtp.host, mail.smtp.port, etc.

4. Check Classloading (For Web/Containerized Apps) #

If you’re running this in a web app (like Tomcat) or a container:

• Ensure your dependencies are in the right place (e.g., WEB-INF/lib for WAR files). Don’t rely on container-provided JavaMail versions unless you’re 100% sure they match your project’s API.
• If the container does provide a JavaMail implementation, mark your project’s dependency as <scope>provided</scope>—but only if the versions are compatible. If not, you may need to configure the container to use your project’s jars instead.

Since your pom.xml snippet cuts off, it’s hard to spot exact issues there. If you can share the full pom.xml or the output of mvn dependency:tree, we can zero in on the problem faster.

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