Краткий ответ

Go сначала инициализирует импортируемые пакеты, затем переменные текущего пакета с учётом зависимостей между их инициализаторами. Переменная, значение которой используется при вычислении другой переменной, инициализируется раньше неё. После инициализации переменных выполняются функции init.

Исторический контекст

Пакеты Go проектировались как независимые единицы компиляции с предсказуемым запуском. Автоматический порядок инициализации решает проблему ручного управления зависимостями между глобальными значениями и пакетами.

Такой подход позволяет пакету подготовить таблицы, константоподобные переменные или регистрации до использования его экспортируемых функций. Одновременно Go ограничивает скрытую логику запуска: порядок задаётся зависимостями, а не произвольными вызовами из пользовательского кода.

Постановка проблемы

Если пакет содержит несколько переменных уровня пакета, простого чтения исходного текста недостаточно. Одна переменная может использовать другую напрямую или через вычисление, поэтому неправильный порядок привёл бы к чтению ещё не подготовленного значения.

Особый риск возникает при циклических зависимостях. Если для вычисления одной переменной требуется другая, а для второй — первая, компилятор не может построить корректный порядок и отклоняет программу.

Подробное решение

Сначала Go инициализирует зависимости импортируемого пакета. Затем в каждом пакете выполняется инициализация переменных уровня пакета: анализируются зависимости их инициализаторов, и каждая зависимая переменная получает значение до переменных, которые от неё зависят.

После завершения инициализации переменных выполняются функции init этого пакета. Функция init не вызывается напрямую и выполняется один раз для конкретного пакета в рамках запуска программы. Для пакета с несколькими файлами порядок без зависимости между инициализаторами определяется порядком исходных файлов, представленным компилятору; полагаться на случайный порядок файлов не следует.

Например:

package main

import "fmt"

var base = 2
var doubled = base * 2

func init() {
	fmt.Println("init:", doubled)
}

func main() {
	fmt.Println("main:", base, doubled)
}

Здесь base должна быть инициализирована до doubled, потому что её значение используется в инициализаторе doubled. Затем выполняется init, и только после этого начинается main.

Зависимость определяется статически, поэтому вычисления в инициализаторах не следует рассматривать как обычную последовательность операторов. Циклические зависимости между переменными уровня пакета приводят к ошибке компиляции, а чрезмерная логика в init затрудняет тестирование и делает запуск пакета менее очевидным.

Ситуация из практики

Пакет конфигурации вычисляет значения по умолчанию в переменных уровня пакета, а затем в init читает переменные окружения. Проблема состоит в том, что тесты не могут удобно подменить окружение после автоматической инициализации пакета: пакет уже выполнил скрытую работу при импорте.

Вариант с расширенным init прост в реализации и гарантирует готовность конфигурации до вызова функций, но ухудшает тестируемость и усложняет обработку ошибок. Вариант с ленивой инициализацией через sync.Once откладывает работу, однако добавляет синхронизацию и всё ещё скрывает момент подготовки состояния.

На практике для конфигурации обычно выбирают явную функцию загрузки, возвращающую значение и ошибку. Такой подход позволяет передавать зависимости явно, создавать разные конфигурации в тестах и контролировать момент инициализации. init разумнее оставлять для небольших безошибочных действий, например регистрации статически известного обработчика.

Что кандидаты часто упускают

1. Выполняются ли переменные импортируемого пакета после переменных пакета, который его импортирует?

Нет. Сначала полностью инициализируется импортируемый пакет: его переменные, затем его функции init. Только после этого начинается инициализация пакета-импортёра. Это гарантирует, что экспортируемое состояние зависимости уже подготовлено к использованию.

2. Гарантирует ли расположение объявления переменной в файле порядок её инициализации при наличии зависимости?

Нет, зависимость важнее текстового расположения. Если более поздняя переменная используется в инициализаторе более ранней, сначала будет вычислена зависимая переменная. При отсутствии таких зависимостей порядок определяется порядком представления исходных объявлений компилятору, поэтому межфайловый порядок не следует использовать как скрытый механизм координации.

3. Что произойдёт при циклической зависимости переменных уровня пакета?

Программа не будет скомпилирована: Go обнаружит цикл и сообщит об ошибке инициализации. Это безопаснее, чем выбирать произвольное начальное значение или допускать зависимость от порядка выполнения. Цикл обычно устраняют переносом вычисления в явную функцию, изменением структуры данных или разрывом зависимости через явно передаваемый параметр.