什么是NODE_ENV，如何在Express中使用它?

这是我目前正在生产环境中运行的应用程序。

var app = express();
app.set('views',settings.c.WEB_PATH + '/public/templates');
app.set('view engine','ejs');
app.configure(function(){
app.use(express.favicon());
app.use(express.static(settings.c.WEB_PATH + '/public'));
app.use(express.bodyParser());
app.use(express.cookieParser());
app.use(express.methodOverride());
app.use(express.session({
cookie:{ domain:"."+settings.c.SITE_DOMAIN, maxAge:1440009999},
secret:'hamster',
store: r_store,
}));
app.use(useragent.express());
app.use(flash());
app.use(passport.initialize());
app.use(passport.session());
});

现在我已经了解了NODE_ENV并想要使用它。我该怎么做呢?

350262 次浏览
小开

NODE_ENV是由表达 web服务器框架流行起来的环境变量。在运行节点应用程序时，它可以检查环境变量的值，并根据该值执行不同的操作。NODE_ENV特别用于(按照约定)声明特定环境是生产还是发展环境。一个常见的用例是，如果在开发环境中运行，则运行额外的调试或日志代码。

访问NODE_ENV

您可以使用以下代码自己访问环境变量，以便您可以执行自己的检查和逻辑:

var environment = process.env.NODE_ENV

如果你没有意识到它的价值，就假设它是生产:

var isDevelopment = environment === 'development'


if (isDevelopment) {
setUpMoreVerboseLogging()
}

你也可以选择使用express' app.get('env')函数，但请注意，这是< >强不推荐< / >强，因为它默认为"development"，这可能会导致开发代码意外地在生产环境中运行——如果你的应用程序在没有设置这个重要值的情况下抛出错误，那么就更安全了(或者如果愿意，默认为如上所示的生产逻辑)。

如果你从process.env访问它，则没有默认值。

设置NODE_ENV

如何实际设置环境变量因操作系统而异，也取决于您的用户设置。

如果你想一次性设置环境变量，你可以在命令行中这样做:

  • linux和;mac: export NODE_ENV=production
  • 窗户: $env:NODE_ENV = 'production'

从长远来看，您应该坚持这样做，以便在重新启动时不会取消设置—而不是列出所有可能的方法来执行此操作，我将让您自己搜索如何执行此操作!

惯例规定，NODE_ENV应该使用两个“主要”值，production或development，都是小写的。没有什么可以阻止你使用其他值(例如，如果你希望在运行自动化测试时使用一些不同的逻辑，则使用test)，但请注意，如果你使用第三方模块，它们可能会显式地与'production'或'development'进行比较，以确定要做什么，因此可能会有不明显的副作用。

最后，请注意，尝试在节点应用程序本身的中设置NODE_ENV是一个非常糟糕的想法 -如果你这样做，它将只能应用于设置它的进程，所以事情可能不会像你期望的那样工作。别做了——你会后悔的。

小开

NODE_ENV是一个环境变量，在快速服务器中表示节点的环境。

这是我们如何设置和检测我们所处的环境。

使用production和development是非常常见的。

设置:

export NODE_ENV=production

得到:

你可以使用app.get('env')来获取它

小开

我假设最初的问题包括Express如何使用这个环境变量。

Express使用NODE_ENV来改变自己的默认行为。例如，在开发模式下，默认错误处理程序将向浏览器发送回堆栈跟踪。在生产模式下，响应只是Internal Server Error，以避免向外界泄露实现细节。

小开

通常，在开发、测试和调试代码时，可以使用NODE_ENV变量来采取特殊操作。例如，生成您不想在生产环境中使用的详细日志记录和调试输出。Express本身的行为取决于NODE_ENV是否设置为production。如果你把这些行放在Express应用程序中，然后对/error发出HTTP GET请求，你就可以看到这一点:

app.get('/error', function(req, res) {
if ('production' !== app.get('env')) {
console.log("Forcing an error!");
}
throw new Error('TestError');
});


app.use(function (req, res, next) {
res.status(501).send("Error!")
})

注意，后面的app.use()必须在所有其他方法处理程序之后的最后!

如果你在启动服务器之前将NODE_ENV设置为production，然后向它发送一个GET /error请求，你应该在控制台中看不到文本Forcing an error!，并且响应不应该在HTML主体中包含堆栈跟踪(来自Express)。 相反，如果在启动服务器之前将NODE_ENV设置为其他值，则应该发生相反的情况

在Linux操作系统中，环境变量NODE_ENV的设置如下:

出口NODE_ENV = ' 价值 '

小开

< em > 免责声明: 这个答案可能会惹恼很多人，但它必须说出来。 没有冒犯的意思，请试着考虑一个比开发人员的观点更广泛的观点

业务:

这是一个环境变量，最初由express框架推广，后来“leaked"在不同的包和服务中使用。

特别是在express中——当值不是production时——库会进入一种更宽容、更可调试、记录更多日志并消耗更多内存的开发模式。

更常见的怪态是视图呈现库或视图呈现中间件在非生产模式下跳过缓存，期望在刷新之间由开发人员修改文件。

这是nodejs和express的ops中令人困惑的一点。

这基本上是一种反模式，将行为与环境名称耦合在一起。

这有什么不对吗?

  • 如果我不想让测试在不同于生产的模式下运行，该怎么办?
  • 如果我有几个不同名称的云环境，所有这些环境都需要像生产环境一样运行，那该怎么办?

变量的名称将许多操作人员推入陷阱，他们在NODE_ENV中填写环境的名称，当他们从相同的分布中获得与生产中不同的行为和性能时，他们会感到惊讶。

结果是，作为一名顾问，我看到大多数团队不得不使用第二个变量，如OVERRIDE_ENV， NODE_ENV_NAME， NODE_ACTUAL_ENV和更多类似的无意义的东西，并继续与直观地将NODE_ENV这样的名称与环境名称相关联的操作作斗争……

更好的名字应该是EXECUTION_MODE，但现在改变有点太迟了，所以我们只能用这个名字，不幸的是，不仅在express中…


提交答案