La función init() es un identificador reservado en Go que define una subrutina de inicialización automática, la cual se invoca exactamente una vez por paquete tras la evaluación de las variables de nivel de paquete y antes de la ejecución de la función main(). Al carecer de parámetros de entrada y valores de retorno, su firma es estrictamente func init(), lo que impide su invocación manual desde cualquier punto del código fuente.
Este comportamiento existe en Go para garantizar que el estado interno de un paquete esté plenamente configurado antes de que cualquier otra entidad pueda consumir sus funciones o tipos exportados. Resuelve el problema de la inicialización de estado global complejo que no puede expresarse mediante asignaciones simples en la declaración de variables, como la configuración de controladores de bases de datos, la validación de variables de entorno o la instanciación de mapas pre-poblados. A diferencia de lenguajes que dependen de constructores estáticos o bloques de inicialización manual, Go integra este proceso en el ciclo de vida del binario de forma determinista y segura.
Grafo de dependencias y secuencia de inicialización
El runtime de Go gestiona la ejecución de las funciones init() siguiendo estrictamente el grafo de dependencias del programa. Si el paquete A importa al paquete B, la especificación del lenguaje garantiza que la inicialización de B se completará totalmente antes de que comience cualquier inicialización en A. Este proceso es recursivo y se realiza en profundidad, asegurando que los paquetes “hoja” (aquellos que no tienen dependencias externas) sean los primeros en ejecutar su lógica de configuración.
Dentro de un mismo paquete, el orden se divide en dos fases críticas: primero se evalúan las declaraciones de variables a nivel de paquete en su orden de aparición (siempre que no haya dependencias circulares entre ellas) y, posteriormente, se ejecutan las funciones init(). Es perfectamente legal declarar múltiples funciones init() dentro de un mismo paquete e incluso dentro del mismo archivo fuente; el compilador las procesará en el orden en que se presentan al analizador léxico.
package main
import (
"fmt"
)
var (
// Se evalúa antes que init()
version = setupVersion()
)
func setupVersion() string {
fmt.Println("1. Evaluando variables globales")
return "v1.0.0"
}
func init() {
fmt.Println("2. Ejecutando primer init()")
}
func init() {
fmt.Println("3. Ejecutando segundo init()")
}
func main() {
fmt.Println("4. Ejecutando main(). Versión:", version)
}
/*
Output esperado:
1. Evaluando variables globales
2. Ejecutando primer init()
3. Ejecutando segundo init()
4. Ejecutando main(). Versión: v1.0.0
*/
El comportamiento más contraintuitivo de la función init() es que, aunque múltiples archivos de un mismo paquete la declaren, Go garantiza que todo el proceso ocurre en un solo hilo de ejecución. Esto elimina condiciones de carrera durante la fase de arranque, pero también implica que una función init() bloqueante o excesivamente pesada retrasará el inicio de todo el programa, ya que main.main() no puede comenzar hasta que el grafo completo de inicializaciones haya finalizado.
Determinismo léxico en múltiples funciones init
Un comportamiento no obvio del compilador es cómo gestiona el orden cuando las funciones init() están distribuidas en múltiples archivos de un mismo paquete. El orden de ejecución entre archivos está determinado por el orden alfabético de los nombres de los archivos según los recibe el compilador. Si el archivo a.go y b.go definen init(), el de a.go se ejecutará primero.
Un edge case real surge con los “blank imports” (import _ "package"). Este mecanismo se utiliza exclusivamente para disparar la función init() de un paquete por sus efectos secundarios —como registrar un driver en sql o un formato de imagen en image— sin importar ninguno de sus identificadores. Si el paquete importado de esta manera falla dentro de su init() (por ejemplo, mediante un panic), el programa abortará antes de siquiera entrar en la primera línea de main(). Esta dependencia oculta hace que el orden de los imports sea crítico, ya que determina el estado global disponible para los paquetes subsiguientes.
- Módulo: Funciones
- Artículo número: #78