EF Core 中应通过 IDbCommandInterceptor 的 ReaderExecuting 和 NonQueryExecuting 方法拦截并修改 SQL 命令；CommandPreparing 不可靠，不适用于修改 CommandText；需保持参数占位符一致，避免注入风险。
EF Core 中如何拦截并修改即将执行的 SQL 命令
EF Core 本身不提供直接“修改原始 SQL 字符串”的钩子（比如不能像 ADO.NET 那样在
赋值前随意替换），但可通过
拦截命令对象，在执行前动态修改其
、
或行为逻辑。关键点是：必须在命令真正发送到数据库前介入，且要区分查询/非查询、同步/异步调用。
使用
修改
实现拦截器时，重写
（查询）、
（增删改）等方法，在其中拿到
实例后直接改
即可。注意以下几点：
修改
是允许的，但 EF Core 不保证该字符串未被参数化处理过；若原语句含
等参数占位符，需保持参数名与数量一致，否则抛
必须调用
或返回
，否则命令不会执行
若只针对特定上下文生效，注册时需用
在
中添加，而非全局单例
示例：把所有
开头的语句自动追加
为什么不能在
中修改
是 EF Core 6+ 新增的拦截点，但它发生在命令“准备阶段”，此时
可能尚未生成（尤其对 LINQ 查询），或已被内部缓存优化，直接修改它常无效甚至被忽略。实际测试表明：
C知道
CSDN推出的一款AI技术问答工具
下载
LINQ to Entities 查询走的是表达式树编译路径，
在
时才最终确定
更适合做日志、统计或取消操作，不适合文本改写
若强行在
中赋值
，EF Core 可能后续覆盖它，导致修改丢失
修改参数或绕过 EF Core 直接执行原始 SQL 的边界场景
当需要深度控制 SQL（如动态表名、复杂 hint、存储过程重写），EF Core 的拦截机制会力不从心。此时应考虑：
用
手动打开连接，创建
并设置
—— 完全绕过 EF Core 拦截链，但也失去变更跟踪、事务自动绑定等特性
若只是想加参数（如租户 ID），优先用
添加到
，而不是拼接进 SQL 字符串，避免注入风险
EF Core 8 支持
+ 自定义
替换，但该接口属内部 API，不稳定，不建议生产使用
真正稳定的修改入口只有
和
，其他方式要么不可靠，要么破坏 EF Core 的契约。别试图在
前改 LINQ 表达式树——那属于另一个技术栈了。
DbCommand.CommandTextIDbCommandInterceptorCommandTextParametersIDbCommandInterceptorCommandTextReaderExecutingNonQueryExecutingDbCommandCommandTextCommandText@p0SqlExceptionbase.ReaderExecutingcommandAddInterceptorsDbContextOptionsBuilderSELECTWITH (NOLOCK)public class SqlLockInterceptor : DbCommandInterceptor
{
public override InterceptionResult ReaderExecuting(
DbCommand command, CommandEventData eventData, InterceptionResult result)
{
if (command.CommandText.StartsWith("SELECT", StringComparison.OrdinalIgnoreCase))
{
command.CommandText = command.CommandText.TrimEnd() + " WITH (NOLOCK)";
}
return base.ReaderExecuting(command, eventData, result);
}
} CommandPreparingCommandPreparingCommandTextCommandTextReaderExecutingCommandPreparingCommandPreparingCommandTextDatabase.GetDbConnection()DbCommandCommandTextSqlParametercommand.ParametersExecuteSqlRawIQuerySqlGeneratorReaderExecutingNonQueryExecutingSaveChanges