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