在 EF Core SQL 注入防范中，有几个核心判断：EF Core 本身并不提供自动防注入机制，安全性完全取决于你选择哪条 API 以及如何传递参数。如果忽视这一点，那么FromSqlRaw 和 ExecuteSqlRaw 基本上等于裸奔——不手动进行参数化，就相当于把数据库的钥匙直接交给用户。
何时必须使用参数化？FromSqlRaw 和 ExecuteSqlRaw 的常见陷阱
这两个方法不会对字符串进行任何解析或转义处理，只是原封不动地将传入的字符串发送给数据库驱动。即使只拼接一个字段值，只要使用 + 或 $"" 插入用户输入，就会立即产生漏洞。
FromSqlRaw($"SELECT * FROM Users WHERE Name = '{name}'")→ 危险！C# 层已完成拼接，例如'admin' OR 1=1 --可直接注入 SQLFromSqlRaw("SELECT * FROM Users WHERE Name = " + name)→ 同样危险，字符串拼接发生在 EF 执行之前FromSqlRaw("WHERE Status = {0}", "Active")→ 安全，EF 将{0}视为参数占位符，采用参数绑定机制FromSqlRaw("WHERE Name = @name", new SqlParameter("@name", name))→ 安全，显式构造参数对象，明确传递参数
FromSqlInterpolated 虽然便捷，但存在硬性限制
它能自动对插值变量进行参数化，但仅识别纯变量引用，不会处理表达式或拼接逻辑。
- ✅
context.Users.FromSqlInterpolated($"SELECT * FROM Users WHERE Name = {name}")→ 安全，变量直接引用 - ✅
context.Users.FromSqlInterpolated($"SELECT * FROM Users WHERE CreatedAt > {DateTime.UtcNow.AddDays(-7)}")→ 安全，表达式结果作为参数 - ❌
context.Users.FromSqlInterpolated($"SELECT * FROM Users WHERE Name LIKE {name + "%"}")→ 危险！name + "%"是 C# 表达式，其结果整体被当作参数，导致语义错误 - ❌
context.Users.FromSqlInterpolated($"SELECT * FROM Users WHERE {whereClause}")→ 完全无效！whereClause是字符串变量，会被整体当作参数值，导致 WHERE 条件失效
表名、列名、ORDER BY 等结构部分无法参数化
数据库引擎不支持对标识符（identifier）进行参数化，例如 FromSqlRaw("SELECT * FROM {0}", tableName) 在语法上本身就是非法的，EF 也不会帮助你校验或转义。
- 动态表名/列名必须采用白名单机制：例如仅允许
new[] { "Users", "Orders", "Products" }中的值 - 排序字段和排序方向必须显式校验：例如
if (!new[] { "Name", "Email", "CreatedAt" }.Contains(sortField)) throw ...；if (sortDir != "ASC" && sortDir != "DESC") throw ... - 禁止使用
string.Concat、StringBuilder或Replace进行所谓的“关键词过滤”来糊弄——例如删除了"or"，但"oR"或换行符仍然可以绕过防护
真正棘手的并非写对那几行参数化代码，而是需要时刻分清“数据”与“结构”：值可以参数化，但 SQL 骨架必须依赖白名单来兜底。只要漏掉任何一个动态拼接点，整条防护链就会失效。
