Spring Boot: автоконфигурация и starters

@SpringBootApplication и запуск

@SpringBootApplication — это мета-аннотация, объединяющая три: @SpringBootConfiguration (вариант @Configuration), @EnableAutoConfiguration (включает автоконфигурацию) и @ComponentScan (сканирует пакет приложения и ниже).

SpringApplication.run поднимает ApplicationContext, запускает встроенный сервер и применяет автоконфигурацию. Философия Boot — convention over configuration: разумные умолчания из коробки, которые при необходимости переопределяются.

Starters и версии зависимостей

Starter (spring-boot-starter-web, -data-jpa, -security…) — это курируемый набор согласованных зависимостей под задачу: подключив один, вы получаете все нужные библиотеки совместимых версий.

Версии при этом не указывают вручную — ими управляет Spring Boot BOM (dependency management). Это убирает «ад зависимостей» и несовместимости версий, типичные для ручной сборки classpath.

Механизм автоконфигурации

@EnableAutoConfiguration загружает список классов-автоконфигураций из META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (в старых версиях — из spring.factories). Каждая автоконфигурация — это обычный @Configuration, обвешанный условиями: @ConditionalOnClass (нужный класс есть на classpath), @ConditionalOnMissingBean, @ConditionalOnProperty.

Логика проста и предсказуема: «если на classpath есть, например, H2 и Spring JDBC, а пользователь сам не настроил DataSource — настройте его за него». Никакой магии: всё это обычные бины под условиями.

Переопределение умолчаний

Ключ к управляемости — @ConditionalOnMissingBean: автоконфигурация создаёт бин ТОЛЬКО если такого бина ещё нет. Поэтому, объявив свой бин (например, собственный ObjectMapper или DataSource), вы автоматически замещаете дефолт Boot — без отключения чего-либо.

Если нужно убрать конкретную автоконфигурацию целиком — её исключают через @SpringBootApplication(exclude = ...). Так «convention over configuration» остаётся под контролем.

Внешняя конфигурация и приоритеты

Настройки задают в application.yml/properties, а читают точечно через @Value("${...}") или, предпочтительно, типобезопасно через @ConfigurationProperties (группа свойств в объект, с валидацией и relaxed binding: APP_NAME, app.name, app-name связываются с одним полем).

Источники свойств имеют приоритет (от высшего к низшему, упрощённо): аргументы командной строки → переменные окружения → application-{profile} → application. Профили (@Profile, spring.profiles.active) переключают наборы бинов и файлы application-{profile}.yml под dev/test/prod без правки кода.

@ConfigurationProperties(prefix = "app")
record AppProps(String name, int retries) {} // app.name, app.retries из yml

Отладка автоконфигурации

Когда непонятно, почему бин появился или нет, запускают с флагом --debug (или свойством debug=true): Boot печатает ConditionsEvaluationReport — какие автоконфигурации применились (positive matches) и какие отклонены и по какому условию (negative matches).

Это превращает «магию» в читаемый отчёт и снимает большинство вопросов «откуда взялся этот бин».

Как отвечать на собеседовании

Разложите @SpringBootApplication на три аннотации, объясните starters + BOM (согласованные версии). Главное — механизм автоконфигурации: список из AutoConfiguration.imports + @ConditionalOnClass/OnMissingBean/OnProperty, и переопределение через @ConditionalOnMissingBean (свой бин замещает дефолт). Добавьте приоритеты источников конфигурации и @ConfigurationProperties с relaxed binding, и упомяните --debug/ConditionsEvaluationReport.