我正在寻找一种存储解决方案，用于为Node.js项目存储ENV_VARIABLE，并且遇到dotenv，这是一个Node.js模块，用于读取.env并进行其变量在process.env中可用。但是我也遇到过another post，其中指出dotenv仅应用于开发。
dotenv应该仅用于开发吗？如果是，那么环境变量的生产解决方案是什么？
答案 0 :(得分：2)
tl; dr -是的，
dotenv实际上仅建议用于开发，但是如果您仔细并理解其含义，也可以将其用于生产。
要了解为什么仅建议在开发中使用dotenv，让我们看一下人们通常将其放入 .env 文件中的内容。
人们通常放入他们的 .env 文件中的可疑对象是：
NODE_ENV）POSTGRES_URL，MONGODB_URL等）REQUEST_TIMEOUT，MAX_BODY_SIZE等）您可能会看到，其中大多数内容都包含敏感信息（凭据，密码等）。通常，在实际部署应用程序时，这些值直接存储在服务器的环境中，而不是源代码的一部分。原因是强烈建议不要将敏感数据提交到git存储库（即使它是私有的），因为它最终可能会泄漏-通过将存储库公开或意外地使访问权限超出了预期的目的，或者出于无数目的其他原因。
因此，这些敏感值直接存储在目标部署服务器上，只有很少的人可以看到它们，并且在意外泄漏的情况下很容易更换它们。
另一方面， .env 文件通常不是源代码的一部分，而仅存在于单个用户的计算机上。开发人员将提供他们自己的，唯一的安全密钥，密码和其他敏感信息，这些信息通常只会在自己的计算机上运行，因此泄漏不会造成太大的危害。
通常不建议提交 .env 文件的另一个重要原因是，其目的是允许各个开发人员为自己的计算机自定义配置和/或开发过程。共享相同的 .env 文件不能达到此目的。
不建议这样做的另一个重要原因是，在进行更复杂的部署时，您很可能不仅只有生产-您还将有 staging ，< em> beta ，甚至可能还有更多部署环境，每个部署环境的稳定性级别不同或针对不同的审阅组。环境变量是为特定目的定制/配置应用程序的一种好方法。但是，如果仅通过单个 .env 文件管理配置，那么您将放弃这种灵活性，因为您只有一组这些环境变量。
如果
那么您就不必担心-如果愿意，请继续在生产中使用dotenv！
如果计划将其用于敏感数据存储，那么唯一“安全”的方法是在将该文件提交给git之前对其进行加密，并且仅在实际服务器上解密该文件。
尽管如此，即使对于有经验的开发人员来说，这种管理生产环境的方法也可能会引发“噢，好听”的反应，为此特别使用dotenv可能会给您一个“ WTF？”的奖励，充其量是因为大多数熟练的开发人员都希望dotenv是他们可以为正在处理的事情放置自己的每台计算机配置的地方。
答案 1 :(得分：1)
名称“环境变量”将告诉我们很多用法。 在第二篇文章（中）上有一个很好的句子：
环境变量可帮助我们定义不想在源代码中进行硬编码的值。它们使我们能够根据其运行环境自定义代码行为。
Environment变量始终用于定义不同环境（如数据库连接，上载路径等）上的设置。
所以我可以说不要将dotenv不仅用于开发，还可以在测试，暂存或生产环境中使用它。