EF Core连接Oracle时SQL未打印，需将日志级别设为Information或更低，并在AddDbContext时通过options.LogTo(...)配置；确保查询真正执行，且终端支持UTF-8编码。
EF Core连接Oracle时SQL没打印出来？先确认日志级别
默认情况下，EF Core不会输出SQL语句，哪怕你用了Oracle.EntityFrameworkCore。关键不是驱动版本，而是日志配置是否启用且级别足够低。EF Core的SQL日志属于Microsoft.EntityFrameworkCore.Database.Command类别，日志级别必须设为Information或更低（如Debug），否则Executing DbCommand这类消息直接被过滤掉。
- 在
Program.cs中注册DbContext时，确保调用.LogTo(Console.WriteLine, LogLevel.Information)或更细粒度地指定类别 - 若用
ILoggerFactory手动配置，需显式添加Microsoft.EntityFrameworkCore.Database.Command前缀的过滤器 - Oracle驱动本身不拦截或修改日志行为，但旧版
Oracle.ManagedDataAccess（如19.x之前）可能因内部异常吞掉部分命令日志，建议至少用21c+客户端
LogTo方法不生效？检查DbContext生命周期和执行时机
LogTo只对后续创建的DbContext实例生效，如果在AddDbContext之后才调用LogTo，或者在DbContext已构造完毕（比如在Controller里直接new）后再配日志，SQL照样不会打印。正确做法是把日志配置嵌入DbContextOptionsBuilder构建过程。
- 在
Startup.ConfigureServices或Program.cs的AddDbContext里，用options.LogTo(...)，不是在DbContext类内部或实例化后补 - 确保查询真正执行：用
.ToList()、.FirstOrDefault()等触发实际数据库访问，IQueryable定义阶段不产生SQL - 异步方法（如
ToListAsync）的日志和同步方法一样输出，无需额外配置
看到参数占位符但看不到真实值？这是正常行为
EF Core默认打印的是带:p0、:p1这类命名参数的SQL，而不是替换后的字符串。这是为了安全和性能，避免日志泄露敏感数据，也防止SQL注入痕迹混入日志。Oracle驱动本身不提供“展开参数”的开关，EF Core也不支持一键开启原始值打印。
- 如需验证参数实际值，可捕获
DiagnosticSource事件，监听Microsoft.EntityFrameworkCore.Database.Command.CommandExecuted，从中提取command.Parameters - 开发期临时调试可用
ToString()查看DbCommand对象，但注意这会触发一次额外执行（慎用） - 第三方工具如
MiniProfiler能同时显示SQL和参数值，但需集成且对Oracle支持依赖驱动兼容性
Oracle特殊语法导致SQL截断或乱码？关注NLS设置和日志编码
Oracle返回的SQL文本可能含N'xxx'前缀、双引号标识符或中文注释，若控制台或日志系统编码不匹配（如Windows默认GBK而日志是UTF-8），会出现乱码甚至截断。这不是EF Core的问题，而是终端/日志接收方的字符处理问题。
- 在
Console.WriteLine前加Console.OutputEncoding = Encoding.UTF8（.NET 6+默认已是UTF-8，但某些环境仍需显式设置） - 避免在SQL中写长注释或特殊字符——EF Core生成的SQL本身不含这些，但如果你手动拼接
FromSqlRaw，就得自己负责可读性 - Oracle的
VARCHAR2与NVARCHAR2字段类型差异不影响SQL打印，但会影响参数绑定逻辑，日志里看到的参数类型（如OracleDbType.Varchar2）需与实体属性匹配，否则可能隐式转换失败
