防止SQL注入最有效的方法就是参数化查询，而使用Dapper这类轻量级ORM可以非常简洁、高效地实现这一点。直接来说，SQL注入的根本原因在于将用户输入的数据与SQL命令字符串进行拼接，攻击者通过精心构造的输入，可以改变原有SQL语句的逻辑，从而窃取、篡改或破坏数据库。参数化查询将数据与指令分离，用户输入的数据在整个数据库查询过程中始终被视为“数据”而非“代码”的一部分，从而从根本上杜绝了注入的可能。Dapper通过扩展方法（如"Query", "Execute"）支持将匿名对象或"DynamicParameters"作为参数传入，内部会将其转换为安全的参数化SQL命令，你几乎不需要写任何额外的防御代码，就能获得企业级的安全保障。

一、 为什么字符串拼接是危险的，而参数化是安全的？

假设你有一段用户登录的代码，传统拼接字符串的方式可能是这样的："string sql = "SELECT * FROM Users WHERE Username = '" + username + "' AND Password = '" + password + "'""。如果用户输入的用户名是 "admin'--"，那么最终的SQL语句会变成 "SELECT * FROM Users WHERE Username = 'admin'--' AND Password = '...'"。"--"在SQL中是注释符，这意味着密码检查被完全绕过了，攻击者可以轻松以管理员身份登录。

而参数化查询的写法完全不同。以Dapper为例，你会这样写：

var user = connection.QuerySingleOrDefault<User>(
    "SELECT * FROM Users WHERE Username = @Username AND Password = @Password",
    new { Username = username, Password = password }
);

在这个例子中，"@Username"和"@Password"是参数占位符。Dapper（实际上是底层的ADO.NET）会向数据库发送一个编译好的命令模板，并将"username"和"password"变量的值作为独立的参数传递过去。数据库引擎明确知道哪些部分是命令结构，哪些部分是数据值。即使"username"变量里包含了"admin'--"，它也会被当作一个完整的字符串值去匹配"Username"字段，而不会被解释为SQL命令。这就是本质区别：拼接是把数据和代码混在一起煮成一锅粥；参数化是把数据和代码分装在两个不同的盒子里，泾渭分明。

二、 Dapper如何实现参数化查询：从匿名对象到DynamicParameters

Dapper提供了极其灵活的传参方式。最简单的是使用匿名对象，如上例所示。Dapper会通过反射读取对象的属性名，并将其与SQL语句中的参数名（带"@"、":"或"?"，取决于数据库类型）进行匹配。这种方式代码简洁，适用于大多数场景。

对于更复杂的需求，例如参数方向（输入/输出）、数据类型、大小等控制，可以使用"DynamicParameters"类。这在调用存储过程或处理复杂数据类型时非常有用。

var parameters = new DynamicParameters();
parameters.Add("@UserId", id, DbType.Int32, ParameterDirection.Input);
parameters.Add("@UserName", dbType: DbType.String, direction: ParameterDirection.Output, size: 50);
parameters.Add("@TotalCount", dbType: DbType.Int32, direction: ParameterDirection.ReturnValue);

connection.Execute("sp_GetUserDetails", parameters, commandType: CommandType.StoredProcedure);
string outputName = parameters.Get<string>("@UserName");

这种方式将参数的定义显式化，提供了更强的控制力。无论使用哪种方式，Dapper最终都会将它们转换为ADO.NET的"DbParameter"集合，确保查询是参数化的、安全的。

三、 超越基础查询：IN语句、动态表名等复杂场景的安全处理

使用参数化查询时，一些特殊场景需要特别注意。例如，直接使用参数化来处理"IN"子句（"WHERE Id IN (@ids)"）是行不通的，因为一个参数只能代表一个标量值。Dapper社区提供了巧妙的解决方案，即利用其内置的对列表参数的支持。

var ids = new List<int> { 1, 2, 3, 5 };
var users = connection.Query<User>("SELECT * FROM Users WHERE Id IN @Ids", new { Ids = ids });

注意，这里的SQL中参数是"@Ids"，而传递的是一个名为"Ids"的列表属性。Dapper会自动将其展开为"WHERE Id IN (1, 2, 3, 5)"。关键在于，这个展开过程依然是安全的。Dapper并不是做字符串拼接，而是为列表中的每个元素生成一个独立的参数（例如"@Ids_0", "@Ids_1"...）。这仍然符合参数化查询的原则。

