Dapper 执行动态拼接 SQL 的核心原则是:**避免字符串拼接参数,但允许拼接表名、列名、WHERE 条件结构等非用户输入的“元信息”;所有用户数据必须通过参数化传入(@param 形式)**。直接拼接用户输入极易引发 SQL 注入,Dapper 本身不负责校验拼接逻辑,安全责任在开发者。
动态表名/列名:用白名单或严格校验后拼接
表名、排序字段、分组字段等无法参数化,必须拼接到 SQL 字符串中。关键是要确保它们来自可信源:
硬编码白名单(推荐):string tableName = allowedTables.TryGetValue(request.TableKey, out var t) ? t : "orders"; 正则校验(次选):Regex.IsMatch(input, @"^[a-zA-Z_][a-zA-Z0-9_]{0,63}$")(仅字母、数字、下划线,不以数字开头,长度合理) 禁止使用用户原始输入(如 request.SortBy = "name; DROP TABLE users")动态 WHERE 条件:用条件列表 + 参数字典构建
不要写 "WHERE 1=1" + (name != null ? " AND name = '" + name + "'" : "") —— 这是高危写法。
正确做法是分离 SQL 结构和参数:
维护一个 ListIN 查询:用 Dapper 内置支持,别手动拼接
传入 List
Dapper 原生支持数组/List 参数:
sql = "SELECT * FROM users WHERE id IN @ids"; conn.Query(sql, new { ids = new[] { 1, 2, 3 } }); —— Dapper 自动展开为 @ids0, @ids1, @ids2 空集合会自动转为 IN ()(SQL Server 报错),建议提前判断:if (!ids.Any()) return new List复杂动态查询:考虑 QueryBuilder 或表达式树(进阶)
当动态逻辑非常复杂(多级嵌套、OR 分组、动态 JOIN),纯字符串拼接易出错且难维护。可引入轻量方案:
自建简单 QueryBuilder 类,链式调用生成 SQL 片段与参数 用开源库如 SqlKata(兼容 Dapper),它专注动态 SQL 构建,输出纯净 SQL + 参数对象,再交给 Dapper 执行 避免过早抽象——80% 场景用前三个技巧已足够清晰安全基本上就这些。动态 SQL 不复杂,但容易忽略边界(空条件、特殊字符、空集合)。守住“结构可拼、数据必参”这条线,Dapper 的 Raw SQL 就既灵活又可靠。
