必须显式传入spliton,否则dapper将所有列映射到第一个类型,第二个类型字段全为默认值;spliton值为第二个实体起始列的列名(如"userid"),区分大小写,别名需匹配。

用 Query<t1 t2 tresult></t1> 做一对一映射时,必须显式传入 splitOn
不设 splitOn 会导致 Dapper 把所有列都塞进第一个类型,第二个类型字段全为默认值(比如 0、null),连异常都不会抛。它只按列名前缀猜分割点,不可靠。
常见错误是以为主键名(如 Id)天然就是分隔点——其实 Dapper 默认只认 Id,但一旦你用了 UserId、ProfileId 这类命名,就必须手动指定:
connection.Query<user profile user>(
"SELECT u.*, p.* FROM Users u LEFT JOIN Profiles p ON u.Id = p.UserId",
(u, p) => { u.Profile = p; return u; },
splitOn: "UserId" // 注意:这里对应 Profile 表的外键列名,不是主键名
);</user>
-
splitOn的值是「第二个实体起始列的列名」,不是类属性名 - 多个映射时(如
Query<a></a>),用逗号分隔:splitOn: "BId,CId" - 如果 SQL 中用了别名(如
p.Id AS ProfileId),splitOn必须写"ProfileId",不是"Id"
一对多不能靠 Query<t1></t1> 直接搞定
Dapper 原生 Query 系列方法只支持扁平结果集映射,无法自动展开子集合。强行用 (u, o) => { u.Orders.Add(o); return u; } 会因引用复用导致所有 User 实例共享同一个 Orders 列表。
正确做法是分两步:先查主表,再用 QueryMultiple 或批量 IN 查询子表,最后在内存中组装。最稳的是 QueryMultiple:
var sql = @"
SELECT * FROM Users WHERE Id IN @ids;
SELECT * FROM Orders WHERE UserId IN @ids;";
using var multi = connection.QueryMultiple(sql, new { ids = userIds });
<p>var users = multi.Read<user>().ToList();
var orders = multi.Read<order>().ToList();</order></user></p><p>// 手动分组挂载
var orderLookup = orders.GroupBy(x => x.UserId).ToDictionary(g => g.Key, g => g.ToList());
foreach (var u in users)
u.Orders = orderLookup.GetValueOrDefault(u.Id, new List<order>());</order></p>
- 别用
Read<user order user></user>模拟一对多——结果是笛卡尔积,数据量大时爆炸 -
QueryMultiple要求 SQL 用分号分隔多个查询,且顺序必须和Read调用顺序一致 - 如果子表数据可能为空,
orderLookup.GetValueOrDefault()比orderLookup[u.Id]安全
自定义映射逻辑必须用匿名对象或显式构造函数
当实体字段和数据库列名不一致,或需要条件赋值(如状态码转枚举),Dapper 不会调用属性 setter 链式处理。它直接通过反射写字段/属性,跳过业务逻辑。
解决方式只有两个:
- 用匿名对象过渡:
connection.Query("SELECT ..., Status AS StatusValue FROM ...").Select(x => new Order { Status = (OrderStatus)x.StatusValue }) - 给实体加匹配的构造函数:
public Order(int id, string name, int statusCode) { Id = id; Name = name; Status = (OrderStatus)statusCode; },然后Query<order></order>自动绑定
别指望 [Column("status_code")] 或 [JsonIgnore] 影响 Dapper 的映射行为——它不读这些特性。
性能关键点:避免 N+1,也别盲目用 Multi-Mapping
看起来 Query<user order user></user> 一行代码很爽,但它本质是单次查询 + 内存分组,适合子项极少(如每个用户最多 3 条订单)的场景。一旦平均子项数超过 10,生成的笛卡尔积会让网络传输和 GC 压力陡增。
真实项目里更常用的是「主表 ID 列表 → 批量查子表 → 字典关联」,因为:
- 子表查询可走索引,比 JOIN 更可控
- 能分页主表后,再查对应子项,避免拉回全部关联数据
- 必要时子表还能单独加缓存(如用
IDistributedCache缓存OrderId列表)
真正容易被忽略的是:Dapper 的 splitOn 是大小写敏感的,SQL Server 默认不区分,但 PostgreSQL 和 SQLite 区分——本地跑通的代码,上线可能全空,务必确认目标数据库的列名大小写规则。











