Теги required, min, max

required звучит как «поле заполнено», но реализовано строго: поле не должно быть нулевым значением своего типа. Для строк это пустая строка — и только: строка из пробелов required пройдёт, потому что она не пустая. Для чисел — ноль, для bool — false, для указателей и интерфейсов — nil, для срезов и карт — nil или нулевая длина. Отсюда первая крупная ловушка курса: числовое поле, где ноль — легитимное значение. Количество детей, этаж, скидка в процентах — во всех этих случаях required отвергнет честный ноль, и пользователь формы получит «обязательное поле», хотя ничего не забыл. То же самое с деньгами: сумма перевода 0 на int с required уедет в отказ, хотя пользователь мог ввести ноль осознанно — перевод между своими счетами без комиссии. Различать «не указано» и «указан ноль» можно только указателем: *int с required,gte=0 пропустит честный ноль и отвергнет отсутствующее значение. Решений два: пересмотреть, действительно ли ноль допустим (если нет — нужен диапазон вроде gte=1), либо перейти на указатель, где nil и ноль различимы. И вторая ловушка — строка из пробелов: required её пропустит, а бизнес примет «имя пользователя» из одних пробелов. Отсюда правило: чистка пробелов — это нормализация перед валидацией, у неё отдельный урок курса. Третье следствие из семантики required — пустые контейнеры: срез тегов длиной ноль required отвергнет так же, как ноль числа; если пустой список легитимен, поле описывается парой omitempty,min=1 — «пусто можно, непусто хотя бы один элемент».

min и max — самые полиморфные теги валидатора: их смысл зависит от типа поля. Для строк они считают длину, причём в рунах, а не в байтах: «привет» — семь символов, хотя байтов двенадцать; для кириллических форм это принципиально, потому что len() по байтам дал бы вдвое больше. Для чисел min и max сравнивают само значение: min=1 на int отвергает ноль и отрицательные числа. Для срезов, карт и массивов — количество элементов: min=1 на []string требует хотя бы один элемент. Границы у min/max включительные: значение ровно на границе проходит проверку. Если нужна строгая граница, берите gt и lt, а нестрогие аналоги gte и lte для чисел работают как «минимально/максимально допустимое». Точный размер даёт len=13 — например, для строк фиксированной длины вроде штрихкодов и кодов подтверждения. На практике полиморфизм стреляет вот где: команда пишет max=140, думая о лимите твита, а поле — заголовок задачи в символах; для латиницы лимит совпадает с подсчётом фронтенда, для кириллицы — совпадает тоже (руны везде), а вот если фронт считает байтами — начинается спор про «пятьдесят символов» против «сотни байтов». Договаривайтесь на рунах и фиксируйте это в доках API. Таблица ниже собирает всю матрицу «тег против типа» на один экран — вернитесь к ней, когда сомневаетесь.

Необязательное поле — не то же самое, что поле без правил. Поставили min=3 на необязательное поле — и пустая строка провалится: min проверяет длину, а нулевая длина меньше трёх. omitempty решает конфликт: если поле нулевое значение своего типа, все остальные правила тега пропускаются. Комбинация omitempty,min=3,max=500 читается как договор: пусто — можно; непусто — от трёх до пятисот символов. Порядок правил в теге роли не играет — omitempty может стоять и в конце, — но конвенция ставить его первым улучшает читаемость. Частая ошибка новичка противоположна: привычка вешать omitempty на всё подряд, включая обязательные поля. required и omitempty в одном теге противоречат друг другу: required отвергает нулевое, которое omitempty только что пропустил, — поведение получается запутанным и зависит от порядка исполнения правил. Выбирайте одно из двух: поле обязательное или нет. Отдельный кейс для omitempty — PATCH-обновления: клиент присылает только изменённые поля, остальное отсутствует, и после декодирования структура заполнена нулями. Без omitempty валидация всей структуры отвергла бы такие запросы пачкой; с omitempty на необязательных полях и точечным перечислением обязательных через StructPartial — метод из прошлого урока — частичные обновления описываются без отдельной структуры на каждый эндпоинт. И ещё разница, о которой забывают: поле, отсутствующее в JSON, и поле с пустой строкой после декодирования для валидатора неразличимы — оба нулевые. Поэтому omitempty честно описывает оба случая сразу, а вот проверка «пользователь прислал, но пустое» тегами не решается — нужны указатели или приёмы из урока про DTO-границы.

Между «от» и «до» живёт семья точных проверок. len=N требует точного размера: строка из тринадцати символов для штрихкода, срез ровно из шести цифр кода подтверждения. eq и ne сравнивают значение с константой: eq=0 удобен для «поле должно быть нулём» в статусных структурах, ne — для запрета конкретных значений, хотя чаще список запретов переворачивают в oneof с перечнем допустимых. Для чисел полезна пара gt и lt — строгие границы: gt=0 исключает ноль там, где min=0 его пропускает, и это спасает от очередного бага «минимальное количество — ноль». Все эти теги подчиняются той же логике типов: строки считают руны, числа сравнивают значения, срезы — количество элементов. И так же, как min и max, они не прощают нулевых значений без omitempty: точная проверка на необязательном поле требует пары с omitempty, иначе пустая строка провалит len=6. Границы честнее проверять на граничных значениях: min=3 пропускает ровно три символа и ровно три элемента — тест со строкой из трёх символов скажет о правиле больше, чем чтение документации. Если поведение тега кажется неочевидным, соберите его локально на пяти значениях: ниже границы, на границе, выше, нулевое и пустое — эта пятёрка вскрывает любой полиморфный тег быстрее, чем чтение чужих туториалов.

Внутри тега правила разделяются запятыми и исполняются слева направо до первого провала: validate:"required,min=3,max=32" — сначала required, потом min, потом max; споткнувшись, поле завершает проверку, и остальные правила не выполняются. Параметр правила идёт через знак равенства: min=3. Пробелы вокруг правил — источник тихих сюрпризов: пробел после запятой превращает min=3 в неизвестный тег с именем « min», и валидатор паникует Undefined validation function на первом же прогоне структуры — форматируйте теги без пробелов. Перечень допустимых значений задаёт oneof, где значения разделяются уже пробелами: oneof=admin editor viewer — внутри одного тега грамматика двойная, запятые между правилами, пробелы внутри перечня. Форматы вроде email и datetime разобраны в следующем уроке, а здесь напомним про нормализацию: правила работают с тем, что им дали, — trim и нижний регистр делайте до validate.Struct, иначе « a@b.ru » придётся описывать тегами на каждый случай.