【发布时间】：2018-09-28 14:17:54
【问题描述】：
我正在寻找一种生产解决方案来为 Node.js 项目存储 ENV_VARIABLE，并且遇到了 dotenv，这是一个 Node.js 模块，用于读取 .env 并使其变量在 @987654325 中可用@。但我也遇到过another post，它指出 dotenv 只能用于开发。
dotenv 应该只用于开发吗？如果是，那么环境变量的生产解决方案是什么？
【问题讨论】：
标签： javascript node.js
【发布时间】：2018-09-28 14:17:54
【问题描述】：
tl;dr - 是的，
dotenv确实建议仅用于开发，但您也可以将其用于生产，如果您小心并了解其含义。
要了解为什么dotenv 仅推荐用于开发，让我们看一下人们通常放入他们的 .env 文件中的内容。
人们放入他们的 .env 文件中的常见嫌疑人是：
- 当前执行环境 (
NODE_ENV) - 数据库 URL（
POSTGRES_URL、MONGODB_URL等） - AWS 凭证
- JWT 签名密钥
- 各种自定义配置选项，便于调整而不影响源代码（即
REQUEST_TIMEOUT、MAX_BODY_SIZE等）
如您所见，其中大部分内容都包含敏感信息（凭据、密码等）。通常，在实际部署应用程序时，这些值直接存储在服务器环境中，而不是源代码的一部分。理由是，强烈不建议将敏感数据提交到 git 存储库（即使它是私有的），因为它最终可能会泄漏——要么将存储库公开，要么意外授予其他人非预期的访问权限，或者无数次其他原因。
因此，这些敏感值直接存储在目标部署服务器上，只有少数人可以看到它们，并且在发生意外泄漏时很容易替换它们。
另一方面，.env 文件通常不是源代码的一部分，只存在于个人用户的机器上。开发人员将提供他们自己的唯一安全密钥、密码和其他敏感信息，这些信息通常只能在他们自己的机器上使用，因此泄漏不太可能造成太大伤害。
通常不建议提交 .env 文件的另一个重要原因是它的目的是允许个人开发人员为自己的机器自定义配置和/或开发过程。共享同一个 .env 文件会破坏这个目的。
不推荐这样做的另一个重要原因是，在进行更复杂的部署时，您很可能不仅有生产 - 您还将有staging，beta，甚至更多的部署环境，每个环境都有不同的稳定性级别或针对不同的审查组。环境变量是为特定目的定制/配置应用程序的好方法。但是，如果您只通过单个 .env 文件管理您的配置，您将放弃这种灵活性，因为您只有一组这些环境变量。
好的，但我仍然想部署我的 .env 文件！
如果
- 您不打算将 .env 用于敏感数据
- 不要使用 .env 文件来根据每个开发人员和/或每个部署自定义应用程序
那么您不必担心 - 继续吧，如果您愿意，可以在生产环境中使用 dotenv！
如果您打算将其用于敏感数据存储，那么唯一“安全”的方法是在将此文件提交到 git 之前对其进行加密，并且仅在实际服务器上解密该文件。
尽管如此，尽管这种管理生产环境的方法可能会引发“哦，好”的反应，即使是经验丰富的开发人员，特别是为此目的使用 dotenv 最有可能会以“WTF？！”奖励您，充其量，因为大多数熟练的开发人员都希望 dotenv 成为他们可以为他们正在处理的事情放置自己的每台机器配置的地方。
【讨论】：
-
我完全同意，出于安全原因，
.env不应提交给github，.env可能因开发人员而异。但是将环境变量放在生产服务器上的.bash-profile中会很麻烦，特别是如果在一台服务器上多次部署同一个项目，那么在一个文件中具有相同的环境变量并且每次部署具有不同的值会令人头疼。如果没有dotenv，我不知道如何处理。
“环境变量”这个名称会告诉我们很多关于用法的信息。 第二个帖子（中）有一句好话：
环境变量帮助我们定义我们不希望在源代码中硬编码的值。它们允许我们根据运行环境自定义代码行为。
环境变量总是用来定义不同环境的设置，比如数据库连接、上传路径……
所以我可以说，dotenv 不应该只用于开发，您也可以在测试、登台或生产环境中使用它。
【讨论】：