日志级别没生效是因为全局阈值和logger实例启用状态双重过滤；需确保appsettings.json中logging.loglevel.default≤debug，或为特定命名空间/类单独配置，且setminimumlevel代码配置优先于配置文件。
日志级别没生效，八成是配置没对上——不是代码写错了，而是LogLevel判断发生在两个地方：全局阈值 + 当前 logger 实例的启用状态，缺一不可。
为什么 logger.LogDebug("msg") 没输出？
最常见原因是全局最小级别设得太高。比如 appsettings.json 里只写了 "Default": "Information"，那 LogDebug 和 LogTrace 就直接被框架跳过，连格式化都不做。
- 检查
appsettings.json中Logging.LogLevel.Default的值，它必须 ≤Debug才能看到LogDebug - 若只想放开某类日志（如数据库操作），可单独配命名空间：
"MyApp.Data": "Debug"，避免全局开Debug导致日志爆炸 -
IsEnabled(LogLevel.Debug)返回false时，说明当前 logger 已被过滤，不用再调LogDebug浪费性能
log4net 中 level value="INFO" 是怎么拦住 DEBUG 的？
log4net 的 <root></root> 级别是硬性闸门：只有日志级别 ≥ 配置值才会进入后续流程。设成 INFO，DEBUG 和 TRACE 就在入口被丢弃，和 appender 无关。
- 改配置文件里的
<level value="DEBUG"></level>或"ALL"才能放行低级别日志 - 如果只希望某个类（如
MyApp.Services.PaymentService）打Debug，加专属<logger name="MyApp.Services.PaymentService"></logger>节点，别动根节点 - 注意
<filter></filter>标签（如LevelRangeFilter）可能二次拦截，优先检查它是否把DEBUG明确排除了
用 Microsoft.Extensions.Logging 时，SetMinimumLevel 和配置文件谁优先？
代码里调 SetMinimumLevel 会覆盖配置文件中同名项，但仅限于它作用的 ILoggingBuilder 实例范围。多个配置源共存时，以“最后注册”的为准。
- 在
Program.cs中先builder.Logging.SetMinimumLevel(LogLevel.Debug)，再AddConsole()，那控制台就能看到Debug - 但如果同时在
appsettings.json里设了"Default": "Warning"，且没调ClearProviders()，控制台 provider 仍会受配置文件约束 - 开发环境建议用代码动态设级：
if (env.IsDevelopment()) builder.Logging.SetMinimumLevel(LogLevel.Debug);
真正容易被忽略的是：日志级别过滤发生在写入前，而结构化日志的占位符解析、JSON 序列化等操作也依赖这个判断。一旦 IsEnabled 返回 false，所有参数表达式（包括可能抛异常的函数调用）都不会执行——这是性能保护，也是 debug 时容易误判“参数没传进去”的根源。
