Réponse.

Historique de la question :

Perl prend en charge le chargement dynamique et statique de code depuis l'apparition du support des modules. Pour cela, le langage fournit trois mécanismes différents : require, use et do. Chacun d'eux a ses propres caractéristiques, différents cycles de vie d'exécution et influence sur le contexte de fonctionnement du programme.

Problème :

Un choix incorrect du mécanisme de chargement ou une mauvaise compréhension des différences entre eux entraîne souvent des bugs : chargement répété de modules, problèmes de portée, erreurs d'exécution (par exemple, échec de chargement, variables non initialisées ou fonctions).

Solution :

use — charge un module lors de la compilation. Appelle automatiquement la méthode import, si elle est définie. Utilisé pour charger des modules et des déclarations au début du programme.
require — charge un fichier ou un module pendant l'exécution, une seule fois par programme. Bien adapté pour le chargement dynamique de fichiers selon des conditions.
do — exécute simplement un fichier comme du code Perl, chaque fois qu'il est appelé. Utilisé rarement, nécessaire pour des cas spéciaux (par exemple, des fichiers de configuration).

Exemple de code :

use Some::Module;    # chargement statique

if ($config{plugin}) {
    require "$config{plugin}.pm"; # chargement dynamique
}

do 'local_config.pl'; # exécute chaque fois au démarrage

Caractéristiques clés :

use fonctionne uniquement avec package/module, appelle import, se déclenche lors de la compilation.
require fonctionne avec des fichiers et des modules, s'exécute à l'exécution.
do ne met pas en cache le module, mais exécute simplement le contenu du fichier.

Questions pièges.

Peut-on utiliser require pour se connecter à une variable et un module de type Some::Module ?

Oui, mais il faut indiquer explicitement le chemin d'accès au fichier, ou transformer le nom du module en chemin :

my $mod = 'Some::Module';
$mod =~ s!::!/!g;
require "$mod.pm";   # correct

Que se passe-t-il si do ne peut pas trouver le fichier ?

do retourne false (undef) et consigne l'erreur dans $@ — il ne déclenche pas de panique, comme use/require.

Que se passe-t-il si require est appelé deux fois pour le même fichier ?

require ne charge le fichier que la première fois, les appels suivants ne répéteront pas le chargement, même si le fichier source a été modifié.

Erreurs courantes et anti-patterns

Utiliser do au lieu de require pour charger des modules — la mise en cache et la sécurité se perdent.
Croire à tort que use peut être utilisé avec une variable.
Ne pas surveiller la valeur retournée par do — les erreurs de chargement de son fichier ne sont pas détectées.

Exemple de la vie réelle

Cas négatif

Dans un projet, ils ont essayé de connecter des plugins à la volée avec do, sans vérifier le statut retourné et ont confondu avec require.

Avantages :

"Fonctionne rapidement", pas besoin de comprendre les rouages de require/use.

Inconvénients :

Les erreurs de chargement n'étaient pas capturées, le plugin ne se chargeait pas, mais aucun message.
Le changement de plugin n'était pas correctement traité, le cache n'était pas nettoyé.

Cas positif

Ils ont utilisé require pour charger selon des conditions, transformant toujours le nom du module en chemin. Ils vérifiaient $@ après la tentative de chargement.