防止SQL注入的Dapper与EntityFramework参数化对比

Dapper和Entity Framework Core在防止SQL注入方面都采用了参数化查询机制，但实现方式和底层原理存在本质差异。Dapper通过底层ADO.NET的DbParameter直接绑定参数值，将用户输入与SQL语句结构完全分离；Entity Framework Core则通过LINQ表达式树解析和参数化命令对象自动生成安全的SQL语句。两者在正确使用的前提下都能有效防止SQL注入，但EF Core如果使用Raw SQL或FromSqlRaw等方法时仍需手动参数化，而Dapper天然就是参数化驱动的。下面从原理、代码实现、性能、适用场景四个维度做全面拆解。

SQL注入攻击的核心在于攻击者将恶意代码拼接进SQL语句中，让数据库把用户输入当成SQL指令执行。比如一个登录查询，如果直接拼接字符串：

string sql = "SELECT * FROM Users WHERE Username='" + username + "' AND Password='" + password + "'";

攻击者输入用户名为 admin'--，就能绕过验证。参数化查询的防御逻辑是：SQL语句的结构和数据是分开传输的，数据库先编译SQL模板，再把参数值填入占位符，任何特殊字符都不会被解析为SQL语法。这是目前公认最可靠的防注入手段，没有之一。

Dapper是一个轻量级ORM，本质上是对ADO.NET的封装。它的参数化查询直接映射到DbCommand的Parameters集合。当你写Dapper代码时，框架会自动把匿名对象或DynamicParameters的属性值绑定到SQL中的@参数名上。

var sql = "SELECT * FROM Users WHERE Username = @Username AND Status = @Status";
var users = connection.Query<User>(sql, new { Username = inputName, Status = 1 });

Dapper在执行时会做以下几件事：创建DbCommand对象，将SQL文本设为CommandText，遍历匿名对象的属性生成DbParameter，设置ParameterName和Value，然后调用ExecuteReader。整个过程中，参数值永远不会被拼接到SQL字符串里，而是作为独立的参数包发送给数据库引擎。即使inputName的值是 "'; DROP TABLE Users;--"，数据库也只会把它当成一个普通字符串去匹配，不会执行任何破坏性操作。

Dapper还支持DynamicParameters，适合动态构建查询条件的场景：

var p = new DynamicParameters();
p.Add("@Name", userInput, DbType.String);
p.Add("@Age", 25, DbType.Int32);
var result = connection.Query("SELECT * FROM Users WHERE Name = @Name AND Age = @Age", p);

这种方式同样是参数化的，安全性有保障。Dapper的优势在于它几乎没有抽象层，你写什么SQL它就执行什么SQL，参数绑定逻辑简单透明，开发者对SQL有完全的控制权。

EF Core的防注入机制分两个层面。第一层是LINQ查询，这是EF Core最推荐的用法。当你写LINQ表达式时，EF Core会把它翻译成表达式树，再由查询提供程序（如SQL Server Provider）解析成参数化SQL。

var users = context.Users
    .Where(u => u.Username == inputName && u.Status == 1)
    .ToList();

这段代码在背后生成的SQL大致是：

SELECT [u].[Id], [u].[Username], [u].[Status]
FROM [Users] AS [u]
WHERE [u].[Username] = @__inputName_0 AND [u].[Status] = 1

EF Core自动生成了@__inputName_0参数，值通过DbParameter传递。开发者不需要手动处理参数绑定，框架全自动完成。这是EF Core最安全的使用方式，因为你根本接触不到原始SQL字符串。

第二层是Raw SQL查询。EF Core提供了FromSqlRaw、FromSqlInterpolated、ExecuteSqlRaw等方法。这里要特别注意区分：

// 危险！字符串拼接，存在注入风险
var bad = context.Users.FromSqlRaw("SELECT * FROM Users WHERE Username = '" + inputName + "'");

// 安全！使用插值字符串，自动参数化
var safe = context.Users.FromSqlInterpolated($"SELECT * FROM Users WHERE Username = {inputName}");

FromSqlInterpolated会把插值表达式中的变量自动转成DbParameter，而FromSqlRaw如果你用字符串拼接就等于手动拼SQL，注入风险立刻回来。EF Core的文档明确警告过这个问题。所以用EF Core写原生SQL时，必须用参数化的方式，要么用FromSqlInterpolated，要么手动传参数数组。

从防御能力角度看，Dapper和EF Core在正确使用时安全性等同，都是参数化查询。但差异在于"犯错的概率"和"犯错后的后果"。

Dapper因为是手写SQL，开发者必须时刻记得用参数占位符。如果某个地方偷懒直接拼接了字符串，注入漏洞就产生了。但Dapper的代码结构让你一眼就能看到SQL，审查起来比较直观。

EF Core的LINQ查询天然安全，几乎不可能写出注入漏洞。但一旦开发者为了性能或复杂查询转向Raw SQL，如果不熟悉FromSqlInterpolated的用法，很容易写出FromSqlRaw拼接字符串的危险代码。而且EF Core的表达式树翻译过程是黑盒，你不容易直观看到最终生成的SQL是否真的参数化了，需要借助日志或SQL Profiler去验证。

还有一个容易被忽略的点：EF Core的全局查询过滤器（Global Query Filters）和拦截器（Interceptors）如果处理不当，也可能引入注入风险。比如在拦截器中手动拼接SQL字符串就会出问题。Dapper没有这些高级抽象，反而更"笨"更安全。

在性能层面，Dapper通常比EF Core快30%-50%，因为它没有表达式树解析、变更追踪、实体状态管理等开销。但这和安全性没有直接关系。参数化查询本身对性能的影响很小，数据库会缓存执行计划，参数化反而有利于计划复用。

从实际项目角度建议：如果团队SQL能力强、追求极致性能和精细控制，选Dapper，但要建立代码审查机制确保所有查询都用参数化；如果团队更熟悉面向对象开发、希望减少手写SQL的出错概率，选EF Core的LINQ方式，同时对Raw SQL的使用做严格规范。

无论选哪个，都应该在数据库层面再加一道防线：使用最小权限原则，应用程序连接数据库的账号只给必要的SELECT、INSERT、UPDATE权限，禁止DROP、ALTER等高危操作。这样即使代码层面出了漏洞，攻击者能造成的破坏也有限。

第一，永远不要用字符串拼接构建SQL，不管用Dapper还是EF Core。第二，Dapper中始终使用@参数或DynamicParameters，不要用$"{variable}"这种字符串插值直接塞进SQL字符串。第三，EF Core优先使用LINQ，必须用Raw SQL时选择FromSqlInterpolated或带参数的FromSqlRaw。第四，开启数据库的参数化查询日志，定期审计生成的SQL是否存在拼接痕迹。第五，结合输入验证、最小权限、WAF等多层防御，不要把安全押注在单一技术上。

总结一句话：Dapper和EF Core都是参数化的，都能防SQL注入，但"能防"不等于"不会出错"。真正的安全来自开发者的意识和规范，工具只是帮你降低了门槛，不能替代正确的编码习惯。