Переменные окружения: AutomaticEnv

AutomaticEnv не копирует переменные в реестр заранее — она меняет поведение каждого чтения. На Get, GetString, GetInt и IsSet viper спускается по лестнице приоритетов и на уровне окружения делает следующее: берёт ваш ключ, приводит его к верхнему регистру и ищет переменную с таким именем через os.LookupEnv. Запрос server.port превращается в поиск SERVER.PORT — и вот первая засада: переменную с точкой в имени shell не выставит, export SERVER.PORT=9090 bash отклонит как невалидный идентификатор. Поэтому без настройки имён AutomaticEnv в одиночку находит только ключи без точек: retries, debug, loglevel. Регистр работает в обе стороны: ключ в коде пишется как угодно — Server.Port, SERVER.PORT — реестр приведёт его к нижнему регистру, а поиск в окружении всегда идёт в верхнем. Запомните порядок: верхний регистр, потом замена разделителей, потом поиск. Проверку окружения можно и точечно: для ручного управления существует BindEnv, но в большинстве сервисов одной AutomaticEnv хватает, а тонкости явной привязки — тема ближайшего урока.

Связка SetEnvKeyReplacer(strings.NewReplacer(".", "_")) описывает, как превращать ключ в имя переменной: viper берёт ключ в верхнем регистре и прогоняет через замену — server.port становится SERVER_PORT, database.host — DATABASE_HOST. Replacer — обычный strings.NewReplacer, тот же тип, что и для массовых замен строк: можно заменить не только точки, но и дефисы. Правило одно: SetEnvKeyReplacer должен быть вызван до первых чтений, и обычно его ставят рядом с AutomaticEnv в начале конфигурационной секции. После этого связка полностью предсказуема: ключ → верхний регистр → замена разделителей → поиск в os.LookupEnv. Нашли — значение вернётся с этого слоя; не нашли — viper пойдёт дальше по файлу и дефолтам, как будто окружения вообще нет.

Самая коварная особенность AutomaticEnv: значения читаются, а ключей в реестре нет. AllKeys собирает ключи из файлов, дефолтов, Set и явно привязанных env — но перечислить все переменные процесса он не может и не пытается: viper не знает, какие из тысяч системных переменных относятся к вашей конфигурации. Поэтому AllSettings покажет только файл и дефолты, и дамп на старте напечатает «пустой конфиг» для сервиса, который прекрасно работает на env-настройках. Отсюда правило: не используйте AllSettings для логирования конфигурации целиком — печатайте конкретные ключи через Get, они честно сходят в окружение. Явная привязка BindEnv регистрирует ключ в реестре — и тогда он появляется в AllKeys вместе со значением; вместе с префиксами это тема следующего урока.

Окружение подключено, и один бинарник принимает настройки от деплоя. Нерешённым остался конфликт имён: два сервиса на общей машине дерутся за PORT, а переменные соседних приложений просачиваются в ваш реестр. Следующий урок про SetEnvPrefix и BindEnv чинит обе беды: префикс превращает PORT в APP_PORT, а явная привязка ключей возвращает их в AllKeys и делает валидацию полной. Тема переменных окружения в CLI уже встречалась в курсе Cobra — там os.Getenv и флаги; здесь всё сходится в один реестр с приоритетами. Потренируйтесь локальным Go: соберите секцию из урока, запустите с парой переменных и попробуйте предсказать дамп AllSettings до печати. Общий маршрут по темам — на странице курса viper.