.NET Core 3.1 Web API 依赖注入场景下Serilog跨程序集会话日志读取问题求解

• Serilog核心对象不可变特性被误用：Serilog的Logger实例在调用CreateLogger()完成构建后，所有管道配置（包括挂载的Sink）就被永久固化，后续再链式调用WriteTo方法不会修改已经生成的全局Logger。很多项目把WriteTo.InMemory()写在CreateLogger()之后，这行代码完全不生效，DI管线的日志根本不会写入内存通道。
• Sink实例不匹配：如果在appsettings.json的Serilog配置节点中启用了InMemory Sink，ReadFrom.Configuration会在配置加载时自动实例化一个全新的InMemory Sink对象挂到日志管道上，这个独立实例和代码中读取的静态单例InMemorySink.Instance不是同一个对象，自然读不到任何写入管道的日志。
• 为什么手动创建内部Logger时能正常读取：手动new的Logger实例，配置链上直接把读写用的同一个InMemory实例挂载在CreateLogger()之前，没有经过配置加载的独立实例创建环节，读写路径完全打通，所以逻辑正常。
• 全局静态存储的会话隔离缺陷：就算解决了实例不匹配的问题，InMemorySink.Instance是进程级全量静态存储，多并发请求时日志会交叉混杂，根本无法满足“读取当前请求会话日志”的核心需求。

• 第一步：修正全局Logger配置链路
  调整Program.cs的Logger初始化顺序，严格保证所有Sink挂载逻辑在CreateLogger()之前执行，同时移除appsettings.json中所有InMemory Sink的配置节点，避免自动创建独立实例：

  // 正确的全局Logger构建逻辑
  var globalLogger = new LoggerConfiguration()
      .ReadFrom.Configuration(builder.Configuration)
      // 显式将全局静态InMemory实例挂载到管道，确保和后续读取的对象一致
      .WriteTo.Sink(InMemorySink.Instance)
      .Enrich.FromLogContext()
      .CreateLogger();
  builder.Host.UseSerilog(globalLogger);
  

• 第二步：实现请求级日志的隔离收集
  全局静态InMemory存储无法隔离请求日志，需要搭配Scoped生命周期的收集器实现会话范围日志归集：
  • 注册Scoped服务RequestLogCollector，内部用线程安全集合存储当前请求产生的日志事件，生命周期和当前请求绑定。
  • 新增自定义Serilog Enricher，从LogContext中取出当前请求关联的RequestLogCollector实例，把每一条流经全局管道的日志（无论来自控制器、业务程序集、还是第三方组件的Serilog日志）写入对应请求的收集器中。
  • 在请求中间件的管道末端，从当前请求的RequestLogCollector中过滤出Information、Warning、Error级别的日志事件，序列化为紧凑JSON后写入自定义响应头，注意提前设置响应头大小阈值，避免超大日志导致响应被服务端拒绝。
• 第三步：验证DI链路连通性
  所有通过依赖注入获取的ILogger<T>、ILogger实例，日志会自动路由到全局Serilog管道，经过自定义Enricher归集到当前请求的收集器中，不会出现“手动Logger能读、DI注入读不到”的断层问题。

注意：.NET Core 3.1默认对响应头的大小限制为16KB，如果会话日志较多，建议先截断超过长度阈值的日志内容，避免响应异常。

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