.NET为何使用泛型ILogger？与非泛型ILogger的差异对比

在.NET微软默认配置中，日志记录器通常通过ILogger<Worker>这类泛型接口注入，示例代码如下（来自微软官方文档）：

public sealed class Worker : BackgroundService
{
    private readonly ILogger<Worker> _logger;

    public Worker(ILogger<Worker> logger) =>
        _logger = logger;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            _logger.LogInformation("Worker running at: {time}", DateTimeOffset.UtcNow);
            await Task.Delay(1_000, stoppingToken);
        }
    }
}

一、泛型ILogger<T>除指定日志名称外的优势 #

• 自动绑定类型上下文：泛型版本会自动把日志和当前注入的类型（比如Worker）绑定，日志系统能直接识别日志所属的类，排查问题时可以快速定位到日志产生的组件，不用手动在日志消息里加类名标识。
• 简化日志粒度配置：配置日志过滤规则时，可以直接针对特定类型或命名空间设置日志级别，比如只开启Worker类的Debug级日志；而非泛型版本得手动指定日志名称才能实现相同的粒度控制，容易写错。
• 避免硬编码日志名称：用泛型时不用手动写死日志名称字符串，减少拼写错误的概率，类名变更时日志名称会自动同步，维护成本更低。

二、使用非泛型ILogger会缺失的特性 #

• 类型级别的日志过滤能力：非泛型ILogger默认用固定的日志名称（没指定的话一般是"Microsoft.Extensions.Logging.Logger"），没法直接通过类型配置日志规则，只能靠全局或手动指定的名称过滤，灵活性差。
• 自动上下文标识：日志里不会自动携带类型信息，得开发者手动在日志消息里加类名等标识，不然排查问题时很难定位日志来源，增加调试成本。
• 依赖注入的类型安全：泛型版本由容器自动解析对应的日志实例，不用手动指定名称；而非泛型版本要实现类似效果，得手动传入类型名称，容易出现拼写错误，还没法享受编译时的类型检查。

三、GitHub未解决的分歧与更多差异点 #

在相关GitHub议题中，社区对以下差异点还没达成共识：

• 日志范围的关联差异：部分开发者反馈，泛型ILogger<T>在使用日志范围时，是否自动关联类型上下文的表现不一致，而非泛型版本得手动管理范围的上下文信息，官方目前还没统一这一行为。
• 性能差异的争议：有人认为泛型版本在日志实例的创建和缓存上有微小性能优势，因为容器可以提前缓存泛型对应的实例；但也有开发者觉得这种差异在实际场景中可以忽略，官方也没给出明确的性能基准测试结论。
• 第三方日志框架兼容性：部分第三方日志提供者对泛型ILogger<T>的支持更完善，能提供更丰富的类型关联日志特性；而非泛型版本在某些框架下可能没法完全利用这些扩展功能，不过这一点因框架而异，没有统一结论。

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