C#如何实现自定义中间件记录请求耗时_C#监控API接口响应性能【方案】-C#.Net教程-PHP中文网

StopWatch是Spring框架提供的高精度计时工具，基于性能计数器，精度达微秒级，支持分段计时、暂停继续、格式化输出等功能，适用于接口监控、任务调度和日志记录等场景。

c#如何实现自定义中间件记录请求耗时_c#监控api接口响应性能【方案】

直接用 Stopwatch + 中间件是最轻量、最可控的方案，不需要引入 AOP 框架或第三方库，也避开了 DateTime.Now 的精度和时钟漂移问题。

为什么不用 DateTime.Now 记录接口耗时

DateTime.Now 分辨率低（通常 10–15ms），在短请求（如几毫秒的 GET）中误差显著；且系统时钟可能被 NTP 调整，导致 ElapsedMilliseconds 出现负值或跳变。而 Stopwatch 基于高精度性能计数器（QueryPerformanceCounter），.NET 中默认启用，精度可达微秒级。

常见错误现象：ElapsedMilliseconds 为负数、同一请求两次日志差值异常大、耗时统计明显偏离实际（比如显示 2ms，但 Fiddler 抓包是 18ms）。

必须用 Stopwatch.Start() 和 Stopwatch.Stop() 配对，不能只靠 Start() 后直接读 ElapsedMilliseconds
避免在 await next() 前后用两个独立的 Stopwatch 实例——上下文可能跨线程，计时会断裂
不要在中间件里调用 Stopwatch.Restart()，它不保证原子性，高并发下易出错

中间件中正确使用 Stopwatch 的写法

关键在于把 Stopwatch 实例绑定到当前 HttpContext 生命周期，确保「开始→结束」严格对应一次请求处理链。

实操建议：

在 async (context, next) => { ... } 作用域内创建并启动 Stopwatch，不要提前提取为字段或静态变量
务必在 await next() 之后再调用 Stop()，否则计时不包含下游中间件和控制器执行时间
用 context.TraceIdentifier 关联日志，便于和分布式追踪对齐
日志输出字段建议固定为：RequestMethod、RequestPath、StatusCode、ElapsedMilliseconds，方便后续按字段聚合分析

示例片段：

app.Use(async (context, next) =>
{
    var sw = Stopwatch.StartNew();
    await next();
    sw.Stop();
<pre class="brush:php;toolbar:false;">var logger = context.RequestServices.GetRequiredService<ilogger>>();
logger.LogInformation(
    "REQ {TraceId} {Method} {Path} - {StatusCode} in {ElapsedMs}ms",
    context.TraceIdentifier,
    context.Request.Method,
    context.Request.Path,
    context.Response.StatusCode,
    sw.ElapsedMilliseconds);</ilogger>

});

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

和 ActionFilter 方案对比：什么时候该选中间件

中间件记录的是整个 HTTP 请求生命周期（含静态文件、认证、授权、MVC 路由前处理等），而 RequestTimeActionFilter 只覆盖 MVC 控制器的 Action 执行阶段。如果你要定位「慢在路由？慢在模型绑定？还是慢在业务逻辑？」，必须用中间件。

容易踩的坑：

把 UsePerformanceLog() 放在 UseRouting() 之前 → 无法获取 RequestPath，Path 为空
放在 UseEndpoints() 之后 → 日志里 StatusCode 总是 200，因为响应已提交，状态码不可读
未检查 context.Response.HasStarted 就读 StatusCode → 可能抛 InvalidOperationException

推荐顺序：

app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UsePerformanceLog(); // 放这里
app.UseEndpoints(...);

生产环境要注意的细节

中间件本身不能成为性能瓶颈。高频日志（如每秒数千请求）直接打 ILogger.LogInformation 会拖慢吞吐量。

优化建议：

对 ElapsedMilliseconds 的请求，默认不记日志，或降级为 <code>LogDebug
用结构化日志框架（如 Serilog）时，加 LogEventLevel.Warning 级别阈值：耗时 > 1s 才触发 LogWarning
避免在日志消息里拼接字符串（如 "耗时" + ms + "ms"），改用占位符，减少 GC 压力
如果需导出指标（如 Prometheus），不要在中间件里直接暴露 /metrics，应走专门的 IMetricsRoot 或 Counter 类型度量