اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
Java
رفتن به کانال در Telegram
Самая актуальная информация по Java По всем вопросам- @haarrp @itchannels_telegram - 🔥лучшие каналы @pythonl - 🐍 @ai_machinelearning_big_data- ml @ArtificialIntelligencedl - AI @datascienceiot - ds @pythonlbooks 📚 РКН: clck.ru/3FmwKr #VRHSZ
نمایش بیشتر📈 تحلیل کانال تلگرام Java
کانال Java (@javatg) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 16 873 مشترک است و جایگاه 7 863 را در دسته فناوری و برنامهها و رتبه 39 922 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 16 873 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 14 ژوئن, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر -97 و در ۲۴ ساعت گذشته برابر -1 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 15.50% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 6.80% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 2 616 بازدید دریافت میکند. در اولین روز معمولاً 1 148 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 17 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند github, void, api, kotlin, static تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“Самая актуальная информация по Java
По всем вопросам- @haarrp
@itchannels_telegram - 🔥лучшие каналы
@pythonl - 🐍
@ai_machinelearning_big_data- ml
@ArtificialIntelligencedl - AI
@datascienceiot - ds
@pythonlbooks 📚
РКН: clck.ru/3FmwKr
#VR...”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 15 ژوئن, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
16 873
مشترکین
-124 ساعت
+257 روز
-9730 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئن '26
ژوئن '26
+83
در 0 کانالها
مه '26
+70
در 1 کانالها
Get PRO
آوریل '26
+66
در 1 کانالها
Get PRO
مارس '26
+320
در 22 کانالها
Get PRO
فوریه '26
+180
در 46 کانالها
Get PRO
ژانویه '26
+378
در 127 کانالها
Get PRO
دسامبر '25
+153
در 3 کانالها
Get PRO
نوامبر '25
+205
در 43 کانالها
Get PRO
اکتبر '25
+103
در 13 کانالها
Get PRO
سپتامبر '25
+139
در 38 کانالها
Get PRO
اوت '25
+375
در 9 کانالها
Get PRO
ژوئیه '25
+432
در 76 کانالها
Get PRO
ژوئن '25
+452
در 73 کانالها
Get PRO
مه '25
+251
در 1 کانالها
Get PRO
آوریل '25
+217
در 28 کانالها
Get PRO
مارس '25
+208
در 1 کانالها
Get PRO
فوریه '25
+220
در 41 کانالها
Get PRO
ژانویه '25
+311
در 43 کانالها
Get PRO
دسامبر '24
+600
در 64 کانالها
Get PRO
نوامبر '24
+1 051
در 189 کانالها
Get PRO
اکتبر '24
+1 867
در 68 کانالها
Get PRO
سپتامبر '24
+719
در 202 کانالها
Get PRO
اوت '24
+663
در 42 کانالها
Get PRO
ژوئیه '24
+768
در 52 کانالها
Get PRO
ژوئن '24
+867
در 58 کانالها
Get PRO
مه '24
+486
در 36 کانالها
Get PRO
آوریل '24
+817
در 46 کانالها
Get PRO
مارس '24
+777
در 21 کانالها
Get PRO
فوریه '24
+775
در 5 کانالها
Get PRO
ژانویه '24
+811
در 46 کانالها
Get PRO
دسامبر '23
+156
در 38 کانالها
Get PRO
نوامبر '23
+3 105
در 57 کانالها
Get PRO
اکتبر '23
+203
در 20 کانالها
Get PRO
سپتامبر '23
+484
در 0 کانالها
Get PRO
اوت '23
+1 199
در 0 کانالها
Get PRO
ژوئیه '23
+1 849
در 0 کانالها
Get PRO
ژوئن '23
+646
در 0 کانالها
Get PRO
مه '23
+615
در 0 کانالها
Get PRO
آوریل '23
+1 217
در 0 کانالها
Get PRO
مارس '23
+3 950
در 0 کانالها
Get PRO
فوریه '23
+330
در 0 کانالها
Get PRO
ژانویه '23
+2 306
در 0 کانالها
Get PRO
دسامبر '22
+640
در 0 کانالها
Get PRO
نوامبر '22
+488
در 0 کانالها
Get PRO
اکتبر '22
+751
در 0 کانالها
Get PRO
سپتامبر '22
+628
در 0 کانالها
Get PRO
اوت '22
+197
در 0 کانالها
Get PRO
ژوئیه '22
+923
در 0 کانالها
Get PRO
ژوئن '22
+339
در 0 کانالها
Get PRO
مه '22
+1 180
در 0 کانالها
Get PRO
آوریل '22
+823
در 0 کانالها
Get PRO
مارس '22
+3 055
در 0 کانالها
Get PRO
فوریه '22
+928
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 15 ژوئن | +2 | |||
| 14 ژوئن | +5 | |||
| 13 ژوئن | +10 | |||
| 12 ژوئن | +12 | |||
| 11 ژوئن | +10 | |||
| 10 ژوئن | +5 | |||
| 09 ژوئن | +8 | |||
| 08 ژوئن | +10 | |||
| 07 ژوئن | +4 | |||
| 06 ژوئن | +5 | |||
| 05 ژوئن | +8 | |||
| 04 ژوئن | +3 | |||
| 03 ژوئن | 0 | |||
| 02 ژوئن | +1 | |||
| 01 ژوئن | 0 |
پستهای کانال
⚡️ Бинарный поиск, который вы выучили, скорее всего, был неправильным.
Джон Бентли опубликовал реализацию бинарного поиска в *Programming Pearls* после того, как доказал её корректность и протестировал.
Баг прожил почти 20 лет.
Позже Джошуа Блох нашёл точно такую же ошибку в реализации бинарного поиска, которую сам написал для JDK.
Исследование 1988 года показало: корректный бинарный поиск был только в 5 из 20 учебников.
Ошибка проявляется только на массивах размером
2^30 элементов и больше.
Проблема возникает при вычислении середины:
mid = (low + high) / 2;
low + high может вызвать переполнение.
Правильнее писать так:
mid = low + (high - low) / 2;
ArrayIndexOutOfBoundsException.
Та же ошибка затрагивала mergesort и огромное количество других алгоритмов «разделяй и властвуй».| 2 | 🖥 Java постепенно закручивает гайки вокруг мутации final-полей через reflection.
В JDK 26 появятся предупреждения, если код меняет final-поля через Reflection API. Это часть движения к тому, чтобы final снова означал реальную неизменяемость, а не «почти immutable, пока кто-то не сделал setAccessible(true)».
Проблема старая: фреймворки, сериализация, DI и cloning часто создавали «пустой» объект, а потом дописывали поля напрямую. Для final это ломает саму идею конструктора, инвариантов и безопасной инициализации.
Что предлагает Java-команда вместо этого:
- использовать constructor injection вместо field injection
- восстанавливать объекты через конструкторы или static factory
- для сериализации чаще выбирать records
- применять serialization proxy / readResolve
- не полагаться на порядок полей в reflection
- не превращать private-поля в скрытый публичный протокол
- менять final через reflection только как крайний случай
Самый практичный вывод для Java-разработчиков: если ваша библиотека, фреймворк или приложение «оживляет» объекты через reflection, пора проверить этот код заранее. Сегодня это может быть просто warning, завтра - реальное ограничение.
https://inside.java/2026/04/27/avoiding-final-field-mutation/
#java | 2 060 |
| 3 | 🔴 Завтра тестовое собеседование с Java-разработчиком
10 июня(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Java-разработчика.
Как это будет:
📂 Виктор Анохин, старший разработчик из WildBerries, будет задавать реальные вопросы и задачи разработчику-добровольцу
📂 Виктор будет комментировать каждый ответ респондента, чтобы дать понять чего от вас ожидает собеседующий на интервью
📂 В конце можно будет задать любой вопрос Виктору
Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.
Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot
Реклама.
О рекламодателе. | 1 709 |
| 4 |  Java-совет, который кажется мелочью, пока кто-то не сломает вам состояние объекта.
Не возвращайте наружу изменяемые внутренние коллекции.
Плохой вариант:
```java
public List<String> getMembers() {
return members;
}
Так вызывающий код получает прямой доступ к вашему внутреннему списку. После этого он может сделать:
team.getMembers().clear();
И внезапно вся команда исчезла. Не через метод доменной модели, не через проверку прав, не через бизнес-логику, а просто потому что геттер отдал наружу ссылку на mutable state.
Нормальный вариант:
public List<String> getMembers() {
return Collections.unmodifiableList(members);
}
Или, если нужен безопасный снимок:
public List<String> getMembers() {
return List.copyOf(members);
}
Разница важная:
* unmodifiableList даёт read-only view поверх текущей коллекции
* List.copyOf создаёт неизменяемую копию на момент вызова
Это защищает инварианты объекта и оставляет вам свободу менять внутреннюю реализацию. Сегодня внутри может быть ArrayList, завтра Set, послезавтра вообще другая структура. Внешний код не должен зависеть от того, как именно вы храните данные внутри.
Геттер коллекции - не просто «получить список». Это граница инкапсуляции. Если отдали mutable-ссылку наружу, объект уже не полностью контролирует своё состояние.
#java #javadev | 1 631 |
| 5 |  💡 Java: вложенные if-else быстро превращают код в лабиринт
Когда вся логика уходит в глубокую вложенность, читать метод становится больно: основной сценарий спрятан где-то внизу, а перед ним несколько уровней проверок.
Проще использовать guard clauses - ранние проверки с выходом из метода.
Было:
- проверяем user
- внутри проверяем active
- внутри проверяем order
- внутри проверяем paid
- только потом выполняем основное действие
Стало:
- если user == null - сразу ошибка
- если user неактивен - сразу ошибка
- если order == null - сразу ошибка
- если order не оплачен - сразу ошибка
- основная логика остаётся плоской и читаемой
Такой код легче:
- читать
- тестировать
- ревьюить
- расширять без превращения метода в пирамиду из if
Guard clauses - маленький приём, который сильно улучшает чистоту кода. | 2 338 |
| 6 |  📌 Magic numbers в Java - мелкая привычка, которая потом превращает поддержку кода в археологию.
Когда в коде встречается 86400, 7, 1.21 или 5000, компилятору всё равно. Человеку - нет. Через месяц уже приходится вспоминать, что это было: секунд в дне, дней сессии, НДС или задержка перед повторной попыткой.
Плохой вариант выглядит так:
if (sessionAgeSeconds > 86400 * 7)
Формально код работает. Но смысл спрятан внутри чисел.
Нормальный вариант:
SECONDS_PER_DAY
SESSION_DAYS
VAT_RATE
RETRY_DELAY_MS
Теперь намерение видно прямо в месте вызова. Не нужно угадывать, почему именно 7, что означает 5000 и можно ли безопасно поменять значение.
Это особенно важно в бизнес-логике, где числа редко бывают случайными. Лимиты, комиссии, таймауты, скидки, сроки жизни сессии, количество попыток - всё это правила продукта, а не просто цифры в коде.
Хорошее правило простое: если число несёт смысл, дай ему имя. Исключения вроде 0, 1, индексов и простых счётчиков можно не трогать.
Чистый код часто начинается не с архитектуры, а с таких скучных вещей: убрать загадочные числа и оставить будущему разработчику понятный контекст.
#java #cleancode | 3 372 |
| 7 | Митап для Java-разработчиков — 18 июня, Екатеринбург
В программе 2 доклада от бэкендеров Яндекс Вертикалей про неочевидные продакшн-баги в Java и Spring, переход на Temporal:
🟥 NullPointerException на инициализированном final-поле. Как такое вообще возможно? Расскажет Михаил Черноскутов из Яндекс Путешествий
🟥Переезд со scheduler-сервисов на Temporal. Зачем он понадобился и какие были подводные камни, ответит Герман Михайлов из Яндекс Недвижимости
После выступлений участников ждёт «Громкий вопрос» — интеллектуальная игра по мотивам одноимённого шоу. А также нетворкинг с коллегами и единомышленниками.
🗓18 июня (четверг), 18:00 — 22:00
📍 Ельцин Центр, Екатеринбург
→ Подробности и регистрация | 2 833 |
| 8 |  🖥 Java наконец начал подстраховывать разработчика там, где раньше легко прятались баги.
В switch expression начиная с Java 14+ компилятор проверяет, что обработаны все возможные значения. Если у вас enum и вы забыли один из вариантов, код просто не соберётся.
Это даёт сразу несколько плюсов:
- меньше скрытых багов после рефакторинга
- безопаснее расширять enum
- компилятор сам ловит забытые кейсы
Например, добавили в Status новое значение FAILED, но не обновили switch - получите ошибку компиляции, а не сюрприз в рантайме.
По сути это маленькая фича, которая экономит много нервов: чем больше проверяет компилятор, тем меньше потом искать ошибки руками. | 2 568 |
| 9 | Docker и Kubernetes: основы разработки под облачную инфраструктуру
Курс для тех, кто хочет держать свой стэк и знания актуальными и глубоко разбираться, как устроены Docker, Kubernetes, и современная облачная инфраструктура в целом.
🌐 Чему вы научитесь:
🤩 Создавать облачную инфраструктуру «с нуля» управление и конфигурация серверов с Terraform, Ansible, cloud‑init
🤩 Уверенно работать с Docker: Dockerfile, слои, кэш, многоступенчатые сборки, реестры, безопасность, air‑gapped
🤩 Проектировать многоконтейнерные приложения: паттерны Sidecar, Ambassador, Adapter, проверки (liveness/readiness), DaemonSet и поды
🤩 Настраивать сеть и балансировку в Kubernetes
ClusterIP, Services, Ingress, MetalLB, TLS/SNI, сервис‑меши (Istio)
🤩 Организовывать хранение данных: PersistentVolumes / PVC, StorageClasses, резервное копирование. Упаковка в Helm и поддержка через Operator
🥸 Кто мы: R&D-центр Devhands. Автор курса — Николай Ихалайнен, эксперт по СУБД и бекенду (ex-Percona), со-основатель MyDB, энтузиаст открытого ПО.
🗓 Старт курса: 10 июня, 6 недель обучения.
Изучить программу и записаться можно здесь.
Ждем вас!
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzqxNnFKA | 2 193 |
| 10 |  Spring Boot: когда нужно контролировать HTTP-ответ полностью
Если обычного return user уже мало, в Spring Boot есть ResponseEntity<T>.
Он позволяет явно управлять всем ответом:
• статусом HTTP
• заголовками
• телом ответа
• обработкой ошибок
• поведением API в нестандартных сценариях
Пример: пользователь найден - возвращаем 200 OK, тело ответа и кастомный header.
Пользователь не найден - возвращаем 404 NOT FOUND без лишней магии.
Это особенно полезно, когда API должен быть предсказуемым: фронтенд, мобильное приложение или внешний клиент получают не просто JSON, а нормальный контракт ответа.
ResponseEntity<T> - маленькая деталь, которая делает Spring Boot API заметно аккуратнее. | 2 176 |
| 11 | Java-ошибка, которую лучше ловить на компиляции, а не в проде
В Java @Override - это не украшение над методом, а простая защита от глупых ошибок.
Представь базовый класс:
class Report {
void print() {
// ...
}
}
Ты хочешь переопределить метод, но случайно пишешь prnt() вместо print():
class PDFReport extends Report {
void prnt() {
// ...
}
}
Код скомпилируется. Но метод print() не переопределён. Ты просто создал новый метод с опечаткой, а старое поведение осталось на месте.
А теперь добавляем @Override:
class PDFReport extends Report {
@Override
void prnt() {
// ...
}
}
И компилятор сразу скажет: такого метода в родительском классе нет, переопределять нечего.
Вот почему @Override стоит писать всегда, когда переопределяешь метод. Это маленькая аннотация, которая превращает скрытый баг в обычную ошибку компиляции. | 2 529 |
| 12 |  🚀 Request ID в Spring Boot - мелочь, которая спасает часы дебага
Когда API начинает сыпаться ошибками, главный вопрос не «что сломалось», а «где именно сломалось».
Request ID решает эту боль просто: каждому входящему запросу выдаётся уникальный идентификатор, который потом проходит через логи, заголовки и внутренние вызовы.
В итоге можно быстро найти весь путь конкретного запроса:
• где он пришёл
• какой сервис его обработал
• на каком шаге появилась ошибка
• какие логи относятся именно к нему
• что вернуть клиенту или поддержке для расследования
В Spring Boot это часто делают через OncePerRequestFilter: генерируем UUID, кладём его в request attribute и добавляем в ответ заголовок X-Request-ID.
Это не делает систему быстрее. Зато делает её наблюдаемой.
А в продакшене наблюдаемость часто важнее красивой архитектуры на схеме. | 2 688 |
| 13 |  Spring Boot: уберите try/catch из контроллеров
В Spring Boot не нужно размазывать обработку ошибок по каждому endpoint через бесконечные try/catch.
Для этого есть @RestControllerAdvice.
Идея простая: вы выносите обработку исключений в один глобальный класс, а контроллеры оставляете чистыми.
Например:
@RestControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(ResourceNotFoundException.class)
public ResponseEntity<?> handleNotFound(ResourceNotFoundException ex) {
return ResponseEntity
.status(HttpStatus.NOT_FOUND)
.body(new ErrorResponse("NOT_FOUND", ex.getMessage()));
}
@ExceptionHandler(IllegalArgumentException.class)
public ResponseEntity<?> handleBadRequest(IllegalArgumentException ex) {
return ResponseEntity
.badRequest()
.body(new ErrorResponse("BAD_REQUEST", ex.getMessage()));
}
@ExceptionHandler(Exception.class)
public ResponseEntity<?> handleGeneric(Exception ex) {
return ResponseEntity
.status(HttpStatus.INTERNAL_SERVER_ERROR)
.body(new ErrorResponse("INTERNAL_ERROR", "Something went wrong"));
}
}
После этого контроллер может выглядеть спокойно:
@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
return userService.findById(id);
}
Если пользователь не найден - сервис кидает ResourceNotFoundException, а Spring сам отправит нормальный 404.
Что это даёт:
• меньше мусора в контроллерах
• единый формат ошибок
• проще поддерживать API
• легче логировать исключения
• меньше копипасты в endpoint-ах
Контроллер должен описывать сценарий запроса, а не превращаться в свалку обработки ошибок. | 2 849 |
| 14 |  Spring Boot магия, которая на самом деле просто проверка classpath.
@ConditionalOnClass - одна из тех аннотаций, из-за которых Spring Boot кажется умным.
Она говорит фреймворку:
«Включи этот bean или конфигурацию только если нужный класс реально есть в проекте».
Простой пример:
@Configuration
@ConditionalOnClass(DataSource.class)
public class DataSourceAutoConfiguration
{
// загружается только если доступен javax.sql.DataSource
}
То есть Spring Boot не пытается настраивать всё подряд.
Он смотрит:
• есть ли нужная библиотека в зависимостях
• доступен ли конкретный класс
• можно ли безопасно включить автоконфигурацию
Именно поэтому ты добавляешь starter - и внезапно появляется конфигурация для базы, Redis, Kafka, Web MVC или Security.
Не потому что Spring «угадал».
А потому что нужные классы появились в classpath, и условия автоконфигурации стали true.
В этом и есть главный принцип Spring Boot:
меньше ручной настройки, больше условий, которые включаются только когда проект к ним готов. | 2 575 |
| 15 | Код на скорости: митап про производительность, ИИ-агенты и бизнес-процессы в Омске! ⚡️
Встречаемся уже 28 мая, чтобы разобраться:
✔️ Как выкрутить на максимум производительность продукта без больших затрат. Спойлер: помогут виртуальные потоки и корутины (можно сделать скрытым текстом).
✔️ Как создать ИИ-агента, который анализирует сбои и борется с мошенничеством.
✔️ Как моделировать процессы в BPMN так, чтобы минимизировать ошибки.
В финале митапа — крутой «мафиозно-квизный» нетворкинг.
Дата: 28 мая в 18:00
Место: Школа 21 (ул. Ленина, д. 26Б)
Регистрация: здесь! | 2 345 |
| 16 |  N+1 в Spring Boot выглядит безобидно, пока прод не начинает молиться на базу данных.
Классический сценарий:
Вы грузите список заказов:
orderRepository.findAll()
А потом в цикле обращаетесь к order.getItems().
Hibernate сначала делает один запрос за заказами, а потом ещё по одному запросу на каждый заказ, чтобы достать items.
100 заказов = 101 SQL-запрос.
И вот здесь спасает @EntityGraph.
Он позволяет явно сказать репозиторию, какие связи нужно подтянуть сразу:
@EntityGraph(attributePaths = {"items"})
В итоге Hibernate может сгенерировать один запрос с JOIN, вместо десятков лишних походов в базу.
Что получаем:
- меньше SQL-запросов
- меньше нагрузки на БД
- чище код репозитория
- без ручного JPQL
- fetch-стратегия управляется точечно под конкретный кейс
LAZY сам по себе не зло. Зло - когда вы не контролируете, где и как он срабатывает.
@EntityGraph - один из самых простых способов держать N+1 под контролем в Spring Boot. | 6 639 |
| 17 | Твой код — в сердце мощного ИИ! 💚
Команда GigaChat зовёт на One Day Offer амбициозных Java-разработчиков, которые готовы создавать AI‑продукты уровня BigTech и стать частью крупнейшего AI-комьюнити.
Если ты дружишь с Java (версии 8–25), ладишь со Spring и Hibernate, а PostgreSQL и ClickHouse для тебя — не просто слова, переходи по ссылке и занимай слот на One Day Offer.
Встречаемся 23 мая — очень ждём именно тебя! | 2 766 |
| 18 |  Небольшой, но полезный совет для Spring Boot.
Если у вас есть scheduled task, не стоит хардкодить интервал прямо в аннотации:
`@Scheduled(fixedRate = 5000)`
Лучше вынести значение в конфиг:
`@Scheduled(fixedRateString = "${task.interval}")`
А в application.properties указать:
`task.interval=5000`
Почему так лучше:
• интервал можно менять без правки кода;
• настройки проще различать для dev, staging и production;
• меньше магических чисел в бизнес-логике;
• конфигурация становится прозрачнее.
Мелочь, но именно из таких мелочей и складывается нормальная поддерживаемость Spring Boot-проекта. | 2 491 |
| 19 |  ⚡️ CORS в Spring Boot: не лечите это костылями на фронте
Если frontend и backend живут на разных доменах или портах, браузер начнет резать запросы по CORS. Это не баг Spring Boot и не проблема React. Это нормальный механизм безопасности браузера.
Правильный способ - настроить CORS на стороне backend.
В Spring Boot это можно сделать глобально через WebMvcConfigurer: указать маршруты, разрешенные origins, HTTP-методы, заголовки и работу с credentials.
Главное - не ставить бездумно * везде подряд, особенно если используете cookies, токены или allowCredentials(true). В проде лучше явно перечислять доверенные домены, например frontend-домен приложения.
Такой подход дает централизованный контроль: вы один раз задаете политику CORS и не размазываете настройки по каждому контроллеру.
Для Java backend-разработчика это базовая, но важная вещь: CORS должен быть частью архитектуры API, а не случайной правкой перед деплоем. | 2 813 |
| 20 |  ✔️ Spring Boot может тормозить сам себя из-за одного неаккуратного @ComponentScan
В Spring Boot не стоит бездумно писать что-то вроде:
@ComponentScan("com.mycompany")
На первый взгляд удобно: фреймворк сам просканирует весь пакет и найдет нужные компоненты. Но проблема в том, что он может просканировать слишком много.
Это увеличивает время classpath scanning, замедляет старт приложения и иногда подтягивает классы, которые вообще не должны были становиться Spring-компонентами.
Лучший вариант - полагаться на дефолтное поведение:
@SpringBootApplication
public class MyApplication { }
По умолчанию Spring Boot сканирует только подпакеты того пакета, где лежит MyApplication.
Если нужно явно ограничить область сканирования, указывай конкретные подпакеты:
@ComponentScan({
"com.mycompany.myapp.product",
"com.mycompany.myapp.order"
})
Главная мысль простая: @ComponentScan должен быть точным. Чем шире границы сканирования, тем больше лишней работы делает приложение на старте.
#SpringBoot #JavaDev #Java #Backend | 2 981 |
