Вложенные структуры: Validate рекурсией

Разберём механику на профиле. ProfileForm содержит Name и Address, а Address содержит City, Street и ZipCode со своими тегами. Один вызов validate.Struct(&form) проверяет всё: Name по своим правилам, затем движок видит, что Address — структура, и обходит её поля по их тегам. Вложенные структуры валидация проваливает не одним обобщённым «Address сломан», а конкретными записями по полям: City провалил required, ZipCode провалил len=6. И вот здесь оживёт Namespace(), о котором пятый урок сказал «запомните сам факт»: для City путь будет ProfileForm.Address.City — полный маршрут от корня через точки. Field() при этом возвращает только последний сегмент, «City», — этого хватает для каталога уточнений на плоских структурах и не хватает на вложенных: два поля City в разных адресах съедят уточнение друг друга, поэтому на деревьях каталог ключуют по Namespace(). Проверки каждого уровня независимы: три сломанных поля на трёх глубинах дадут три записи в ValidationErrors, порядок следует порядку полей структуры. Обход дерева предсказуем: движок идёт по полям в порядке объявления и спускается внутрь поля-структуры сразу, как до него доходит очередь — глубина раньше соседей. Записи в ValidationErrors поэтому читаются сверху вниз по дереву, и в логе сообщения про вложенные объекты не перемешиваются хаотично. Цена рекурсии — отражение — платится из того же кэша планов по reflect.Type из второго урока: дерево разбирается один раз за жизнь процесса, повторные вызовы работают по готовому плану.

Главный вопрос вложенности: как сказать «объект целиком обязателен». Ответ прячется в семантике required из третьего урока — поле не должно быть нулевым значением своего типа. Структура-значение нулевой не бывает: она всегда существует, пусть и заполненная нулями, поэтому required на Address Address проходит всегда и не проверяет ничего. Это не баг, а задокументированная ветка обратной совместимости: валидатор явно пропускает required на не-указательной структуре — в том числе и полностью нулевой. Опция WithRequiredStructEnabled() включает строгую семантику: required начинает проваливать нулевую структуру-значение, и именно она станет поведением по умолчанию в следующей мажорной версии — закладывайтесь на указатели уже сейчас, чтобы миграция не изменила вам договоры. Требование «объект должен прийти» выражается указателем: Address с required означает «не nil», и nil-указатель провалит проверку с честным тегом required по имени поля. Вторая половина механики — что происходит с nil без required: валидатор пропускает такой объект целиком, внутрь не спускается, ошибки по полям не собирает. Это разумно — проверять поля отсутствующего объекта нечем, — но пропуска должен хотеть именно вы, а не случайность декодирования. omitempty на указателе делает намерение явным: «объекта может не быть, а если есть — проверяй поля». Бонус связки знаком по третьему уроку: после успешной проверки Address с required указатель гарантированно не nil, и разыменование в бизнес-коде безопасно без второго if. И разбор StructPartial из второго урока здесь добирает своё: частичная проверка принимает вложенные пути вроде Address.City, потому что сравнивает перечисленные поля с теми же Namespace().

Рекурсия из коробки — это удобно ровно до тех пор, пока дерево совпадает с границей проверки. В реальных системах встречаются поля-структуры, которые проверять не нужно: объект уже прошёл проверку на другой границе — пришёл из очереди после валидации продюсера или из соседнего сервиса, который гарантировал целостность; вложенная структура описывает данные, которые этот эндпоинт не трогает; либо дерево настолько большое, что повторная проверка хвоста на каждом запросе — чистая трата. Для таких полей есть тег structonly: поле остаётся под валидацией как структура, но спуск в его поля не выполняется — правила внутри игнорируются, отрабатывают только StructLevel-правила самой структуры, о которых одиннадцатый урок. Полное отключение поля даёт validate:"-": валидатор не проверяет ни поле, ни его содержимое — приём для полей, которые живут в структуре ради сериализации. Различие стоит держать в голове, потому что они решают разные задачи: structonly говорит «поле проверяется как единое целое», минус — «поле вне контракта проверки». Выбирайте structonly, когда гарантии объекта у вас всё-таки есть и вы готовы назвать, откуда, — иначе это способ замести дыру в границе доверия под ковёр.

Шестой урок зарегистрировал RegisterTagNameFunc по json-тегам — на плоских структурах эффект был косметическим, на деревьях он становится архитектурным: каждый сегмент пути переименовывается, и Namespace() превращается из ProfileForm.Address.City в маршрут json-имён вроде profile.address.city. Для фронтенда это готовый контракт: ответ 400 несёт путь, фронт разбивает его по точкам и подсвечивает вложенный инпут без таблиц соответствий. Отсюда же практическое правило каталога: на вложенных структурах уточнения ключуются по Namespace(), потому что Field() отдаёт только последний сегмент — City в Address и City в OfficeAddress различит только полный путь. Есть и цена, о которой честно: путь — это строка, и переименование json-тега меняет контракт с фронтом так же, как переименование поля меняло каталог уточнений в прошлом уроке; страховка та же — тест на пустую форму, который проверяет, что путь ожидаемого вида доезжает до ответа. И ещё деталь, которую удобно знать заранее: вложенность и нормализация имён не конфликтуют — сегменты собираются по тем же правилам, что и плоские поля, поэтому поведение предсказуемо на любой глубине. Пример на практике: уточнение «город — только Москва» для Address и «город отделения — для справки» для OfficeAddress записываются двумя ключами с общим префиксом и никогда не конфликтуют, потому что полный путь различает оба поля целиком; на плоской структуре такой конфликт не смог бы возникнуть, поэтому правило ключуют по Namespace вместе с первой вложенностью.

Последний вопрос плана — что делать, когда вложенных объектов много: Addresses []Address в профиле или позиции []Item в заказе. Ответ: элементы среза валидатор сам не трогает — срез это контейнер, и по умолчанию проверяются его правила уровня контейнера вроде min и max на количество элементов. Чтобы спуститься в каждый элемент, между правилами ставится тег dive, и после него правила применяются уже к каждому элементу — а элемент здесь структура, значит, включается та же рекурсия из этого урока. Ошибки получают индексированные пути: Addresses[0].City, Addresses[1].ZipCode — фронт подсвечивает конкретную строку формы, а не весь блок. Пара тонкостей, которые обычно спрашивают сразу: пустой срез под dive не проверяет ничего — итераций ноль, и это не ошибка; nil-элемент в срезе указателей без required пропускается по правилам прошлого блока. Для длинных срезов полезно помнить, что ошибки не ограничиваются первым провалом: список из двадцати позиций с тремя сломанными вернёт три записи, и все три доедут до Details одним ответом — повторная проверка после исправления покажет следующий список, если что-то осталось. Полная механика dive — правила до и после разделителя, unique, карты с keys и endkeys, цена поэлементной проверки — отдельная тема следующего урока, здесь достаточно моста: вложенность работает и внутри элементов, просто перед ней стоит dive.