Многие разработчики в целом против использования Lombok. Это действительно холиварная тема. Но если вы всё-таки используете Lombok в проекте, постарайтесь избегать спорных и потенциально вредных аннотаций.
Одна из таких — это `@Data`. Во-первых, мало кто помнит, [какие методы она генерирует](https://projectlombok.org/features/Data).
-`@EqualsAndHashCode`. Это наиболее проблемная аннотация в составе `@Data`. Она генерирует методы `equals()` и `hashCode()` для всех полей класса, но зачастую этого не требуется. Например, для сущностей достаточно сравнивать только по идентификатору.
-`@ToString`. Если объект содержит чувствительную информацию, этот метод может вывести её в лог, что небезопасно.
Основная проблема кроется в аннотации `@EqualsAndHashCode`. Конечно, можно использовать `@EqualsAndHashCode.Exclude`, чтобы исключить отдельные поля из генерации, но вам придётся добавлять это почти ко всем полям. Использовать `@EqualsAndHashCode.Include` не получится — вы не можете включить только необходимые поля, придётся исключать все лишние.
Кроме того, избегайте аннотаций из пакета `experimental`. Эти аннотации нестабильны и могут быть удалены в следующих версиях Lombok. Единственным исключением является [@FieldNameConstants](https://projectlombok.org/features/experimental/FieldNameConstants). За несколько лет с ней не возникало проблем, а существующие альтернативы оставляют желать лучшего.
В целом, Lombok делает код чище, но, как и с любым “магическим” инструментом, важно понимать, как он работает и в каких случаях его применение уместно. В противном случае это может привести к снижению производительности или даже некорректной работе приложения.