Réponse

Lorsqu'une application Go est lancée, tous les paquets non testés sont initialisés dans un ordre strict : d'abord toutes les dépendances importées (en chaîne), puis le paquet lui-même. L'initialisation utilise :

• des variables au niveau du paquet (initialisation de haut en bas dans le fichier)
• des fonctions init() (il peut y en avoir plusieurs par paquet)

Les fonctions init sont appelées après l'initialisation des variables du paquet. Si un paquet est importé, son init s'exécute une fois avant l'utilisation des variables/fonctions de ce paquet.

Exemple :

var a = getA()
func getA() int {
    fmt.Println("getA appelé")
    return 42
}

func init() {
    fmt.Println("init appelé")
}

// Affichera :
// getA appelé
// init appelé

Particularités :

• L'ordre d'initialisation peut devenir critique si les variables d'un paquet dépendent des variables d'un autre paquet importé.
• Plusieurs init() dans un même fichier ou paquet s'exécutent dans l'ordre de leur apparition dans le code source.
• Le paquet main est initialisé en dernier.

Question piège

Peut-on appeler explicitement la fonction init d'un paquet ?

Réponse : Non, la fonction init n'est jamais appelée directement depuis le code du programme. Elle est appelée uniquement par le runtime lors du processus d'initialisation du paquet à un moment prédéfini, l'appel explicite de init() n'est pas autorisé - cela entraînera une erreur de compilation.

Exemples d'erreurs réelles dues à l'ignorance des subtilités

---

Histoire

Dans un projet, deux paquets se sont importés mutuellement pour initialiser des variables globales via init(). Cela a conduit à des dépendances cycliques et à des erreurs de compilation - Go n'a pas pu déterminer l'ordre d'initialisation correct.

---

Histoire

La cause d'un bug complexe était que les fonctions init utilisaient des variables globales de paquet qui n'avaient pas encore été initialisées. Résultat : comportement ambigu lors de l'exécution avec des états imprévisibles.

---

Histoire

Dans un projet, pour des effets secondaires, un paquet a été importé sans son utilisation explicite (via import _ "some/lib"). Après la réorganisation du code, la fonction init du paquet requis a été appelée trop tôt (avant l'initialisation des variables dépendantes dans un autre paquet), provoquant un bug difficile à déboguer.