Валидация конфигов с Viper

Конвейер валидации конфига go собирается из пяти шагов, и порядок здесь — контракт, а не стилистика. Сначала дефолты: viper.SetDefault заполняет ключи, которых может не быть ни в одном слое. Затем файл: viper.ReadInConfig читает конфигурацию в реестр; файл с опечаткой в синтаксисе упадёт здесь же, до всякой валидации. Третий шаг — viper.Unmarshal(&cfg): реестр раскладывается в структуру Config с учётом окружения и приоритетов источников; полную лестницу — файл, env, флаги, дефолты — разбирает курс viper, здесь мы стоим сразу после него. Четвёртый шаг — validate.Struct(&cfg): теги исполняются по полям, и ValidationErrors собирается списком, как в HTTP-хендлерах, — все провалы за один запуск, а не по одному за рестарт. Пятый — инварианты руками, о них ниже. Место конвейера — конец функции load(), которая возвращает (Config, error), и main решает: log.Fatal или ехать дальше. Курс viper строил проверки руками — метод с if-ами и errors.Join; валидатор забирает у ручного кода форматы и границы: правила живут рядом с mapstructure-тегами, одна структура описывает и раскладку, и договор, а новый ключ — это новая строка с тегами, а не новая ветка где-то в функции. Ручные проверки остаются ровно для того, что тегами не выразить: файловая система, парсинг, согласованность с внешним миром.

required ставим на секреты и связи с внешним миром: DSN базы, ключи API — нулевая строка означает «ключ забыли», и сервис без базы не должен подниматься. min и max держат порт в диапазоне 1024–65535: непривилегированные порты ниже 1024 в контейнере обычно не нужны, а опечатка 65350 ловится верхней границей. oneof описывает окружение: oneof=dev stage prod — и опечатка production вместо prod падает на старте, а не при выкладке в чужой кластер; семантику перечня мы разбирали в девятом уроке рядом с условными тегами. Пары значений связывают gtefield и ltefield: WriteTimeout с тегом gtefield=ReadTimeout запрещает таймаут записи короче таймаута чтения; рядом существуют строгие gtfield и ltfield. У time.Duration параметр min парсится как длительность: min=1s отсекает ноль «не задано» — нулевая длительность означает забытый ключ, и required ловил бы её наравне; связка полей — уже работа gtefield, а поля разных типов проваливают правило: держите пары в одном типе. required_without описывает альтернативу: CertFile с тегом required_without=Autogenerate обязан быть заполнен, когда автогенерация выключена. Границы у min и max включительные — полиморфизм границ разобран в третьем уроке, и на конфиге он работает так же, как на форме: диапазон честнее проверять граничными значениями, и к этому вернётся урок про тесты.

Окружение приходит строками — это разобрано в курсе viper: слабая типизация декодера превращает «8080» в int, пустую строку в ноль, а длительность «30s» парсится тем же хуком, что и в GetDuration. Отсюда три честных места конвейера. Первое: пустая переменная по умолчанию считается незаданной — viper пропустит её и возьмёт значение ниже по лестнице; если по ключу нет ни файла, ни дефолта, поле останется нулевым и required упадёт. Переключатель AllowEmptyEnv делает пустоту легальным значением — итог для конвейера не меняется: битый конфиг ловится на старте. Второе: дефолты ставятся до чтения. viper.SetDefault до ReadInConfig — и к моменту Unmarshal реестр полон: required срабатывает только на ключах, которых нет нигде, а не на «порядок вызовов перепутали»; дефолт после Unmarshal в структуру не попадёт вовсе — реестр уже выгружен. Третье: nil против нуля. Поле Retries *int остаётся nil, когда ключа нет ни в одном слое, и показывает 0, когда ключ есть с нулевым значением: required на nil-указателе падает, на указателе с нулём — проходит. Звёздочка в объявлении покупает различие «не задано» и «задано нулём», которого строке не хватает. И не забывайте про BindEnv: автоматические env-ключи Unmarshal не увидит — ключи, за которые отвечают теги, привязывайте явно, иначе required упадёт на ключе, который на самом деле задан.

validate.Struct — не конец конвейера. Теги видят только значения полей: они не умеют проверить, что файл сертификата существует, что каталог логов создаётся, что DSN не просто непустой, а парсится с хостом. Эти проверки — отдельная функция checkInvariants(cfg) error сразу после validate.Struct, обычный Go: os.Stat по сертификату, url.Parse по DSN с проверкой u.Host — приём тот же, что курс viper показывал на webhook-адресах. Правило разделения простое: теги — формат, границы и связи полей; руками — всё, что касается внешнего мира, потому что функция-тег обязана быть чистым предикатом, и файловая система внутри неё — нарушение контракта из десятого урока. Не тащите в инварианты и то, что проверяется использованием: доступен ли хост базы — вопрос ping, а не старта; валидация, которая ходит по сети на запуске, превращается в нестабильный health-check и через пару релизов выкидывается. Граница честная: синтаксис и наличие — на старте, живость — при использовании. Порядок тоже важен: инварианты после validate.Struct, а не до — незачем открывать файлы и парсить DSN, если теги уже нашли нулевой порт; битая структура должна останавливать запуск на самом дешёвом шаге.

Курс viper показывал WatchConfig: конфиг может перечитываться без рестарта, и каждая новая версия обязана пройти тот же конвейер — Unmarshal, validate.Struct, инварианты. Разница в реакции: на старте битая версия роняет процесс через log.Fatal, в рантайме убивать живой сервис нельзя — логируйте список Field() и Tag() и продолжайте работать прежней версией. Удобно, что конвейер один и тот же: load() возвращает ошибку — старт решает умереть, reload решает откатиться. Если проверки разъедутся — на старте теги, при перезагрузке «на глазок» — через месяц в живом процессе появится значение, которое старт никогда бы не принял. Горячая перезагрузка без валидации — способ запустить битый конфиг в обход всего, что построено выше: правило одно — нет конвейера, нет перезагрузки. Сюда же относится и честная оговорка про порядок: новая версия конфига проверяется целиком, а не диффом — теги смотрят на поля структуры, им всё равно, из какого слоя приехало значение. Тест, который докажет, что теги на Config не потерялись при рефакторинге, — тема девятнадцатого урока, и для конфига он важнее, чем для формы: цену пропущенного правила платит не пользователь, а дежурный в три ночи.