Почему не рекомендуется использовать аннотацию @Data в Lombok

Что проверяют

Знаете ли вы, что именно разворачивает @Data, и понимаете ли, почему это опасно на сущности JPA. Вопрос почти всегда ведёт к Hibernate, даже если Hibernate в нём не упомянут.

Как отвечать

@Data это пачка: @Getter, @Setter, @ToString, @EqualsAndHashCode и @RequiredArgsConstructor. Проблемы ровно в трёх последних.

equals и hashCode по всем полям ломают контракт для сущности: пока объект не сохранён, идентификатор пуст, после сохранения хеш меняется, и объект теряется в HashSet. Вдобавок сравнение обращается к ленивым связям, а это лишние запросы или LazyInitializationException вне сессии. Для сущности правильнее равенство по бизнес-ключу либо по идентификатору с постоянным hashCode.

toString по всем полям тянет коллекции в логи, зацикливается на двусторонней связи и печатает то, чему в логе не место: телефоны, токены, адреса.

Сеттеры на каждое поле делают модель изменяемой: инварианты не удержать, объект живёт в половинчатом состоянии. Для неизменяемых данных есть @Value или обычный record.

Вывод формулировать не запретом, а границей: на плоском DTO без связей @Data удобен и безопасен, на сущности берут точечные @Getter и @Setter, @EqualsAndHashCode(onlyExplicitlyIncluded = true) и @ToString с исключениями.

Где спотыкаются

Объясняют вред производительностью и рефлексией. Lombok работает на этапе компиляции, в байткоде получаются обычные методы, накладных расходов в рантайме нет. Претензия к @Data в семантике, а не в скорости.

Знают правило «не вешать на сущность», но не могут сказать, что сломается. Нужна механика: хеш до и после сохранения, ленивые связи внутри equals и toString.

Забывают про наследование. @EqualsAndHashCode по умолчанию поля родителя не учитывает и предупреждает про callSuper. Предупреждение обычно глушат, и два разных объекта начинают считаться равными.