Spring Boot应用启动失败：dispatcherServlet Bean冲突及类缺失问题

你碰到的是Spring Boot自动配置与第三方Jar依赖冲突的典型场景，咱们一步步拆解问题并给出可行的解决方案：

问题根源拆解 #

1. BeanDefinitionOverrideException（dispatcherServlet重复定义） #

第三方Jar里的ASRAutoConfiguration类，和Spring Boot自带的DispatcherServletConfiguration都定义了名为dispatcherServlet的Bean。而Spring Boot 2.x版本默认禁用了Bean覆盖功能（spring.main.allow-bean-definition-overriding默认值为false），所以启动时直接抛出重复定义的异常。

你尝试开启Bean覆盖的思路没问题，但触发了第二个更隐蔽的问题——第三方Jar依赖了Spring Boot 1.x的旧API。

2. 找不到org.springframework.boot.context.embedded.EmbeddedServletContainerCustomizer #

这个类在Spring Boot 2.x版本中已经被完全重构：新的类是org.springframework.boot.web.servlet.server.ServletWebServerFactoryCustomizer，包路径和类名都发生了变化。第三方Jar显然是基于Spring Boot 1.x开发的，当你启用Bean覆盖后，ASRAutoConfiguration被加载，它引用的旧类在你的Spring Boot 2.3.1环境中不存在，因此抛出类找不到的错误。

最优解决方案 #

方案1：排除第三方Jar的冲突自动配置类（优先推荐） #

直接阻止冲突的ASRAutoConfiguration被Spring加载，从根源上避免重复Bean问题，自然也不会触发后续的类找不到错误。

方法A：通过启动类注解排除

在你的PetClinicApplication启动类上添加exclude属性，替换为ASRAutoConfiguration的实际全类名（比如com.thirdparty.asr.ASRAutoConfiguration，需要从第三方Jar中确认路径）：

@SpringBootApplication(exclude = ASRAutoConfiguration.class)
public class PetClinicApplication {
    public static void main(String[] args) {
        SpringApplication.run(PetClinicApplication.class, args);
    }
}

方法B：通过配置文件排除

如果不想修改代码，可以在application.properties中添加配置：

spring.autoconfigure.exclude=com.thirdparty.asr.ASRAutoConfiguration

同样需要替换为ASRAutoConfiguration的实际全类名。

方案2：升级第三方Jar到兼容Spring Boot 2.x的版本 #

如果第三方Jar提供了适配Spring Boot 2.x的版本，优先选择升级。这能从根本上解决API依赖不兼容的问题，比临时规避手段更稳定可靠。

方案3：临时适配旧API（仅作为最后手段） #

如果无法排除冲突配置类，也找不到兼容的第三方Jar版本，可以手动创建适配类模拟旧API的行为，但这需要了解第三方Jar使用该类的具体逻辑，容易引入新问题。示例如下（仅作参考）：

import org.springframework.boot.web.servlet.server.ServletWebServerFactoryCustomizer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

// 模拟旧的EmbeddedServletContainerCustomizer类，让第三方Jar能找到它
@Configuration
public class LegacyServletContainerCustomizerAdapter {

    @Bean
    public org.springframework.boot.context.embedded.EmbeddedServletContainerCustomizer embeddedServletContainerCustomizer() {
        return container -> {
            // 根据第三方Jar的需求添加自定义逻辑，或适配到新的Customizer
            ServletWebServerFactoryCustomizer newCustomizer = new ServletWebServerFactoryCustomizer();
            // 此处补充转换逻辑...
        };
    }
}

总结 #

优先选择方案1排除冲突配置类，如果第三方Jar的ASR功能是业务必需的，再考虑方案2升级Jar版本，最后才尝试方案3的临时适配。这样能最小化代码改动，保证应用稳定启动。

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