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