Dapper不自动处理Guid与数据库字段的格式转换，需根据数据库类型适配：字符串存储用ToString(“N”)和char(36)，binary(16)需自定义TypeHandler，postgresql推荐原生uuid类型并配合Npgsql驱动。
Dapper 本身不自动处理 Guid 类型与数据库字段的底层格式转换，具体怎么存、怎么读，取决于你数据库的字段类型（如 char(36)、uuid、binary(16)）以及你传参和映射时的写法。关键不是“Dapper 支持与否”，而是你是否做了适配——要么手动转字符串，要么用自定义 TypeHandler。
Guid 存成字符串（最常用，兼容性最强）
多数情况下，尤其是 PostgreSQL、sqlite 或老版本 SQL Server，数据库没有原生 uuid 类型，或你选择用字符串存储，这时推荐统一用 Guid.ToString(“N”)（32位无横线格式）存入 char(36) 或 varchar(36) 字段。
- 插入时：把 Guid 转成字符串再传参，例如
ID = Guid.NewGuid().ToString("N") - 查询时：从字符串字段读出后，用
new Guid(reader.GetString("ID"))或 Dapper 自动映射（只要属性是Guid类型，且值可解析） - 建表建议：主键字段设为
char(36) NOT NULL PRIMARY KEY，比 varchar 更稳定（定长、索引友好）
Guid 映射到 binary(16)（空间更省，性能略优）
如果数据库支持 binary(16)（如 mysql、SQL Server），且你希望节省存储、提升索引效率，可以把 Guid 存为 16 字节二进制。
- 存入前：用
guid.ToByteArray() - 读出后：用
new Guid(byteArray) - 但 Dapper 默认不识别 binary → Guid 的自动转换，必须注册自定义 ITypeHandler
- 示例处理器需重写
SetValue（写入时转 byte[]）和Parse（读取时转 Guid）
PostgreSQL 的特殊处理（uuid 类型原生支持）
PostgreSQL 有内置 uuid 类型，推荐优先使用它而非字符串。
- 建表：
ID uuid PRIMARY KEY default gen_random_uuid() - 插入时直接传 Guid 对象（Npgsql 驱动会自动处理），无需 ToString
- 查询结果也能自动映射到 C# 的 Guid 属性，前提是使用 Npgsql 连接器 + 正确配置
- 注意：不要用
varchar或text存 uuid，否则失去类型语义和索引优化
避免踩坑的几个细节
Guid 映射看着简单，但容易在边界处出错：
- 实体类属性必须声明为
public Guid ID { get; set; }，不能是 string，否则 Dapper 不会尝试转换 - 参数化查询中，如果传的是 Guid 对象，而数据库字段是字符串，Npgsql/SqlClient 可能报类型不匹配——此时应显式转字符串
- Dapper Extensions 默认把
Id属性为 Guid 的字段识别为主键，并设为 KeyType.Guid，但仅限于自动映射场景；手写 SQL 仍需自己控制格式 - 使用
QueryFirstOrDefault<t>()</t>时，若数据库字段为空或 null，而 C# 属性是非 Nullable Guid，会抛异常——建议用Guid?或提前判空
基本上就这些。核心就一条：数据库怎么存，代码就怎么转；Dapper 是桥梁，不是翻译官——它按你写的规则走，不猜意图。