Dapper查询参数传递建议：完整实体VS匿名对象？性能内存影响如何？

1. 传递完整实体是否可行？ #

完全可行！Dapper的参数匹配机制相当灵活——它会自动扫描你传入对象的公共属性，匹配SQL语句中定义的参数（比如@Id对应实体的Id属性），完全不会在意对象里有没有其他多余属性。只要你的实体包含SQL所需的参数属性，这种写法就能正常工作：

Query<SomeObj>("Select * from SomeObjs where Id = @Id", someObj);

这种方式的好处是代码简洁，不用额外构造对象，特别适合你已经持有完整实体实例的场景。

2. 轻量级匿名对象更优吗？性能&内存差异分析 #

从性能和内存的角度，两者的差异其实非常小，大部分业务场景下可以忽略不计，但还是有一些细节值得留意：

• 内存占用：匿名对象只包含你指定的属性（比如new { someObj.Id }），所以单个实例的内存占用确实比完整实体小。但除非你在高频循环（比如十万+次调用）中创建这些对象，否则这点差异完全无法感知。
• 参数解析性能：Dapper会缓存对象的属性元数据（不管是实体还是匿名对象），所以第一次调用后，后续的解析速度几乎一致。唯一的区别是，完整实体的属性更多，但Dapper在匹配参数时只会关注SQL中用到的那些，不会遍历所有属性做无用功——它内部是通过参数名直接查找对应的属性，所以多余属性不会带来额外的性能开销。

3. 该怎么选择？ #

• 如果你已经持有完整实体实例，直接传实体就好，代码更简洁，没必要多此一举构造匿名对象。
• 如果你只需要少数几个属性，或者想明确传递参数（避免后续实体属性变更带来的意外影响，比如实体新增了一个@Name属性，而SQL后来不小心用到了这个参数），那么匿名对象会更安全，也更清晰——别人看代码的时候能一眼知道你传递了哪些参数。

举个例子，如果你的实体后来新增了一个Deleted属性，而某天SQL被改成了Select * from SomeObjs where Id = @Id and Deleted = @Deleted，这时候传完整实体就会自动带上Deleted的值，而如果是匿名对象，你需要显式添加Deleted参数，反而能避免不小心引入的bug。

内容的提问来源于stack exchange，提问作者Mayank