LogTo是EF Core最轻量的SQL日志方式，开发阶段一行代码optionsBuilder.LogTo(Console.WriteLine)即可输出SQL、参数及耗时；需配合LogLevel.Information和EnableSensitiveDataLogging()显示完整细节，仅限开发环境使用。
LogTo 是 EF Core 最轻量、最直接的 SQL 日志输出方式，开发阶段开箱即用，不需要引入 Microsoft.Extensions.Logging 或第三方日志库。
用 LogTo 输出到控制台或调试窗口
在自定义 DbContext 的 OnConfiguring 方法里调用即可：
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
=> optionsBuilder.LogTo(Console.WriteLine);
这样每次执行查询、保存等操作时，SQL 语句、参数、执行耗时都会打印到控制台。注意：Console.WriteLine 在 Windows Forms 或某些托管环境（如 IIS）中可能不显示，此时可换用 Debug.WriteLine：
-
LogTo(Debug.WriteLine)会输出到“输出”窗口（Visual Studio 调试模式下可见） - 若部署在 Linux 容器中，
Console.WriteLine仍有效，日志会进 stdout 流，可被docker logs捕获 - 该方式默认只记录
Warning及以上级别（如超时、失败），如需看到所有 SQL，得显式启用LogLevel.Information
让 LogTo 显示参数和完整 SQL
EF Core 默认对敏感数据（如密码字段）做脱敏处理，且参数值常以占位符形式出现（如 @__id_0）。要看到真实参数值，必须启用 EnableSensitiveDataLogging：
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder
.LogTo(Console.WriteLine, LogLevel.Information)
.EnableSensitiveDataLogging();
}
关键点：
-
LogLevel.Information才能捕获普通查询的 SQL 和参数；Warning只捕获慢查询或异常 -
EnableSensitiveDataLogging必须在LogTo之后调用才生效（顺序敏感） - 该选项仅用于开发环境，生产环境禁用——它会把明文密码、身份证号等直接打到日志里
写入文件而不是控制台
LogTo 接收任意 Action<string>，所以可以轻松转向文件：
var logFile = new StreamWriter("ef-logs.txt", append: true) { AutoFlush = true };
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
=> optionsBuilder.LogTo(logFile.WriteLine);
但要注意：
- 别忘了设
AutoFlush = true，否则日志可能滞留在缓冲区不落盘 - 多线程并发写入同一文件时，
StreamWriter不是线程安全的，容易丢日志或乱序；可用ConcurrentQueue<string>+ 后台轮询写入，或改用ILogger配合FileLoggerProvider - 长期运行的服务应考虑日志滚动（按大小/日期切分），
LogTo本身不支持，得自己封装
为什么不用 Database.Log（EF6 风格）
如果你从 EF6 迁移过来，可能会想沿用 context.Database.Log = Console.WriteLine，但这在 EF Core 中完全无效——Database 类型已移除 Log 属性。EF Core 统一收口到 DbContextOptionsBuilder 上，所有日志配置必须在构建上下文前完成。试图在运行时动态开关日志（比如某个请求开启、某个请求关闭），LogTo 无法满足，此时得上 IDbCommandInterceptor 或 ILogger。
真正需要区分环境、做分级、加结构化字段、对接 ELK 或 Sentry 的场景，LogTo 就只是个临时拐杖——它不提供日志上下文（如请求 ID）、不支持异步写入、也不兼容现有日志生态。这些事，留给 Microsoft.Extensions.Logging 做更稳妥。
