ef core原生sql查询必须参数化，查数据优先用fromsqlinterpolated（自动命名参数、防注入），改数据用executesqlinterpolatedasync（异步、返回影响行数）；标量或dto查询用sqlqueryraw；fromsql后链式linq会触发内存过滤，应避免。
EF Core 原生 SQL 查询不能直接拼字符串，必须参数化；查数据用 FromSqlRaw 或 FromSqlInterpolated，改数据用 ExecuteSqlRaw 或 ExecuteSqlInterpolatedAsync。
查数据：用 FromSqlRaw 还是 FromSqlInterpolated？
优先选 FromSqlInterpolated——它自动把插值变量转成命名参数，不手动处理占位符，也不怕漏写 SqlParameter。
-
FromSqlRaw必须显式传参，比如"SELECT * FROM Users WHERE Age > {0}"后跟18，但若混入用户输入又忘了参数化，极易触发 SQL 注入 -
FromSqlInterpolated写法更自然：$"SELECT * FROM Users WHERE Name LIKE {searchTerm}"，EF Core 底层自动包装为@p0参数，安全且不易出错 - 两者都只能用于
DbSet<t></t>，返回类型必须是已映射的实体类（或其可映射基类/接口），不能直接返回匿名对象 - 如果只是读取展示，加上
.AsNoTracking()能省掉变更跟踪开销，尤其对大结果集明显
改数据：为什么不能用 FromSqlRaw 执行 UPDATE？
FromSqlRaw 只接受以 SELECT 开头的语句，EF Core 会尝试把它映射成实体集合。执行 INSERT/UPDATE/DELETE 必须走 DbContext.Database 上的方法。
- 用
ExecuteSqlRaw或更推荐的ExecuteSqlInterpolatedAsync（异步、自动参数化） - 返回值是受影响行数（
int），可用于判断是否成功，比如if (rows == 0) throw new InvalidOperationException("未找到匹配记录") - 原生 SQL 不触发 EF Core 的变更跟踪、验证逻辑、
SaveChanges拦截器，也不会调用实体的构造函数或属性 setter - 别在事务外单独开连接——复用
context.Database.GetDbConnection()，确保与 EF 的事务生命周期一致
查标量值或自定义 DTO：怎么绕过实体映射限制？
当 SQL 返回的是 COUNT(*)、string、或字段名/类型不匹配实体时，FromSqlRaw 就不适用了。
- 标量查询（如计数、求和）用
Database.SqlQueryRaw<t>()</t>，比如context.Database.SqlQueryRaw<long>("SELECT COUNT(*) FROM Users").Single()</long> - 查自定义结构（非实体）需轻量 DTO：定义一个只有 public 属性或带匹配参数的构造函数的 class，再用
SqlQueryRaw<mydto></mydto> -
SqlQueryRaw返回的结果默认不被上下文跟踪，也不参与 EF 的状态管理，这点和FromSqlRaw默认行为不同 - 注意大小写：PostgreSQL 或开启区分大小写的 SQL Server 下，列名必须和 DTO 属性名严格一致（包括大小写）
最容易忽略的一点：链式调用 .Where() 会掉进内存过滤陷阱
很多人写完 FromSqlRaw 还顺手加个 .Where(x => x.IsActive)，以为 EF 会把它翻译进 SQL——其实不会。
- EF Core 对
FromSqlRaw后的 LINQ 方法不做翻译，而是先执行原始 SQL 把所有数据拉到内存，再用 C# 代码过滤 - 数据量稍大就卡死，CPU 和内存飙升，线上容易出事故
- 真要组合条件，要么把逻辑写进原始 SQL 里，要么用
FromSqlInterpolated动态拼接 WHERE 子句（仍保持参数化） - 存储过程调用同理：不能在
FromSqlRaw("EXEC GetUsers")后再加.OrderBy()，得让存储过程自己排序
