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

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并想要使用它。我该怎么做呢?


当前回答

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

业务:

这是一个首先由express框架推广的环境变量,后来“泄露”到不同的包和服务中使用。

特别是在express中——当值是非生产的任何东西时——库将进入更宽容、更可调试、记录更多日志并消耗更多内存的开发模式。

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

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

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

这有什么不对吗?

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

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

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

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

其他回答

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

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

这在生产和开发中非常常见。

Set:

export NODE_ENV=production

Get:

你可以使用app。get('env')

通常,在开发、测试和调试代码时,可以使用NODE_ENV变量采取特殊操作。例如,生成您不想在生产环境中使用的详细日志记录和调试输出。Express本身的行为取决于NODE_ENV是否设置为生产。如果你把这些行放在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设置为生产环境,然后向其发送GET /错误请求,则不应该看到文本“forced an error!”在控制台中,并且响应不应该在HTML主体中包含堆栈跟踪(它起源于Express)。 相反,如果在启动服务器之前将NODE_ENV设置为其他值,则会发生相反的情况。

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

出口NODE_ENV =“价值”

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",这可能会导致开发代码意外地在生产环境中运行——如果你的应用程序在没有设置这个重要值的情况下抛出错误会更安全(如果愿意,默认为如上所述的生产逻辑)。

注意,如果您没有显式地为您的环境设置NODE_ENV,那么如果从进程访问它,它将是未定义的。Env,没有违约。

设置NODE_ENV

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

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

linux和mac: export NODE_ENV=production windows: $env:NODE_ENV = '生产'

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

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

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

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

业务:

这是一个首先由express框架推广的环境变量,后来“泄露”到不同的包和服务中使用。

特别是在express中——当值是非生产的任何东西时——库将进入更宽容、更可调试、记录更多日志并消耗更多内存的开发模式。

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

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

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

这有什么不对吗?

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

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

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

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

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

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