我只是使用了一个alt示例，因为我想要比典型的.json文件更灵活，但不希望它被抽象到一个需要依赖的库中，就像这样。基本上，导出一个立即调用的函数，该函数返回一个带有我想要设置的值的对象。有很大的灵活性。

     module.exports = function(){
       switch(node_env){
         case 'dev':
           return
           { var1 = 'development'};
         }
    }();

这里有一个更好的解释和完整的例子。使用Node.js中的配置文件

我的解决办法相当简单:

在./config/index.js中加载环境配置

var env = process.env.NODE_ENV || 'development'
  , cfg = require('./config.'+env);

module.exports = cfg;

在./config/config.global.js中定义一些默认值

var config = module.exports = {};

config.env = 'development';
config.hostname = 'dev.example.com';

//mongo database
config.mongo = {};
config.mongo.uri = process.env.MONGO_URI || 'localhost';
config.mongo.db = 'example_dev';

重写。/config/config.test.js中的默认值

var config = require('./config.global');

config.env = 'test';
config.hostname = 'test.example';
config.mongo.db = 'example_test';

module.exports = config;

在./models/user.js中使用:

var mongoose = require('mongoose')
, cfg = require('../config')
, db = mongoose.createConnection(cfg.mongo.uri, cfg.mongo.db);

在测试环境中运行应用程序:

NODE_ENV=test node ./app.js

我使用Dotenv-Flow进行配置管理。

这和预期的一样。通常情况下你会有多个 本地、开发、登台和生产等环境。看这些 步骤创建您自己的环境。

1. 我喜欢流动。

2. 创建像.env | .env.dev | .env.prod这样的文件。

出于测试目的，复制此内容

.env

DATABASE_HOST=global
DATABASE_PORT=global
DATABASE_USER=global
DATABASE_PASS=global
DATABASE_NAME=global

.env.dev

DATABASE_NAME=dev
DATABASE_PASS=dev

.env.prod

DATABASE_NAME=prod
DATABASE_PASS=prod

现在使用这些环境变量创建一个测试文件。

. js

console.log('database host:', process.env.DATABASE_HOST);
console.log('database port:', process.env.DATABASE_PORT);
console.log('database user:', process.env.DATABASE_USER);
console.log('database pass:', process.env.DATABASE_PASS);
console.log('database name:', process.env.DATABASE_NAME);

现在使用这些命令运行脚本。

node -r dotenv-flow/config test.js
node -r dotenv-flow/config test.js --node-env=dev
node -r dotenv-flow/config test.js --node-env=prod

如果您在特定的文件夹中创建这些环境变量文件，就像我在envs文件夹中创建这些文件一样，那么使用下面的命令。

node -r dotenv-flow/config test.js --dotenv-flow-path=./envs
node -r dotenv-flow/config test.js --dotenv-flow-path=./envs --node-env=dev
node -r dotenv-flow/config test.js --dotenv-flow-path=./envs --node-env=prod

我知道这是一个非常老的帖子。但是我想分享我的配置环境变量的模块，我认为这是一个非常灵活的解决方案。 下面是模块json-configurator

var configJson = {
  'baseUrl': 'http://test.com',
  '$prod_baseUrl': 'https://prod.com',
  'endpoints': {
    'users': '<%= baseUrl %>/users',
    'accounts': '<%= baseUrl %>/accounts'
    },
  foo: 'bar',
  foobar: 'foobar',
  $prod_foo: 'foo in prod',
  $test_foo: 'foo in test',
  deep:{
    veryDeep: {
      publicKey: 'abc',
      secret: 'secret',
      $prod_secret: 'super secret'
    }
  }
};

var config = require('json-configurator')(configJson, 'prod');

console.log(config.deep.veryDeep.secret) 
// super secret 

console.log(config.endpoints.users)
// https://prod.com/users 

然后你可以使用process.env。NODE_ENV来获取环境的所有变量。

在这里，我将全身心地投入其中，因为这些答案中没有一个解决了几乎任何系统都需要的所有关键组件。注意事项:

公共配置(可以从前端看到)vs私有配置(guy mograbi说对了)。并确保它们是分开的。 钥匙一样的秘密 默认值vs特定于环境的覆盖 前端包

以下是我如何进行配置:

config.default.private.js - In version control, these are default configuration options that can only be seen by your backend. config.default.public.js - In version control, these are default configuration options that can be seen by backend and frontend config.dev.private.js - If you need different private defaults for dev. config.dev.public.js - If you need different public defaults for dev. config.private.js - Not in version control, these are environment specific options that override config.default.private.js config.public.js - Not in version control, these are environment specific options that override config.default.public.js keys/ - A folder where each file stores a different secret of some kind. This is also not under version control (keys should never be under version control).

I use plain-old javascript files for configuration so I have the full power of the javascript langauge (including comments and the ability to do things like load the default config file in the environment-specific file so they can then be overridden). If you want to use environment variables, you can load them inside those config files (tho I recommend against using env vars for the same reason I don't recommend using json files - you don't have the power of a programming language to construct your config).

每个键在一个单独的文件中的原因是为了安装程序的使用。这允许您有一个安装程序，在机器上创建密钥并将它们存储在密钥文件夹中。如果不这样做，当你加载无法访问密钥的配置文件时，安装程序可能会失败。通过这种方式，您可以遍历目录并加载该文件夹中的任何关键文件，而不必担心在任何给定版本的代码中哪些存在哪些不存在。

由于您可能在私有配置中加载了密钥，因此您绝对不希望在任何前端代码中加载私有配置。虽然严格来说，将前端代码库与后端代码库完全分离可能更理想，但很多时候，PITA是一个足够大的障碍，阻止人们这样做，从而导致私有配置与公共配置。但是我做了两件事来防止在前端加载私有配置:

我有一个单元测试，确保我的前端包不包含我在私有配置中的一个密钥。 我将前端代码放在与后端代码不同的文件夹中，并且我有两个名为“config.js”的不同文件-一端一个。对于后端，config.js加载私有配置，对于前端，它加载公共配置。然后你总是只需要('config')，而不用担心它来自哪里。

最后一件事:您的配置应该通过一个完全独立于任何其他前端代码的文件加载到浏览器中。如果捆绑前端代码，公共配置应该作为一个完全独立的包构建。否则，你的配置就不再是真正的配置了——它只是你代码的一部分。配置需要能够在不同的机器上有所不同。

我最近刚刚发布了一个小模块来加载任何类型的配置文件。 它非常简单，你可以在https://github.com/flesler/config-node上查看