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 是桥梁，不是翻译官——它按你写的规则走，不猜意图。
