防重核心靠数据库唯一约束+异常捕获，Dapper仅负责执行与暴露错误；须建唯一索引，捕获对应数据库异常码（如SQL Server 2627），慎用前置查询，推荐MERGE/UPSERT原子操作。
用 Dapper 防止重复插入，核心不是靠 Dapper 本身（它只是轻量 ORM，不提供自动去重或约束拦截），而是靠数据库层面的唯一性约束 + 合理的异常捕获与业务处理。Dapper 的角色是帮你把错误暴露出来，并让你能优雅应对。
数据库建唯一索引是前提
没有数据库级的 UNIQUE 约束或唯一索引，任何代码层的判断都可能因并发而失效。比如对用户名、邮箱、订单号等字段，必须在数据库中显式添加：
- SQL Server：
CREATE UNIQUE INDEX IX_Users_Email ON Users(Email); - PostgreSQL：
CREATE UNIQUE INDEX idx_users_email ON users(email); - MySQL：
ALTER TABLE users ADD UNIQUE(email);
这是防重最可靠、最高效的一道防线。
用 try-catch 捕获唯一性冲突异常
Dapper 执行 Execute() 插入时，一旦违反唯一约束，数据库会抛出特定异常（如 SQL Server 的 SqlException.Number == 2627 或 2601，PostgreSQL 的 SqlException.SqlState == "23505"）。你需要主动捕获并区分处理：
- 检查异常类型和错误码，而不是只看消息文本（消息可能本地化）
- 对唯一冲突返回友好提示（如“该邮箱已被注册”），而非 500 错误
- 避免裸 throw，也不要静默吞掉异常
示例（SQL Server）：
try
{
conn.Execute("INSERT INTO Users (Email, Name) VALUES (@email, @name)", user);
}
catch (SqlException ex) when (ex.Number == 2627 || ex.Number == 2601)
{
throw new InvalidOperationException("邮箱已存在，请更换");
}插入前 SELECT 检查（慎用，仅限低并发或强业务校验场景）
虽然不如唯一索引可靠（存在检查后、插入前的竞态窗口），但在某些需要提前反馈、或需组合条件判断的场景（如“同一手机号+同一渠道当天只能注册一次”），可先查再插：
- 用 Dapper 的
QuerySingleOrDefault或() QueryFirstOrDefault快速判断() - 务必搭配事务（
BeginTransaction）提升一致性，但不能完全消除竞态 - 性能有损耗，高并发下不推荐作为主防重手段
更推荐把它当作“用户体验优化”——提前提示，而不是“数据安全依赖”。
用 MERGE / UPSERT 替代单纯 INSERT（推荐进阶方案）
多数现代数据库支持原子化的“存在则忽略/更新”语句，Dapper 可直接执行：
- SQL Server：用
MERGE INTO ... WHEN NOT MATCHED THEN INSERT - PostgreSQL：用
INSERT ... ON CONFLICT DO NOTHING - SQLite：用
INSERT OR IGNORE
这类语句由数据库保证原子性，既避免异常，又省去 try-catch。Dapper 调用方式不变，只是 SQL 更健壮：
conn.Execute(@"
INSERT INTO users (email, name)
VALUES (@email, @name)
ON CONFLICT (email) DO NOTHING", user);执行后可通过 Execute() 返回影响行数（0 表示被忽略，1 表示插入成功）来判断结果。
基本上就这些。Dapper 不负责防重，但它足够灵活，让你能干净地配合数据库能力实现可靠防重——关键在设计时就想好约束在哪一层生效，别把鸡蛋全放在代码里。
