EF Core 慢查询排查实战：TagWith、OpenTelemetry 与执行计划
EF Core 性能问题里，最折磨人的不是“慢”，而是“慢得没规律”，线上卡，测试又无法复现。 很多小D、小W同学都经历过这种现场： 压测数据很好看 数据库 CPU 没打满 业务代码看起来也没什么大问题 你改了几个 Include，可能短期有效，但过两周又抖回来。根因往往不是某一行 LINQ 写错，而是整条排查链路没打通。 这篇文章就做一件事：给你一套能线上落地的 EF Core 慢查询定位闭环， …
Observability
EF Core 拦截器实战：SaveChangesInterceptor、CommandInterceptor 与审计落地
审计不是“给表补几个 CreatedBy 字段”，也不是“在业务方法里顺手记日志”。它本质上是系统级可追溯能力，设计目标是让系统在任何写路径下都能稳定回答四个问题：谁发起、改了什么、何时发生、通过哪条链路触发。 真正的难点不在 API 用法，而在系统设计阶段是否把审计定义成基础设施能力。这里聚焦两层落地：SaveChangesInterceptor 负责实体变更审 …
Serilog + OpenTelemetry：从请求日志到链路追踪的关联落地
这篇直接给落地方案，不再讲结构化日志的背景概念。目标只有一个：在 ASP.NET Core 服务里，把 Serilog 日志和 OpenTelemetry 链路追踪打通，排障时可以从一条错误日志直接跳到完整 Trace。 1. 问题背景：这篇要交付什么 按下面步骤做完，你会得到一条可执行排障链路： 日志里稳定带上 TraceId、SpanId、RequestPath、RequestMethod 业 …
Serilog：从结构化日志认知到 .NET 工程落地
问题背景 很多项目不缺日志，缺的是有用的日志。 平时接口跑得顺，大家都觉得日志够用。真到线上出问题，日志的短板会一下子暴露出来。 比如订单接口偶发超时，日志里只剩这么一句： Create order failed for customer 1024, cost 3800ms, trace abc123 这种日志平时看着还行，真到线上排障时基本帮不上太多忙： …
从 IApplicationBuilder 到 RequestDelegate：ASP.NET Core 请求管线性能与可观测性
很多团队做性能优化时，第一反应是改 SQL、加缓存、扩机器。结果接口还是慢，而且慢得不稳定。 这类问题里，有一部分根因并不在业务代码，而在请求进入业务之前就已经产生了: 中间件顺序、重复序列化、过重日志、异常处理位置不当，都会把每个请求的固定成本悄悄抬高。 这篇文章我们不讲抽象概念，直接从一个真实工程场景出发，拆开 ASP.NET Core 请求管线，回答三个问题: 请求管线到底是怎么执行的 哪些 …