1. Введение
После разговора про full/lite mode уже видно безопасное правило: обычный @Bean плюс параметры метода закрывают почти всю повседневную конфигурацию. Поэтому естественный вопрос звучит наоборот: если этого уже хватает, зачем вообще существует static @Bean?
Короткий ответ: это не «более правильный @Bean» и не скрытая кнопка “ускорить Spring”. static @Bean нужен для редких случаев, когда контейнеру важно получить некоторый инфраструктурный объект очень рано, ещё до обычной жизни приложенческих singleton beans.
И тут полезно удержать основу: конфиг всё ещё остаётся composition root на стороне контейнера. Он собирает приложение, а не запускает сценарии и не живёт своей отдельной жизнью. Поэтому сначала разбираемся, где у static @Bean реальная польза, а где он только создаёт лишнюю важность на пустом месте.
2. static @Bean: смысл и уместность
Со static @Bean часто происходит забавная история. Человек впервые видит слово static рядом с @Bean, и мозг автоматически думает: «О, это наверное “правильнее”, “быстрее”, “современнее”. Надо срочно всё сделать static!» — и дальше начинаются страдания, потому что мир не любит, когда его оптимизируют без причины.
static @Bean — это просто @Bean-метод, который объявлен как static. То есть Spring может вызвать его как статический фабричный метод, не создавая экземпляр конфигурационного класса. Это влияет не на «красоту», а на момент и контекст, в котором контейнер может создать этот bean.
Синтаксически выглядит это вот так. Мы используем простой “маркер контекста”, чтобы не тащить сегодня будущие темы:
package com.example.contextflow.config.support;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
class SupportConfig {
@Bean
static ContextMarker contextMarker() {
// static @Bean: контейнер может создать этот bean без создания экземпляра конфиг-класса
// В учебном примере это просто маркер, который "помечает" контекст как ContextFlow
return new ContextMarker("contextflow");
}
}А теперь главное: по умолчанию вам почти всегда достаточно обычных (нестатических) @Bean-методов. static — это не «базовый стиль», а редкая кнопка для инфраструктуры, которой действительно нужно появиться очень рано.
Если хочется простого mental shortcut: static @Bean — это как аварийный фонарик. Полезно знать, где он лежит, но странно ходить с ним по квартире вместо нормального света.
3. Ранние инфраструктурные beans на пальцах
Сейчас аккуратно подойдём к идее “ранней инфраструктуры”, без ухода в внутренности контейнера. У Spring есть фаза, когда он ещё не живёт обычной приложенческой жизнью: читает конфигурацию, регистрирует определения и подготавливает свои внутренние механизмы. Иногда именно в этот момент ему нужны специальные помощники, которые должны появиться раньше обычных singleton beans.
И вот тут static @Bean может быть полезен: контейнер может создать такой bean, не создавая экземпляр конфигурационного класса и не цепляя лишние зависимости вокруг него.
Чтобы было нагляднее, представим это как упрощённую схему старта:
flowchart TD
A["Читаем @Configuration и компоненты"] --> B["Регистрируем BeanDefinition"]
B --> C["Готовим раннюю инфраструктуру контейнера"]
C --> D["Создаём обычные singleton beans приложения"]
D --> E["Контекст готов"]
Хороший ориентир здесь — helper-beans, которые участвуют в самой настройке контейнера. Типичный класс таких задач — post-processor-уровень: объект должен успеть появиться достаточно рано, чтобы повлиять на обработку остальных bean definitions или beans. Это совсем другой случай, чем Clock, Path, OrderIdGenerator или любая обычная прикладная инфраструктура из ContextFlow: такие объекты нужны уже приложению, а не самому контейнеру, поэтому static @Bean им не нужен.
Нам здесь достаточно увидеть именно эту границу. Как только bean нужен для обычного wiring приложения, почти наверняка хватает нормального @Bean. static появляется там, где контейнеру нужна ранняя служебная деталь, а не ещё один “обычный объект из проекта”.
4. Обычный @Bean всё ещё основной стиль
Из-за слова static легко переусердствовать и начать смотреть на конфиг как на место особых трюков. Но конфиг по‑прежнему остаётся composition root: это щиток с проводкой, а не сама кухня. Его задача — объяснить, что с чем связано, а не запускать полприложения на старте.
Поэтому рабочий default не меняется. @Bean-метод должен быть коротким: создали объект, получили зависимости параметрами, вернули объект. Как только внутри появляются баннеры, создание директорий, чтение файлов, циклы и ветвистая логика, конфиг перестаёт описывать сборку и начинает жить своей жизнью.
И если один bean зависит от другого, безопасный default остаётся тем же, что и после разговора про full/lite mode: пусть зависимость приходит параметром @Bean-метода, а не через внутренний вызов другого bean-метода.
Для текущего ContextFlow это означает очень приземлённую вещь: часы, пути, генераторы id, форматтеры, менеджеры вывода и прочая обычная прикладная инфраструктура — это всё ещё обычные beans. Им нужен честный @Bean без побочных эффектов, а не static.
5. Когда конфиги начинают пухнуть
Ещё одна ловушка рядом со static @Bean — мысль «раз я уже в конфиге, давайте сложу сюда вообще всё». Так появляется гигантский AppConfig, где рядом живут генераторы id, аудит, отчётность и непонятные helper-ы.
Лекарство тут скучное, но рабочее: раскладывать конфигурацию по ответственности. Например, держать отдельно AuditConfig, IdConfig и ReportingConfig. Это не обязательная форма текущей сборки и не новый священный канон; это просто следующий уровень аккуратности, когда явных @Bean-ов становится больше и один файл перестаёт читаться.
Минимальный рабочий вариант может оставаться коротким. Более тонкая декомпозиция нужна тогда, когда конфиг реально распухает, а не “на всякий случай”.
6. Типичные ошибки при работе со static @Bean
Ошибка №1: превращать конфигурационный класс в место выполнения действий.
Когда в @Bean-методах появляются System.out.println, создание директорий, чтение файлов, попытки “проверить доступность чего-то”, вы незаметно смешиваете сборку и работу приложения. Это приводит к сюрпризам на старте контекста и к странным эффектам в тестах. Конфиг должен создавать объекты и связывать их зависимости, а “делать дела” должны сервисы и сценарии.
Ошибка №2: думать, что static @Bean — это новый основной стиль.
Обычно это просто не нужно. Большинство прикладных beans спокойно живут как обычные @Bean-методы, и именно так их проще читать. static имеет смысл только там, где контейнеру реально нужна ранняя служебная инфраструктура.
Ошибка №3: писать длинные @Bean-методы и прятать в них полпроекта.
Очень легко начать с “чуть-чуть логики”, а потом получить мини-программу со своими ветками, try/catch и побочными эффектами. Чем больше такой логики, тем хуже читается wiring и тем труднее понять, почему контейнер собрался именно так.
Ошибка №4: после темы proxyBeanMethods снова связывать beans внутренними вызовами как teaching default.
Иногда это работает, иногда начинает зависеть от режима конфигурации и от того, что именно вы выключили или включили. Параметры @Bean-методов скучнее, но зато гораздо честнее и предсказуемее.
Ошибка №5: складывать всё в один конфиг или, наоборот, раскидывать по десятку файлов заранее.
Один гигантский AppConfig быстро становится свалкой. Но и десяток пустых конфигов “про запас” пользы не даёт. Нормальный ориентир простой: пока конфиг читается как ясная карта wiring — не дробите его силой; когда перестал читаться — раскладывайте по ответственности.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