1. 为什么.NET Core错误处理值得专门讨论在.NET Core开发中错误处理看似基础却暗藏玄机。我见过太多团队在项目后期被诡异的异常折磨得焦头烂额而问题根源往往是最初的错误处理设计存在缺陷。不同于传统的ASP.NET.NET Core的中间件管道和依赖注入体系让错误处理既更灵活又更复杂。最近帮一个电商平台排查线上故障时发现他们的支付服务因为未正确处理AggregateException导致在第三方API超时情况下错误地标记订单为支付成功。这个Bug潜伏了三个月才被发现造成的财务损失超过六位数。这让我意识到很多.NET Core开发者包括曾经的我都在重复踩同样的坑。2. 五大致命陷阱深度解析2.1 陷阱一过度依赖全局异常过滤器// 典型错误示范 services.AddControllers(options { options.Filters.Add(new CustomExceptionFilter()); });全局异常过滤器看似一劳永逸实则存在严重局限中间件异常无法捕获在中间件管道中如AuthenticationMiddleware抛出的异常会直接跳过过滤器异步上下文丢失过滤器中的async/await可能导致调用栈信息不完整响应格式失控无法根据Accept头动态返回JSON/XML错误格式实战建议结合中间件和过滤器使用。用中间件处理基础架构异常过滤器处理业务异常。2.2 陷阱二忽略CancellationToken传播// 危险代码示例 public async Task ProcessDataAsync() { var data await _httpClient.GetAsync(api/data); // 未传递CancellationToken }在微服务架构中这个问题尤为致命上游服务取消请求时下游操作仍在执行数据库连接池被挂起操作占满负载均衡器认为服务无响应而触发熔断正确做法应该像这样public async Task ProcessDataAsync(CancellationToken ct) { ct.ThrowIfCancellationRequested(); var data await _httpClient.GetAsync(api/data, ct); await _dbContext.SaveChangesAsync(ct); }2.3 陷阱三错误记录上下文缺失常见反模式try { // ... } catch (Exception ex) { _logger.LogError(ex.Message); // 只记录Message }这种记录方式在排查分布式系统问题时几乎无用。我推荐的结构化日志应该包含_logger.LogError(ex, Order processing failed for {OrderId} at {Stage}. User: {UserId}, order.Id, currentStage, HttpContext.User.FindFirstValue(ClaimTypes.NameIdentifier));关键字段包括关联IDCorrelationId操作上下文如当前处理的实体ID用户身份信息环境变量仅开发环境2.4 陷阱四异常类型处理不当.NET Core中最危险的异常类型异常类型典型陷阱正确处理方式AggregateException直接catch导致信息丢失Flatten()后处理内部异常TaskCanceledException与TimeoutException混淆检查CancellationTokenDbUpdateConcurrencyException简单重试导致死循环采用乐观并发控制策略特别提醒处理System.Text.Json序列化异常时JsonException的Path属性能精确定位出错位置catch (JsonException jex) { _logger.LogError($JSON parsing failed at {jex.Path}); return BadRequest(new { ErrorPath jex.Path, Message Invalid data format }); }2.5 陷阱五生产环境过度暴露细节安全反模式示例app.UseExceptionHandler(errorApp { errorApp.Run(async context { var exception context.Features.GetIExceptionHandlerFeature(); await context.Response.WriteAsync(exception.Error.ToString()); // 暴露堆栈 }); });根据OWASP建议应该实现分级错误响应if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } else { app.UseExceptionHandler(/error); app.UseStatusCodePagesWithReExecute(/error/{0}); } // 在ErrorController中 public IActionResult Index(int? statusCode null) { var model new ErrorViewModel { RequestId Activity.Current?.Id, IsProduction !_env.IsDevelopment() }; if(statusCode.HasValue) { model.StatusCode statusCode.Value; if(statusCode 404) model.Message Resource not found; } return View(model); }3. 高级防御性编程技巧3.1 熔断模式实现Polly库的典型配置services.AddHttpClient(PaymentGateway) .AddTransientHttpErrorPolicy(policy policy.WaitAndRetryAsync(3, retryAttempt TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)))) .AddPolicyHandler(Policy.TimeoutAsyncHttpResponseMessage(10));关键参数经验值重试间隔指数退避2^n秒熔断阈值连续5次失败超时设置根据SLA的P99响应时间设定3.2 健康检查集成ASP.NET Core的健康检查端点常被忽视services.AddHealthChecks() .AddSqlServer(_config[ConnectionStrings:Default]) .AddRedis(_config[Redis:Configuration]) .AddUrlGroup(new Uri(https://payment-gateway/api/health), PaymentGateway); app.UseHealthChecks(/health, new HealthCheckOptions { ResponseWriter async (context, report) { context.Response.ContentType application/json; await context.Response.WriteAsync( JsonSerializer.Serialize(new { Status report.Status.ToString(), Checks report.Entries.Select(e new { Service e.Key, Status e.Value.Status.ToString(), Duration e.Value.Duration.TotalMilliseconds }) })); } });4. 诊断工具链推荐4.1 本地调试神器Exception HelperVS扩展自动建议可能的异常处理方案OzCode可视化异常传播路径dotnet-trace捕获生产环境异常堆栈4.2 生产环境监控# 使用DiagnosticSource监听异常 dotnet counters monitor System.Runtime Microsoft.AspNetCore.Hosting -p PID推荐报警阈值设置异常频率50次/分钟错误率5%的请求超时比例1%的请求5. 我的血泪经验在金融项目中我们曾因为未处理OperationCanceledException导致对账服务漏单。后来我们建立了错误处理检查清单所有async方法必须接受CancellationToken日志必须包含CorrelationId第三方调用必须配置熔断数据库操作必须设置超时建议5-10秒生产环境错误响应必须标准化最近帮客户重构错误处理系统时通过引入ElasticSearch存储错误日志配合Kibana的异常模式分析将MTTR平均修复时间从4小时缩短到15分钟。关键是在错误发生的第一时间就能获取完整的上下文信息。