当初第一次接触ASP.NET主机这个概念，我脑子里冒出一个很朴素的疑问，这东西到底是干什么的？字面看叫主机，很容易理解成一台物理机器。慢慢折腾一段时间之后才明白，微软说的主机和硬件设备无关，它是一套负责应用程序启动以及生命周期管理的运行机制。
可以把它理解成后台管家。应用程序启动之前，由它完成各类准备工作。配置服务器，搭建请求处理管道，顺带处理日志记录、依赖注入、配置管理这类琐碎事务。虽然需要处理的事情不少，但写代码的时候不需要过多操心，ASP.NET Core项目模板已经封装好大部分默认行为。
说到项目模板，新建ASP.NET Core项目，默认使用WebApplicationBuilder搭配WebApplication这套API。对比以前IWebHostBuilder写法，新版写法简洁很多。我印象很深，老版本要在Program.cs单独写CreateWebHostBuilder方法，还要配合Entity Framework Core工具，很容易踩坑。现在直接调用WebApplication.CreateBuilder一行代码完成初始化，省去很多冗余代码，写起来更顺手。当然旧版Web主机并没有移除，微软保留它主要是为了兼容老项目，维护遗留系统的时候大概率还会碰到。
但光有管家还不够，应用程序需要处理HTTP请求，这部分工作交给服务器组件。ASP.NET Core内置多款服务器实现，最常用的是Kestrel和IIS HTTP Server。Kestrel跨平台运行，性能优秀，内存利用率高，但缺少HTTP.sys提供的部分高级特性。IIS HTTP Server是Windows平台进程内托管方案，和IIS运行在同一个进程。还有HTTP.sys，仅限Windows系统使用，不需要搭配IIS。
这里涉及部署时托管模型选择，会直接改变IIS和Kestrel之间的协作关系。如果ASP.NET Core应用直接托管在IIS工作进程w3wp.exe内部，就是进程内托管，这时使用IIS HTTP Server而不是Kestrel。进程外托管不一样，IIS相当于反向代理，接收请求之后转发给后端Kestrel进程。两种方案各有利弊，微软默认推荐进程内托管，理由是性能更好，故障诊断更方便。
那什么时候需要纠结托管模型？大多数场景使用默认配置就足够，进程内托管简单高效。但如果需要部署在Linux环境，或者前端已经部署Nginx反向代理，也可以让Kestrel直接对外提供服务。反过来服务器是Windows Server，并且已经部署IIS，可以把IIS作为前置反向代理，后端跑Kestrel。使用IIS托管记得提前安装.NET托管捆绑包，里面包含运行时和ASP.NET Core模块，是IIS和ASP.NET Core应用通信的基础。有个小坑要留意，如果先安装捆绑包再部署IIS，需要修复捆绑包安装，不然模块加载失败。模块安装完成，应用程序池.NET CLR版本设置为无托管代码，因为业务代码不由IIS托管。
环境配置也值得简单说说。ASP.NET Core依靠ASPNETCORE_ENVIRONMENT环境变量区分Development、Staging、Production三种运行环境。应用启动读取这个变量，存入IWebHostEnvironment实例，通过依赖注入可以在程序任意位置获取。实际开发最常见用法，非开发环境开启异常处理中间件和HSTS中间件。这个设计很合理，开发环境展示详细错误页面，生产环境隐藏错误详情。
回头看主机和环境这套机制，本质解决一个老问题：应用从启动、运行到退出，整套生命周期的各类事务需要统一管理。传统ASP.NET里，这些工作依靠IIS和HttpApplication事件管道，依靠Module和Handler机制实现。现在ASP.NET Core改成基于委托的中间件管道，灵活性提升，但生命周期相关管理工作依旧需要主机组件承担。