Опиши пример реального бага, с которым ты столкнулся в работе.

Контекст: Веб-форма регистрации с полем email.

Баг: Email-адрес, содержащий кириллические символы в доменной части (например, user@домен.рф), успешно проходил фронтенд-валидацию, но при отправке на сервер вызывал ошибку 500 Internal Server Error.

Причина:

1. Фронтенд использовал упрощенную регулярку, которая проверяла только наличие символа @.
2. Бэкенд (на основе Java) использовал встроенный валидатор javax.validation.constraints.Email, который по умолчанию не допускает Unicode-символы в домене.

Пример некорректной валидации на фронтенде:

// Упрощенная (и ошибочная) проверка
function validateEmail(email) {
    return email.includes('@'); // Пропускает "тест@пример.рф"
}

Как нашли:

1. Изучили логи сервера — увидели ConstraintViolationException.
2. Сравнили спецификации валидации на фронтенде и бэкенде.

Решение:

1. Синхронизировали валидацию. Применили одинаковое регулярное выражение на обеих сторонах, соответствующее стандарту RFC 5322.
2. Улучшили фронтенд-валидацию:

   function validateEmail(email) {
   const regex = /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;
   return regex.test(email);
   }

3. Добавили понятное сообщение об ошибке: "Допустимы только латинские буквы, цифры и специальные символы в адресе email".

Вывод: Валидация критичных данных должна быть единой и максимально строгой на всех уровнях приложения (фронтенд, бэкенд, БД).