Условные теги: required_without, excluded_with

Семья required_with и required_without отвечает на вопрос «когда поле обязательно», и условие читается по соседям, перечисленным через пробел после знака равенства. required_without=Phone означает: поле обязательно, если Phone отсутствует — а «отсутствует» здесь то же самое, что в семантике required из третьего урока: для строк, чисел и bool — нулевое значение («», 0, false), для указателей, срезов, карт и интерфейсов — nil. Нюанс, который дорого стоит на формах: пустой, но инициализированный срез для условия — присутствующий сосед, отсутствует только nil-срез; после декодирования JSON именно nil означает «поля в запросе не было». Условная валидация go устроена как словарная статья: поле описывает не «когда я валидно», а «когда я обязана существовать». Вариант с _all меняет логику на «все перечисленные»: required_without_all=Phone Email — поле обязательно, только если нет ни телефона, ни почты, то есть всегда, кроме случаев, когда хоть один способ связи указан. Разница между «хотя бы одного нет» и «все отсутствуют» — главная путаница семьи, и её стоит прогнать на четырёх состояниях формы до того, как тег поедет в прод. Присутствие соседа, напомним, тоже нулевое-значение-перевёрнутое: строка из пробелов — присутствующая, ноль числа — отсутствующий, и это ровно тот случай, где указатель из третьего урока снова становится инструментом честности. Соседей в условии можно перечислять сколько нужно через пробел, но помните о суффиксе: required_without=Phone Email Telegram — «обязательно, если хотя бы одного из трёх нет»; «только когда нет ни одного» — это required_without_all. Для формы «хотя бы один способ связи» из трёх каналов каждому полю хватает required_without_all с двумя остальными соседами в роли условия — за счёт перечней семья закрывает формы, которые в ручном коде превращаются в матрицу состояний.

Вторая ветка семьи смотрит не на соседей, а на значение конкретного поля: required_if=Method courier — поле обязательно, если Method равен courier. Параметр — пары «поле значение», разделённые пробелом: required_if=Method courier; несколько условий расширяются повторением имени поля — required_if=Method courier Method taxi делает поле обязательным при courier ИЛИ taxi. Следите за парностью: нечётное число параметров — паника «Bad param number for required_if» на первой же проверке структуры. Форма доставки собирается на этих двух тегах полностью: адрес обязателен для курьера, адрес запрещён для самовывоза, а Comment остаётся опциональным всегда. Так пара тегов описывает бизнес-правило «всё зависит от способа доставки», которое иначе пришлось бы расписывать ветками if в хендлере. Есть и обратный вариант — required_unless: поле обязательно, ПОКА условие не выполнено; он читается тяжелее и нужен реже, держите в памяти как существующий, а применяйте required_if. Пара required_if и excluded_if покрывает большинство «если-то» форм: обязательность по значению и запрет по значению. Только помните о регистре: значение сравнивается буквально, «courier» и «Courier» — разные значения, поэтому нормализуйте способ доставки до валидации, иначе условие молча перестанет ловить половину вариантов. Когда же условие выходит за рамки равенства — «адрес обязателен для доставки за пределы города, но не в день праздника» — теги заканчиваются, и начинаются свои функции-валидаторы десятого урока, которым условия доступнее: они видят всю структуру через Parent().

Механика порядка заслуживает отдельного абзаца, потому что на ней держатся все комбинации урока. Правила тега исполняются слева направо, и omitempty работает как выключатель для того, что стоит после него: поле нулевое — оставшиеся правила пропускаются целиком. Условные теги — обычные правила в этом конвейере: они исполняются в свою очередь и либо требуют поле, либо отпускают. Отсюда канонический порядок: условная обязательность, omitempty, форматы и границы. Условие первым — оно решает судьбу пустого поля; omitempty вторым — он не даёт min, max и email добить пустоту, которую условие только что отпустило. Проверяйте комбинацию пятёркой состояний: оба поля пусты, заполнен первый, заполнен второй, заполнены оба, заполнен первый некорректно — это минимальный набор, на котором видно и условие, и формат. Отдельная память на числа: ноль — нулевое значение, то есть «отсутствует» для условия. Этаж 0 при required_without=Level будет считаться неуказанным, и поле потребуют заново; если ноль легитимен, переходите на указатель из третьего урока — *int различает «не указано» и «указан ноль» для тегов и для условий одинаково. Из механики следует и приём отладки: если сомневаетесь, что условие сработало, прогоните структуру с нулевым полем при каждом состоянии соседа и посмотрите на Tag() в ответе — условный тег, который не появился, либо не в том порядке, либо его условие читается иначе, чем вам кажется.

Обратная задача — не «должно быть заполнено», а «должно быть пусто»: excluded_with=BonusPoints запрещает заполнять поле, пока заполнен BonusPoints. Классический носитель — способы применения скидки: промокод и бонусные баллы нельзя совместить, и бизнес хочет это на границе, а не в глубине логики. Тег описывает конфликт одной строкой на каждое поле пары, а сообщение из каталога шестого урока собирается по Tag() и Param(): «выберите одно: промокод или бонусы». Пара зеркальных excluded_with закрывает конфликт с обеих сторон: какое поле ни заполнили вторым, ошибка укажет на него. Тонкость, которая возвращается из третьего урока: «пусто» — это нулевое значение, и ноль числа считается пустым. Счётчик бонусов со значением 0 под excluded_with пройдёт — поле «пустое», конфликта нет; если для бизнеса «0 бонусов» — это применённый бонус, нужна пара указателей, где nil и ноль различимы. И следите за направлением: excluded_with говорит «сосед есть — я пуст», excluded_without — «соседей нет — я пуст»; суффиксы работают как в required-семье, только вердикт противоположный, и таблица выше — лучший способ не перепутать их в боевом теге. И не пытайтесь заменить excluded_with на oneof с пустым значением: перечень допустимых значений не умеет говорить «поле должно быть пустым», а пустая строка в oneof выглядит легитимным выбором и путает клиента — для запрета существует отдельный тег, вот им и пользуйтесь.

FieldError на условном теге несёт всё то же сырьё из пятого урока, и каталогу сообщений достаточно Tag() и Param(). Tag() возвращает имя условия — required_without, excluded_if; по нему каталог отличает «обязательное поле» от «обязательное, если не указан телефон». Param() возвращает перечень соседей строкой: «Phone» для одного, «Phone Email» для двух, а для required_if — «Method courier», имя поля и значение в одном параметре. Шаблоны сообщений получаются честными: «укажите хотя бы один способ связи», «поле обязательно при Method courier», «выберите что-то одно». Namespace() здесь работает как всегда — на вложенных формах путь покажет, какая ветка дерева сломалась. Диагностика из Value() в логах дополняет картину: запись с полем, соседом и значением соседа позволяет восстановить состояние запроса без трейсинга — ровно то, что нужно дежурному в три ночи. Две вещи, которых Tag() и Param() не дадут. Первая: почему сосед посчитался отсутствующим — нулевое значение скрыто внутри условия, и для диагностики берите Value() в логах, не в ответе. Вторая: список всех конфликтующих пар разом — валидатор собирает ошибки по полям независимо, и два зеркальных excluded_with дадут две записи; не склеивайте их в одну на бэкенде, фронтенду проще подсветить оба поля.