另一个棘手的问题是动态表名或列名。SQL的参数化只能用于值（Value），不能用于标识符（Identifier），如表名、列名。对于这种需求，绝对不能使用用户输入直接拼接。正确的做法是使用白名单验证。例如，如果用户可以选择按不同列排序：

// 危险！绝对不要这样做：
// string sql = $"SELECT * FROM Users ORDER BY {orderByColumn}";
// 安全做法：白名单验证
string[] allowedColumns = { "Username", "CreateTime", "Email" };
if (!allowedColumns.Contains(orderByColumn))
{
    orderByColumn = "Username"; // 提供安全的默认值
}
string safeSql = "SELECT * FROM Users ORDER BY " + orderByColumn;
// 注意：orderByColumn来自白名单，是安全的，但查询本身已不是参数化，因为参数化不适用于此场景。

这种情况下，虽然SQL字符串的一部分是动态的，但因为动态部分来自于一个预定义的、完全可控的白名单，而非直接的用户输入，所以也是安全的。这体现了安全的核心思想：对所有外部输入保持不信任，并进行严格的验证或转义。

四、 对比其他ORM：Dapper在安全与性能上的平衡

与Entity Framework (EF) Core这样的全功能ORM相比，Dapper在防止SQL注入的机制上本质是相同的，都依赖于ADO.NET的参数化查询。区别在于抽象层级。EF Core使用LINQ表达式树，开发者几乎不直接接触SQL，由框架负责生成安全的参数化SQL。这降低了注入风险，但也让开发者对最终执行的SQL失去了一些控制和透明度。

Dapper则要求你手写或部分手写SQL，这看起来似乎“更危险”，但实际上它迫使开发者必须直面SQL和安全问题。只要你坚持使用Dapper的参数化方法（而不是忍不住去拼接字符串），其安全性与EF Core是等同的。同时，Dapper因为几乎没有额外的运行时开销，性能通常更接近原生ADO.NET，这对于高性能要求的应用至关重要。它是一种在“安全”、“性能”和“开发控制力”之间取得极佳平衡的方案。

与更底层的ADO.NET相比，Dapper的安全性并无二致，但极大地简化了代码。原本需要手动创建"DbCommand"、添加"DbParameter"的冗长过程，被一两行简洁的代码所取代，减少了因代码繁琐而无意中引入安全漏洞的可能性。

五、 构建纵深防御：参数化查询并非唯一防线

尽管参数化查询是防止SQL注入的基石，但成熟的防御策略应该是纵深防御。首先，在数据库层面，遵循最小权限原则。应用程序连接数据库的账户只应拥有其必需的最小权限（如只有特定表的SELECT、INSERT权限，没有DROP、ALTER等权限）。这样即使发生注入，损害也能被限制。

其次，对所有输入进行严格的验证和过滤。在数据到达数据访问层之前，在API或控制器层就对输入数据的类型、长度、格式（如邮箱、电话）进行校验。使用正则表达式或模型验证特性（如ASP.NET Core的"[Required]", "[StringLength]"）可以过滤掉大量非法输入。

再次，启用并正确配置数据库的日志和审计功能。监控异常的查询模式，例如短时间内大量失败的登录尝试、超长SQL语句的执行等，可以帮助你及时发现潜在的攻击行为。

最后，定期进行代码安全审计和渗透测试。自动化工具和人工审查可以帮你发现那些遗漏的、潜在的字符串拼接点。同时，保持Dapper、数据库驱动程序和数据库系统本身的及时更新，以修补已知的安全漏洞。

结论

防止SQL注入是一场不能松懈的战斗。使用Dapper等轻量级ORM，通过其简洁而强大的参数化查询支持，你可以用最少的代码获得最高等级的安全防护。核心要义始终是：绝不信任任何外部输入，绝不拼接SQL字符串。将参数化查询作为铁律，并结合最小权限、输入验证、监控审计等纵深防御措施，才能构建起真正坚固的数据安全防线。Dapper在这条路上，为你提供了一个既安全又高效的工具选择。