Dapper 默认不支持带参构造函数映射，仅支持无参构造+属性赋值；可通过三种方式间接实现：①无参构造+可写属性（推荐）；②Query泛型委托手动构造；③第三方扩展（如Dapper.FluentMap），但均无法真正自动调用带参构造。
Dapper 默认不支持直接通过带参数的构造函数创建实体对象，它依赖无参构造函数 + 属性赋值（即 setter）完成映射。但你可以通过几种方式“间接实现”构造函数参数化映射，核心思路是：让 Dapper 先创建对象（靠无参构造），再用自定义逻辑填充——或绕过 Dapper 默认行为，自己控制实例化过程。
方法一：使用无参构造函数 + 可写属性（推荐、最简单）
这是 Dapper 原生支持且最稳定的方式。只要你的类有 public 无参构造函数，并且每个要映射的字段都有对应的 public settable 属性（哪怕只读属性加 private set 也行），Dapper 就能自动赋值。
✅ 示例：
public class User
{
public User() { } // 必须存在（可为 private，但 Dapper 3.0+ 要求 public 或 internal）
public User(int id, string name) // 这个构造函数 Dapper 不调用
{
Id = id;
Name = name;
}
public int Id { get; set; }
public string Name { get; set; }
}
查询时直接使用：
var users = connection.Query<user>("SELECT Id, Name FROM Users");</user>
Dapper 会调用 User() 创建实例，再把结果集字段按名称匹配赋给 Id 和 Name 属性。
方法二：用 Query 的 Func 映射委托（手动控制构造）
如果你坚持要用带参构造函数初始化对象，可以跳过 Dapper 的自动映射，改用 Query 的泛型重载，传入一个 Func<idatareader t></idatareader> 委托，自己从 DataReader 中读取字段并调用构造函数。
优点：完全可控；缺点：失去自动列名匹配和类型转换的便利，需手动处理 null、类型转换等。
var users = connection.Query<User>(
"SELECT Id, Name FROM Users",
reader => new User(
id: reader.GetInt32("Id"),
name: reader.IsDBNull("Name") ? null : reader.GetString("Name")
)
);
⚠️ 注意：reader.GetXXX() 方法需确保列名准确、顺序无关，但字段存在性/类型必须匹配，否则抛异常。
方法三：配合 Dapper.FluentMap 或 Dapper.Contrib（第三方扩展）
原生 Dapper 不支持构造函数注入，但社区有扩展库尝试增强：
- Dapper.Contrib：仅支持无参构造 + 属性映射，不支持构造函数参数。
- Dapper.FluentMap：专注字段/属性映射配置，也不支持构造函数绑定。
- 自定义 TypeHandler（不推荐用于此场景）：TypeHandler 是为单个字段类型服务的，无法接管整个对象构造流程。
所以目前没有主流、稳定的第三方方案能让 Dapper “自动调用带参构造函数”。强行封装反而增加复杂度和维护成本。
补充：为什么 Dapper 不支持构造函数参数映射？
根本原因是性能与设计哲学：Dapper 的核心目标是轻量、极速、零反射开销。它用 Expression Tree 编译属性 setter，而构造函数参数映射需要解析构造函数签名、匹配列名、处理可空/默认值、处理参数顺序 —— 这些都会显著增加反射和运行时开销，违背其“micro-ORM”定位。EF Core 等全功能 ORM 才提供这类高级映射能力。
基本上就这些。想用构造函数初始化，选方法二；想省心又保持兼容性，就老老实实写无参构造 + 可写属性。不复杂但容易忽略的是：确保属性名和 SQL 字段名大小写一致（或开启 SqlMapper.AddTypeMap 自定义映射），否则 Dapper 匹配失败会静默跳过赋值。
