Dans le développement du projet PHP, il existe généralement de nombreuses options pour gérer les fichiers de configuration. .env Les fichiers sont l'une des méthodes largement utilisées des cadres traditionnels actuels (tels que Laravel). Ils prennent en charge la configuration flexible et la lecture dynamique des variables d'environnement. Cependant, certains développeurs ont suggéré: les constantes PHP ( définir ) peuvent-elles être utilisées à la place des fichiers .env ? Cet article utilisera la fonction get_defined_constants pour analyser les avantages et les inconvénients des deux en termes de performances, de sécurité, de flexibilité, etc.
.env Les fichiers sont généralement utilisés pour stocker des configurations liées à l'environnement, telles que les informations de connexion de base de données, les clés d'API, etc .:
APP_ENV=production
DB_HOST=127.0.0.1
DB_PORT=3306
Le moyen de définir les constantes en PHP est:
define('APP_ENV', 'production');
define('DB_HOST', '127.0.0.1');
define('DB_PORT', 3306);
Nous pouvons obtenir toutes les constantes définies, y compris les constantes personnalisées via get_defined_constants (true) :
$constants = get_defined_constants(true);
print_r($constants['user']);
Du point de vue de l'efficacité de l'exécution, les constantes PHP sont traitées pendant la phase de compilation et sont lues plus rapidement que l'analyse des fichiers .env au moment de l'exécution (en particulier lorsque chaque demande est rechargée).
define('START', microtime(true));
define('CONFIG_VALUE', 'example');
for ($i = 0; $i < 100000; $i++) {
$x = CONFIG_VALUE;
}
echo 'Time: ' . (microtime(true) - START);
contraste:
define('START', microtime(true));
putenv('CONFIG_VALUE=example');
for ($i = 0; $i < 100000; $i++) {
$x = getenv('CONFIG_VALUE');
}
echo 'Time: ' . (microtime(true) - START);
Dans la mesure réelle, la lecture constante est nettement plus rapide.
L'avantage de .env est sa variabilité. Différents fichiers .env peuvent être définis via différents environnements de déploiement sans modifier le code.
En revanche, les constantes ne peuvent pas être modifiées une fois définies (sauf si le script est rechargé), ce qui n'est pas convivial pour les scénarios où les configurations doivent être ajustées dynamiquement.
Par exemple, un service déployé sur https://m66.net/API/ nécessite des adresses d'accès à configurer dans différents environnements. Le fichier .env peut être très pratique pour ce faire:
API_URL=https://m66.net/api/
Et si vous utilisez des constantes, chaque fois que vous modifiez l'adresse, vous devez redéployer ou modifier le code:
define('API_URL', 'https://m66.net/api/');
.env Les fichiers ne doivent pas être exposés à l'extérieur via le serveur Web. S'il est configuré correctement, leur contenu ne sera pas visible à l'extérieur. Cependant, si la configuration est incorrecte, il existe un risque de fuite.
Les constantes PHP font partie du code et n'existent qu'à l'exécution et ne sont pas accessibles directement par les utilisateurs. En ce qui concerne le code lui-même, les constantes sont plus sécurisées.
Utilisez get_defined_constants (true) ['utilisateur'] pour afficher facilement toutes les constantes définies par l'utilisateur, ce qui est parfait pour le débogage:
echo "<pre>";
print_r(get_defined_constants(true)['user']);
echo "</pre>";
Cependant, le contenu de .env n'est pas facile à suivre et doit être lu à travers des outils ou de l'encapsulation supplémentaires.
Dimension | fichier .env | Constant ( définir ) |
---|---|---|
performance | Médium (dépendant d'IO) | Élevé (chargement pendant la compilation) |
flexibilité | Élevé (adapté à plusieurs environnements) | Faible (immuable statique) |
Sécurité | S'appuyer sur la configuration du serveur | Relativement plus sûr |
Débogage de la commodité | Général (besoin de coopérer avec le cadre) | Strong (get_defined_constants) |
La question de savoir s'il faut utiliser des constantes pour remplacer les fichiers .env dépend des exigences du projet:
Si la structure du projet est simple et que l'environnement de déploiement est fixe, l'utilisation des constantes peut obtenir de meilleures performances et de meilleures sécurité.
Si le projet implique un déploiement multi-environnement et un chargement de configuration dynamique, le fichier .env est toujours un choix plus raisonnable.
Dans le développement réel, il est recommandé d'utiliser les deux en combinaison: solidifiez un petit nombre de configurations de base dans le code sous forme constante et enregistrez des configurations variables ou sensibles dans des fichiers .env pour prendre en compte les performances, la sécurité et la flexibilité.