直接加数据库唯一约束往往不够，因前端连点、网络重试等场景下请求可能未达数据库或事务中断；需结合Redis指纹拦截+DB层状态机与乐观锁兜底，并用事务状态表防范悬挂问题。
为什么直接加数据库唯一约束往往不够
很多开发者第一反应是给业务表加 UNIQUE 索引（比如订单号、流水号），但实际线上常遇到：前端连点两次、网络超时重试、消息队列重复投递——这些场景下，请求可能根本没走到写库逻辑就失败了，或者在事务提交前被中断，导致唯一约束没生效。更麻烦的是，有些操作本身不改库（如查询类接口带缓存刷新），但幂等校验必须覆盖全流程。
用 Redis + 请求指纹做前置拦截最实用
核心思路是把「一次请求的唯一标识」（即指纹）在入口处存入 Redis，并设短过期时间（比如 60 秒）。后续相同指纹的请求直接返回上一次结果或拒绝。指纹推荐组合：UserId + InterfaceName + BusinessId（如订单ID）+ Timestamp（截断到秒，避免每毫秒都不同）。
实操建议：
- 用
IDistributedCache（.NET Core 内置）而非直接操作 StackExchange.Redis，避免手动处理序列化和连接生命周期 - 指纹值建议用 SHA256 哈希后转 Base64，避免 Redis Key 过长或含非法字符
- 拦截逻辑放在 ActionFilter 或中间件里，但注意不要包裹整个
Controller，否则影响 GET 查询类接口的缓存穿透处理 - 若业务允许“静默丢弃”，返回
409 Conflict并附带X-Request-Id头，方便前端对焦重试日志
数据库层必须配合“状态机 + 乐观锁”兜底
Redis 只能防并发，不能防服务重启、Redis 故障或跨集群不一致。真正关键的写操作（如扣库存、发券）必须在 DB 层做最终校验。
示例场景：用户下单接口
UPDATE Orders SET Status = 'Paid', UpdatedAt = GETUTCDATE() WHERE Id = @OrderId AND Status = 'Created' AND Version = @ExpectedVersion;
关键点：
- WHERE 条件中必须显式检查当前状态（如只允许从
'Created'变为'Paid'），不能只靠主键更新 - 用
Version字段或UpdatedAt时间戳实现乐观锁，避免 ABA 问题 - SQL 执行后检查
RowsAffected，为 0 则说明已被处理，抛出特定异常（如IdempotentProcessingException），由上层统一转成409或幂等成功响应
别忽略分布式事务中的“悬挂事务”风险
当接口涉及多个服务（如订单服务调库存服务再调支付服务），即使每个环节都幂等，仍可能出现“前两步成功、第三步超时、上游重试导致第三步执行两次”的悬挂问题。
这时要引入“事务状态表”+“异步补偿”：
- 在本地事务中先插入一条
TransactionRecord，包含全局TransactionId、各子步骤状态、回调地址 - 所有下游调用都带上该
TransactionId，对方需在幂等校验时查这张表 - 启动后台任务扫描超时未完成的记录，按状态发起补偿或告警
这个表本身也得有唯一索引（TransactionId），且插入必须和主业务在同一事务内，否则失去原子性。
真正的难点不在代码怎么写，而在如何定义“同一请求”——业务语义模糊时（比如用户修改收货地址，两次内容相同算不算重复？），技术方案只能兜底，决策权必须交给产品侧明确规则。
