ASP.NET Core Web 应用程序中自定义环境名称的后果

Question

我一直在尝试找出在生产部署中将

ASPNETCORE_ENVIRONMENT

变量配置为

Production

以外的任何内容的后果（如果有）。

我们使用环境变量来根据我们的部署目标加载不同的appSettings配置，并且我们不确定当您将环境设置为

Production

时，是否在幕后完成了任何关键的优化。

我知道，如果您不设置变量，它默认为

Production

但仅此而已......🤔

源代码的编码方式是否总是针对

Environment.IsDevelopment

方法而不是

Environment.IsProduction

方法进行检查，以便将其设置为其他任何内容对于发布优化而言并不重要？

提前谢谢您！

Answer 1

不，幕后并没有为您神奇地完成任何事情。好吧，差不多了：

WebApplication.CreateBuilder

确实为您预先配置了

Development

环境的一些默认设置。但除此之外，这只是惯例。毕竟，环境只是一组配置值的名称。

以下是文档中写的建议：

开发环境可以启用不应在生产中公开的功能。例如，ASP.NET Core 项目模板在开发环境中启用开发人员异常页面。由于性能成本，范围验证和依赖项验证仅发生在开发中。

[...]

 生产环境的配置应最大限度地提高安全性、性能和应用程序的稳健性。一些常见的设置 与开发的不同之处包括：

• 缓存。
• 客户端资源被捆绑、缩小，并可能通过 CDN 提供服务。
• 禁用诊断错误页面。
• 启用友好错误页面。
• 启用生产日志记录和监控。例如，使用 Application Insights。

因此，例如，当您生成新项目时，默认模板会为您执行该配置，但您随时可以更改它。您使用的第三方库可能会根据当前环境自动配置自身，但实际上，最好只提供配置点并让您自己进行环境切换。

最终，大部分优化将由 C# 编译器在发布版本编译时完成，并且在应用程序执行时由 JIT 完成。毕竟，ASP.NET 应用程序仍然是 .NET 应用程序，并且它在相同的运行时上运行。

对于“已知”环境，它们对应于

Microsoft.Extension.Hosting.Environments

类的字段。但你真的可以使用任何值。