为何使用Serilog时必须通过泛型ILogger实现依赖注入？

核心原因：日志分类是日志系统的基础需求 #

日志的核心价值之一是追踪来源，而{SourceContext}字段正是用来标识日志产生的组件。泛型ILogger<T>会自动将T的完整类型名作为SourceContext的值，命名ILogger则是手动指定分类名称——这两种方式都能明确日志的来源。如果支持非泛型ILogger，就没有了明确的分类标识，所有日志都会共享同一个默认分类，排查问题时根本无法定位到具体是哪个服务或组件输出的日志，完全违背了日志系统的设计初衷。

DI容器的注册逻辑设计 #

.NET原生日志框架默认只注册了泛型ILogger<T>的实现，并没有将非泛型ILogger作为可直接解析的服务注入容器。Serilog作为适配.NET日志抽象的实现，也遵循了这个约定——它只会为带有明确分类（泛型类型或手动命名）的请求提供Logger实例。如果强行让容器解析非泛型ILogger，容器找不到对应的注册项，自然会报错。

明确开发意图，避免混乱 #

使用泛型ILogger<T>可以让代码意图更清晰：注入的Logger就是专门给当前服务T用的，不会和其他服务的Logger混淆。如果允许非泛型注入，开发者很容易在不同服务中混用同一个无分类的Logger，导致日志上下文混乱，后期维护时很难理清日志归属。

补充：如何获取非泛型ILogger？ #

如果确实需要在代码中使用非泛型ILogger，可以手动在DI容器中注册一个绑定到特定分类的实例，比如：

services.AddSingleton<ILogger>(sp => 
    sp.GetRequiredService<ILogger<MyService>>());

但本质上这还是依赖了泛型ILogger的分类能力，只是通过包装提供了非泛型的访问方式。

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