Срезы и карты: тег dive

Соберём список тегов статьи: Title сверху и Tags []string — от нуля до десяти тегов, каждый от одного до шестнадцати символов. Тег поля собирается так: omitempty разрешает пустой список, max=10 ограничивает количество элементов, dive переключает режим, и дальше min=1,max=16 уже про каждый элемент. Валидация слайса go читается как предложение: контейнер — максимум десять элементов, внутри каждого — от одного до шестнадцати символов. Ключевая разница с третьим уроком в том, куда смотрит правило: min=1 до dive требует хотя бы один элемент в срезе, min=1 после dive требует непустую строку в каждом элементе — одинаковая запись, два разных договора. Правила после dive исполняются для каждого элемента слева направо до первого провала, ровно как на плоских полях; элемент не проходит одно правило — его проверка завершена, следующие не выполняются. Контейнер при этом проверяется один раз, до цикла. Массивы живут по тем же правилам: [4]string под dive проверит каждый из четырёх элементов, а len=4 до dive потребует ровно четыре. И последняя деталь грамматики: dive может стоять и последним правилом — тогда он просто включает проверку элементов, а правила к ним приезжают из тегов самих структур, как в срезе объектов из пятого блока. Так тегом из одной строки описывается конвейер, который ручным кодом занял бы вложенный цикл с ветками на каждый случай.

Элементы независимы, как поля плоской структуры: один провалился — проверка остальных продолжается, и каждая ошибка становится отдельной записью ValidationErrors. В поле Field() такой записи появляется индекс: Tags[1], Tags[2] — это обещание пятого урока сбылось. Именно индексы превращают технический список в человеческий ответ: каталог сообщений из шестого урока строит «тег №2 пустой» по Field(), и фронт подсвечивает конкретную строку списка, а не блок целиком. Отсюда два практических вывода. Первый: не склеивайте ошибки элементов в одну строку на бэкенде — держите по записи на элемент, формату Details из двадцать четвёртого урока это подходит идеально. Второй: ожидайте несколько записей по одному полю — срез из трёх пустых элементов даст три записи с разными индексами, и тесты должны это покрывать. Сообщение при этом собирается из готовых деталей: Field() дал «Tags[1]», каталог по Tag() вернул «пусто нельзя, минимум 1 символ» — и пользователь видит «Тег 2: пусто нельзя», не зная ничего о срезах и нумерации с нуля. Отдельная тонкость порядка: внутри одного элемента работает правило «первый провалившийся тег завершает проверку», поэтому длинный пустой элемент вернёт min, а не max — как у Password в пятом уроке. И последнее: индексы в Namespace() — материал для ретрая и логов, но не для ответа клиенту как есть: пользователь думает строками формы, а не номерами массива.

Второй список-специфический тег — unique: он требует, чтобы элементы не повторялись. Правило уровня контейнера, поэтому ставится до dive, вместе с max и len: validate:"omitempty,unique,dive,min=1,max=16". Сценарии — теги статьи, список адресатов, набор купонов: дубль здесь не ошибка формата, а логическая ерунда, которую не поймает ни один тег формата из четвёртого урока. Механика у unique простая: валидатор собирает элементы в служебную карту и ловит повтор — значит, элементы должны быть сравнимыми: строки, числа, структуры без срезов и карт внутри. Срез несравнимого типа под unique приведёт к панике в рантайме при первой же проверке — тот же жанр, что битый тег из первого урока, и лечится тем же лекарством: тестом с реальным значением на старте. Для срезов структур, где «уникальность» означает «нет двух позиций с одним артикулом», у unique есть параметр: unique=SKU сравнивает элементы по полю SKU и ловит повтор (с версии v10.12), а на отдельном поле той же механикой работает сравнение с соседом — «дата конца не равна дате начала». Ошибётесь в имени поля — паника «Bad field name» на первой проверке, и это тоже ловит тест на старте. Уникальность по нескольким полям сразу — по-прежнему территория StructLevel из одиннадцатого урока. И заметьте разделение труда: unique следит за взаимностью элементов, dive — за качеством каждого по отдельности; одно другому не заменяет, и в честных формах оба правила живут рядом. Комбинация с oneof внутри дива закрывает и качество, и состав: omitempty,unique,dive,oneof=go rust python — список без дублей, где каждый элемент из перечня. Одна строка тега заменяет три ветки кода, и ошибки по-прежнему едут с индексами.

С картами dive работает по той же схеме с одной надстройкой: после dive правила применяются к значениям, а для ключей есть собственный сэндвич — между тегами keys и endkeys пишутся правила ключа, после endkeys — правила значения. Атрибуты товара: Attrs map[string]string, ключ — имя атрибута от одного до двадцати символов, значение — до двухсот. Один тег описывает обе стороны каждой пары, и ошибки различают, что именно сломалось: путь в Namespace() содержит сам ключ карты, поэтому из ответа видно, какая пара виновата. Пустая карта под dive не проверяет ничего — итераций ноль, это не ошибка; обязательность наличия пар описывается required или min=1 до dive, по правилам контейнера. Для структур в значениях действует то же правило, что и для срезов структур: dive включает рекурсию седьмого урока, и путь до ошибки проходит сквозь ключ карты. Практический совет: не описывайте в ключах сложные форматы — ключ карты чаще всего едет в JSON-объект, где его формат договорён с фронтом; тегу оставьте длину и oneof на перечень допустимых имён атрибутов. И держите сэндвич в голове как целое: keys пишут в паре с endkeys, чтобы границы правил ключа и значения в теге оставались читаемыми — вольная перестановка превращает тег в загадку для следующего ревью.

Самый частый в реальных API случай — срез не строк, а структур: Positions []Item в заказе, Addresses []Address в профиле. Здесь dive включается в рекурсию из прошлого урока: правило после dive применяется к каждому элементу, элемент — структура, и валидатор спускается в её поля по их тегам. Пути ошибок собирают всё сразу: Order.Positions[0].Sku, Order.Positions[2].Qty — индекс элемента плюс маршрут внутри него, и фронт подсвечивает конкретную ячейку конкретной строки. Для указателей в срезе работает договор прошлой недели: []*Address с dive пропустит nil-элементы без спуска, а required на элементе потребует ненулевой указатель в каждой позиции. Условные теги из следующего урока тоже работают внутри элементов: требование «у позиции со скидкой обязателен код причины» выражается тегом на поле структуры, и dive доставит его до каждой строки. Единственное, чего dive не делает, — сравнивает элементы между собой: «сумма позиций равна итогу» и «артикулы не повторяются» живут за пределами тегов, в StructLevel из одиннадцатого урока. На практике здесь любят гранулярные Details: ошибка «позиция 3: количество больше остатка на складе» читается оператором быстрее, чем общее «проверьте позиции», — формат ошибок API рассчитан именно на такой по-элементный список.