Dapper怎么防止重复插入数据 Dapper唯一性约束处理

防重核心靠数据库唯一约束+异常捕获，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 不负责防重，但它足够灵活，让你能干净地配合数据库能力实现可靠防重——关键在设计时就想好约束在哪一层生效，别把鸡蛋全放在代码里。