Автоконфигурация
Автоконфигурация — Spring Boot сам настраивает бины на основе того, что есть в classpath, без единой строчки явной настройки от тебя.
Пример: подключил spring-boot-starter-data-jpa и указал spring.datasource.url в application.yml — Spring Boot сам создаёт DataSource, EntityManagerFactory, TransactionManager — три сложных бина, которые без автоконфигурации пришлось бы настраивать вручную через @Bean-методы.
// без Spring Boot — пришлось бы писать руками:
@Bean
DataSource dataSource() { ... много кода настройки ... }
@Bean
EntityManagerFactory entityManagerFactory() { ... ещё больше кода ... }
// со Spring Boot — просто работает, ничего писать не нужно
Копнуть глубже
Как это работает под капотом — условные аннотации. Автоконфигурация Spring Boot построена на классах, помеченных @Conditional-аннотациями, которые проверяют, нужно ли применять конкретную настройку:
@Configuration
@ConditionalOnClass(DataSource.class) // только если в classpath есть DataSource
@ConditionalOnProperty("spring.datasource.url") // только если указан url
class DataSourceAutoConfiguration {
@Bean
DataSource dataSource() { ... }
}
Если в проекте нет зависимости на JDBC-драйвер — соответствующая автоконфигурация просто не сработает, потому что условие @ConditionalOnClass не выполнится.
Главная сила автоконфигурации — переопределяемость. Если сам создашь бин DataSource через @Bean, Spring Boot не станет создавать свой — твоя явная настройка имеет приоритет. Это значит: автоконфигурация — это разумные настройки по умолчанию, а не жёсткое навязывание, всегда можно взять контроль вручную, когда нужно что-то нестандартное.
Посмотреть, что реально включилось можно через --debug при запуске или эндпоинт Actuator /actuator/conditions — покажет, какие автоконфигурации сработали, а какие были пропущены и почему.
• как работают `@ConditionalOnClass`/`@ConditionalOnProperty` и почему свой `@Bean` всегда побеждает автоконфигурацию (если дошёл до 3-го слоя).