Asp.Net Core中未配置异常处理中间件的深层影响及异常发生时CORS头丢失原因解析

我来给你把这两个问题讲得明明白白，毕竟我对ASP.NET Core中间件的运行机制摸得门儿清：

结果分两种环境来看：

• 开发环境：框架会自动兜底，返回一个自带的开发者异常页面——里面堆了堆栈跟踪、请求详情、查询参数这些调试必备的信息，相当于偷偷帮你启用了UseDeveloperExceptionPage的效果，方便你快速定位问题。
• 生产环境：服务器只会返回一个极其简洁的500“内部服务器错误”响应，要么是空白页面，要么是浏览器默认的错误提示。不过别担心，完整的异常信息会被记录到日志里（前提是你配置了日志系统），不会凭空消失。

深层运行机制 #

ASP.NET Core的中间件是按管道顺序干活的，分正向的“请求处理阶段”和反向的“响应生成阶段”。当某个中间件抛出异常时，执行流程会立刻反向回溯——从出问题的中间件往回走，挨个调用之前中间件里的异常处理逻辑（如果有的话）。

如果没配置UseExceptionHandler或UseDeveloperExceptionPage这类专门的异常处理中间件：

• 开发环境下，框架会在管道最末尾偷偷插一个隐式的异常处理中间件，捕获异常后生成那个带调试信息的页面；
• 生产环境下，没有任何中间件接盘处理异常，当流程回溯到管道起点时，Kestrel服务器会直接生成一个全新的500响应——注意，这个响应是完全从零开始建的，和之前请求处理过程中已经生成的响应半毛钱关系都没有。

CORS头丢失的原因 #

UseCors中间件是在正向请求阶段给响应添加CORS头的。但如果后续中间件抛出了异常，流程反向回溯时，原来那个已经加了CORS头的响应会被直接丢弃——因为服务器要生成全新的错误响应，而这个新响应根本不会再走一遍UseCors中间件的逻辑，所以之前加的CORS头自然就没了。

说白了：异常发生后，原来的响应被废掉了，新的错误响应走的是异常处理的“快捷通道”，没经过CORS中间件，所以头就丢了。

内容的提问来源于stack exchange，提问作者emrich