Problema de excepción:
Veamos primero el problema. Hoy quería copiar un proyecto que tenía Druid en un nuevo proyecto, pero este problema ocurrió inexplicablemente. ¡Es muy extraño!
java.lang.NoClassDefFoundError: org/springframework/boot/bind/RelaxedPropertyResolver
at org.springframework.boot.autoconfigure.AutoConfigurationImportSelector.getExcludeAutoConfigurationsProperty(AutoConfigurationImportSelector.java:205) ~[spring-boot-autoconfigure-1.5.22.RELEASE.jar:1.5.22.RELEASE]
at org.springframework.boot.autoconfigure.AutoConfigurationImportSelector.getExclusions(AutoConfigurationImportSelector.java:199) ~[spring-boot-autoconfigure-1.5.22.RELEASE.jar:1.5.22.RELEASE]
at org.springframework.boot.autoconfigure.AutoConfigurationImportSelector.selectImports(AutoConfigurationImportSelector.java:96) ~[spring-boot-autoconfigure-1.5.22.RELEASE.jar:1.5.22.RELEASE]
at org.springframework.context.annotation.ConfigurationClassParser$DefaultDeferredImportSelectorGroup.process(ConfigurationClassParser.java:888) ~[spring-context-5.2.2.RELEASE.jar:5.2.2.RELEASE]
at org.springframework.context.annotation.ConfigurationClassParser$DeferredImportSelectorGrouping.getImports(ConfigurationClassParser.java:874) ~[spring-context-5.2.2.RELEASE.jar:5.2.2.RELEASE]
Entonces revisé en línea y descubrí que había un conflicto de dependencia. La mayoría de las soluciones en línea eran para heredar el proyecto principal.
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.7.RELEASE</version>
</parent>
Sí, resulta útil después de agregarlo. Pero siempre resulta extraño: hay dos problemas.
Pensando en el problema
- ¿Por qué no hubo problemas para iniciar el proyecto anterior?
- Siempre siento que este método trata los síntomas pero no la causa raíz, y qué debo hacer si la gente no quiere heredarlo.
resolver el problema 1
Entonces, cuando comencé a buscar información con un problema en mente, no era más que un conflicto de dependencia, que sólo necesitaba resolver.
Primero, encuentre las dependencias en conflicto. ¿Cómo encontrarlas? La respuesta a la pregunta es 
obvia. No existe tal clase en este paquete jar.
Así que primero busque este paquete jar 
y compruébelo. De hecho, existen dos paquetes jar de este tipo. Las dos versiones son simplemente incompatibles. Según la experiencia, supongo que la versión superior del paquete jar debe tener esta clase (en realidad, vaya al proyecto anterior) Después de verificar, el proyecto anterior solo introdujo el paquete jar de 2.2.2.RELEASE),
por lo que se encontró el problema. Busque la dependencia de 1.5.22.RELEASE y excluya este paquete jar.
Encontrar dependencias también es muy simple 
. La herramienta también explica el conflicto. Es obvio
que cuando se introduce druid-spring-boot-starter, el paquete jar entra en conflicto. Quién hizo la versión más pequeña, entonces simplemente elimínela. 
Después de eliminar los conflictos del paquete jar en conflicto, inicie el proyecto
resolver el problema 2
El blogger tiene mala suerte, todavía tengo un problema, 
así que lo busqué, la solución es agregar una dependencia de jdbc.
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<version>5.2.4.RELEASE</version>
</dependency>
Después de probarlo, de hecho puede resolver el problema. Jeje, entonces lo entiendo. Todavía es un problema confiar en su propio paquete jar, así que verifiqué la biblioteca dependiente y descubrí que la versión de jdbc en mybatis-spring-
boot- El nivel de inicio era demasiado bajo, así que comencé a actualizar las dependencias
a la última versión 
y luego inicié el proyecto 
para que comenzara de manera hermosa y perfecta. 
Esta es la configuración en la que confío, puedes consultarla.
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<version>2.2.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<version>2.2.2.RELEASE</version>
<scope>test</scope>
<exclusions>
<exclusion>
<artifactId>spring-boot-autoconfigure</artifactId>
<groupId>org.springframework.boot</groupId>
</exclusion>
</exclusions>
</dependency>
<!--springboot+mybatis的依赖-->
<dependency>
<groupId>org.mybatis.spring.boot</groupId>
<artifactId>mybatis-spring-boot-starter</artifactId>
<version>2.1.2</version>
</dependency>
<!-- <dependency>-->
<!-- <groupId>org.springframework</groupId>-->
<!-- <artifactId>spring-jdbc</artifactId>-->
<!-- <version>5.2.4.RELEASE</version>-->
<!-- </dependency>-->
<!--MySQL数据库驱动-->
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.19</version>
</dependency>
<!--Lombok依赖（可以配置也可以不用配置具体看自己）-->
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.16.18</version>
</dependency>
<!--fastjson-->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>2.0.24</version>
</dependency>
<!--druid数据源-->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1.2.1</version>
</dependency>
<!--druid数据库连接池依赖-->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid-spring-boot-starter</artifactId>
<version>1.2.18</version>
<exclusions>
<exclusion>
<artifactId>spring-boot-autoconfigure</artifactId>
<groupId>org.springframework.boot</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.8.0-beta4</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-nop</artifactId>
<version>1.7.2</version>
<type>jar</type>
</dependency>
</dependencies>
Espero que esta publicación sea útil para todos.
Reponer
Por cierto, hay otra pregunta: ¿por qué mi antiguo proyecto funciona tan bien? La razón es que si hay un conflicto de dependencias, la solución de Maven es la siguiente: por ejemplo, existen las dos dependencias siguientes
:
A -> B -> C -> D(V1)
F -> G -> D(V2)
En este momento, aparecen dos versiones de D en el proyecto. En este momento, Maven adoptará el principio de ruta más corta y seleccionará la versión V2 de D, porque la versión V1 de D depende indirectamente del paquete A, y toda la dependencia La longitud de la ruta de acceso es 3, mientras que la versión V2 D depende indirectamente del paquete F y la longitud total de la ruta de dependencia es 2.
Supongamos que hay dos dependencias de la siguiente manera:
A -> B -> D(V1)
F -> G -> D(V2)
En este momento, debido a que las rutas de dependencia de las dos versiones de D tienen la misma longitud, el principio de la ruta más corta falla. La solución de Maven en este momento es: según el orden en que se declaran los paquetes dependientes en pom.xml, dar prioridad al paquete declarado primero,
yo pertenezco al segundo tipo.
Referencia: https://blog.csdn.net/WinWill2012/article/details/71717811