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

Сначала Go инициализирует импортированные пакеты, затем переменные уровня пакета текущего пакета, после чего выполняет его init-функции. Внутри одного исходного файла init-функции выполняются в порядке объявления; порядок между файлами задаётся системой сборки, поэтому строить на нём логику не следует.

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

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

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

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

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

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

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

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

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

init-функция не принимает аргументов и не возвращает значений. Она выполняется автоматически один раз при инициализации пакета в рамках конкретного запуска программы или тестового бинарника.

package main

import "fmt"

func init() { fmt.Println("первый") }
func init() { fmt.Println("второй") }

func main() { fmt.Println("main") }

Вывод будет состоять из строк первый, второй, main именно в таком порядке. Однако это не означает, что следует связывать init-функции из разных файлов неявным порядком.

Надёжнее выразить зависимость явно: объединить связанные действия в одну init-функцию, сделать инициализацию функцией New, либо передавать готовые зависимости в явный Register. Цена явного подхода — несколько больше кода, зато порядок виден вызывающему коду и проще тестируется.

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

Пакет HTTP-маршрутизации автоматически регистрирует обработчики через init. Один файл регистрирует базовые маршруты, другой — административные. Если административный обработчик предполагает наличие middleware, зарегистрированного в первом файле, скрытая межфайловая зависимость может привести к некорректной конфигурации.

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

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

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

Может ли init одной переменной пакета зависеть от другой, объявленной ниже?

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

Нет. init — специальная функция, а не обычный экспортируемый идентификатор API. Она запускается только механизмом инициализации пакета, поэтому для управляемой подготовки следует предоставить обычную функцию или конструктор.
Что произойдёт, если init вызовет panic?

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