我之前也碰到过类似的问题，结合你提到的那些EF Core相关议题，咱们来拆解下可能的原因和对应的解决办法：

最常见的元凶：延迟执行+多次枚举 #

EF Core的FromSqlRaw/FromSqlInterpolated返回的是IQueryable<T>，这是延迟执行的——也就是说，只有当你真正去枚举结果（比如调用ToList()、Count()，或者在foreach里遍历）的时候，才会去数据库执行存储过程。如果你多次枚举这个IQueryable，就会触发多次存储过程调用。

举个典型的错误例子：

// 这里只是定义了查询，还没执行数据库操作
var query = _context.MyEntities.FromSqlRaw("EXEC GetMyFilteredData @Param={0}", paramValue);

// 第一次执行存储过程
var totalCount = query.Count();
// 第二次执行存储过程
var dataList = query.ToList();

解决办法也很简单：先把结果加载到内存，后续操作都基于内存集合：

// 一次性执行存储过程，把结果存到List里
var dataList = _context.MyEntities.FromSqlRaw("EXEC GetMyFilteredData @Param={0}", paramValue).ToList();
// 内存操作，不会再调用数据库
var totalCount = dataList.Count;

另一个可能：客户端评估触发的额外查询 #

如果你在存储过程查询之后，又加了一些EF Core无法转换为SQL的Linq操作（比如自定义方法、复杂的条件判断），EF Core会先执行存储过程把所有数据拉到客户端，然后在内存里做二次处理。虽然这不是两次存储过程调用，但可能会被你误认为是两次资源请求。

怎么排查？打开客户端评估的警告，让EF Core直接告诉你哪里出问题：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer("你的连接字符串")
        // 遇到客户端评估直接抛出异常，方便定位
        .ConfigureWarnings(warnings => warnings.Throw(RelationalEventId.QueryClientEvaluationWarning));
}

如果触发了这个异常，你要么把额外的逻辑写到存储过程里，要么先把数据加载到内存再处理。

其他需要排查的点 #

• 实体跟踪导致的额外加载：如果你的实体有导航属性，EF Core可能会触发额外的查询来加载关联数据（比如延迟加载）。如果不需要跟踪实体变化，用AsNoTracking()可以避免这种情况：

  var data = _context.MyEntities
      .FromSqlRaw("EXEC GetMyData")
      .AsNoTracking()
      .ToList();
  

• 存储过程本身的问题：确保你的存储过程是纯SELECT操作，没有修改数据的副作用——如果存储过程里有INSERT/UPDATE，某些情况下EF Core的处理逻辑可能导致重复执行。
• 版本bug：你提到的那些早期议题里的问题，在EF Core 3.0之后的版本已经被大量修复了。如果还在使用旧版本，升级到最新稳定版（比如EF Core 8）大概率能解决问题。

内容的提问来源于stack exchange，提问作者Raphael Laurent