Understanding the Priority and Interaction of SpringBootApplication, ComponentScan, and MapperScan Annotations

SpringBoot provides three ways to configure package scanning on the main application class: @SpringBootApplication, @ComponentScan, and @MapperScan. The article presents a sample code snippet where all three annotations are used together and raises the question of their effective priority and differences.

@SpringBootApplication(scanBasePackages = {"a", "b"})
@ComponentScan(basePackages = {"a", "b", "c"})
@MapperScan({"XXX"})
public class XXApplication extends SpringBootServletInitializer {}

@SpringBootApplication is a meta‑annotation that combines @Configuration, @EnableAutoConfiguration, and @ComponentScan. By default it scans the package of the startup class and its sub‑packages, but you can override the scan path with the scanBasePackages attribute. To scan third‑party JAR packages, you must add an explicit @ComponentScan , because the default scan does not include external JAR directories.

@ComponentScan is a core Spring annotation that defines the component‑scan base packages. When present, it overrides the default scan path of @SpringBootApplication, causing the latter’s default behavior to be disabled. If the basePackages value does not contain the startup class’s package, none of the project’s own components will be detected.

The article illustrates two failure cases: (1) when @ComponentScan only includes the default package, the annotation becomes ineffective and SpringBootApplication works; (2) when @ComponentScan specifies multiple sub‑directories, SpringBootApplication’s scan is ignored and only the explicitly listed directories are scanned, leaving controllers outside those directories inaccessible.

Another code example shows the effect of adding an empty @ComponentScan after @SpringBootApplication, which disables the scanBasePackages attribute of @SpringBootApplication.

@SpringBootApplication(scanBasePackages = {})
@ComponentScan(basePackages = {})

@MapperScan belongs to MyBatis and automatically registers all DAO interfaces in the specified packages as BaseMapper beans, injecting them into the Spring context without additional annotations.

The author concludes that using @SpringBootApplication and @ComponentScan together can cause the former to lose its scanning effect, a behavior confirmed after extensive testing, and that understanding this interaction resolves common confusion about SpringBoot package scanning.