Where查询默认安全，因EF Core将变量（如email）转为数据库参数（如@p0）而非拼入SQL字符串，攻击输入仅作文本值比较；但需避免ToString()、反射取字段名或手动拼接表达式树等破坏机制的行为。
Where 查询为什么默认安全
EF Core 的 Where 等 LINQ 操作默认防注入，因为表达式树在翻译成 SQL 时，会把变量（如 email）转为数据库参数（如 @p0），而不是拼进 SQL 字符串里。你写 _context.Users.Where(u => u.Email == email)，数据库收到的是 WHERE [Email] = @p0，攻击者输 admin' OR 1=1 -- 也只会当作文本值比较，不会执行。
但前提是别破坏这个机制：
- 不要调用
.ToString()或Expression.ToString()把表达式转成字符串再喂给 EF - 别用反射动态取字段名：
u.GetType().GetProperty(fieldName)—— 这等于把用户输入当代码跑 - 避免手动拼接表达式树后编译成
Func<>，否则查询会退化为内存过滤，且字段名若来自用户输入就变成列名注入
FromSqlRaw 和 ExecuteSqlRaw 必须手动参数化
FromSqlRaw 和 ExecuteSqlRaw 不做任何自动参数化，传什么它就执行什么。写 FromSqlRaw($"SELECT * FROM Users WHERE Name = '{name}'")，恶意输入早在 C# 层就混进 SQL 了，数据库收到的就是完整可执行语句。
正确做法只有一种：用占位符 + 分离参数
- 位置参数：
.FromSqlRaw("WHERE Status = {0} AND CreatedAt > {1}", "Active", DateTime.UtcNow.AddDays(-7)) - 命名参数 +
SqlParameter：.FromSqlRaw("WHERE Name = @name", new SqlParameter("@name", name)) -
FromSqlInterpolated只对纯变量插值安全（如{name}），{name + "%"}或{"Name = '" + name + "'"}都不安全 —— C# 层已拼完，EF 来不及干预 -
ExecuteSqlRaw不支持链式AddParameter，只能靠占位符或SqlParameter数组
表名、字段名、ORDER BY 不能参数化，必须白名单校验
数据库引擎根本不支持参数化标识符（identifier）。传 SqlParameter 给 ORDER BY @sortField，结果是 ORDER BY 'Email' —— 排序失效，还可能报错。
动态结构部分必须硬控制：
- 字段名白名单：
new[] { "Name", "Email", "CreatedAt" }.Contains(sortField)，不匹配直接拒掉 - 排序方向显式判断：
sortDir == "desc" ? "ORDER BY Name DESC" : "ORDER BY Name ASC"，别拼ORDER BY {sortField} {sortDir} - 表名同理，禁止通过反射、配置文件或用户输入动态构造
FROM {tableName} - 别用
string.Format或Replace“转义”字段名 —— 规则易绕过，不可靠
批量操作和迁移脚本也要防注入
EntityFramework Plus 的批量更新（如 .Update(p => new Product { Price = p.Price * 1.1m })）内部用参数化，本身安全；但如果你在批量操作前自己拼了 SQL 字符串，风险照旧。
迁移脚本里的 DbMigration.Sql() 或上下文的 Database.ExecuteSqlCommand() 同样要求用户输入必须参数化：
context.Database.ExecuteSqlCommand("UPDATE Posts SET Rating = 5 WHERE Author = @author", new SqlParameter("@author", userSuppliedAuthor))- 迁移中若需动态表名/字段名，仍得走白名单 —— EF 迁移 API 明确警告：不设计用于处理不受信任的输入
最常被忽略的一点：安全不是“用了 EF 就万事大吉”，而是每处动态拼接都得问一句——这东西是不是用户可控？如果是，它属于值还是结构？值走参数化，结构走白名单，二者混用等于没防。
