使用多个 .env 文件是不好的做法吗？答案

【问题标题】：Is using multiple .env files bad practice?使用多个 .env 文件是不好的做法吗？
【发布时间】：2021-05-26 08:59:02
【问题描述】：

我需要在不同的环境中运行测试：DEV、STAGING、PRODUCTION。不用说，上述环境的环境变量/秘密显然会有所不同。

我的快速解决方案是为每个环境创建一个 env 文件，例如 dev.env、staging.env 和 prod.env

但根据流行的 dotEnv npm 包和 12 Factor 应用程序的文档，不建议在您的 repo 中包含多个 .env 文件。

请给我一个管理多个环境的环境变量的实用解决方案。

【问题讨论】：

在你的仓库中？但是.env 文件包含 API 密钥和加密哈希等秘密，它们不应该被提交并且是你的回购的一部分。 .env 文件的全部意义在于每台机器都有一个，因此您可以根据机器/环境精确地在其中包含内容：开发、登台、生产。还是我错过了什么？
@JeremyThille 不应将秘密放入 .env 文件中，假设它们已在 repo 中检查。秘密应该由专门的机制单独和安全地处理！现在，不将 env 文件检查到 repo 会产生不同的问题：我们将它保存在哪里？我们如何备份它？我们如何跟踪变化？

【解决方案1】：

如果我正确理解他们在这里写的内容：

我应该有多个 .env 文件吗？

没有。我们强烈建议不要使用“主” .env 文件和“环境” .env 文件，如 .env.test。您的配置应该因部署而异，并且您不应该在环境之间共享值。

这并不意味着您不应该拥有多个 env 文件，而是您不应该拥有一个具有所有默认配置的 main.env 文件和继承自 @987654325 的附加 env 文件（每个环境一个） @ 并覆盖某些值。

不推荐的原因是这样的配置很难理解“特定值来自哪里？” （来自以下之一：main-env-file、specific-env-file、env-variable、code-default 等）。

也就是说，如果您创建多个 env 文件而没有这样的“main”，这意味着您需要在不同的 env 文件中复制许多值，由于明确性，这样做更好，但缺点是重复/冗长。

IMO 配置并非微不足道，虽然您只有一个小项目，但您选择如何实施并不重要，但如果我们谈论的是像公司产品这样更重要的东西，那么有很多解决方案可供选择在那里，有些是开源和免费的，有些是要花钱的，但值得您进行研究并找出哪个为您提供对您的用例更有意义的好处。

一些比较“著名”的工具是：Puppet、Ansible 和 Chef。

【讨论】：

【解决方案2】：

在我看来，你的项目中最好有多个 .env。

例如在 Symfony 中，我们可以为我们的项目配置多个环境，例如：local、dev、prod。它的目的是让代码更加干净易读。

我不太了解技术，但您可以在这篇 Symfony 文章中阅读一些关于 .env 的信息（无需成为 symfony 的专家）：https://symfony.com/doc/current/configuration.html#config-dot-env

【讨论】：