在 Koa 框架中，你会采用哪些具体方案来保证接口请求的幂等性？请说明不同方案的设计思路和适用场景。
考察说明
考查对 Koa 中间件机制与 Web 应用状态管理的理解，以及在实际场景中设计幂等性方案的工程能力。
回答思路
- 【回答框架 1】幂等性指同一操作执行多次与执行一次效果相同，重点是防止重复请求导致重复下单、重复扣款或数据重复插入。常见方案包括数据库唯一约束、分布式锁、以及基于请求唯一标识的幂等表。
- 【回答框架 2】在 Koa 中，通常编写一个幂等中间件：先从请求头或请求体中获取幂等键，然后在缓存或数据库中检查该键是否已处理过，若未处理则继续执行后续逻辑并记录处理结果，若已处理则直接返回上次的结果，避免重复处理。
- 【回答框架 3】对于高并发场景，可采用数据库唯一约束结合状态更新原子操作，或者使用 Redis 的 SETNX 实现分布式锁，确保同一时间只有一个请求在处理。此外，还需考虑处理结果保存的粒度，例如按用户 ID 和业务操作类型组合作为幂等键。
- 【回答框架 4】如果业务允许最终一致，可以定期清理过期幂等记录，避免存储无限增长。同时要注意中间件处理的异常情况，如处理过程中失败需释放锁或标记失败状态，以便后续重试。
- 【关键点 1】幂等性需要唯一标识请求，常见方案是使用幂等键配合存储记录。
- 【关键点 2】在 Koa 中通过中间件拦截请求，实现流程控制。
- 【关键点 3】数据库唯一约束和 Redis 分布式锁是两种有效实现手段。
- 【关键点 4】需处理清理策略与异常恢复，防止锁残留或记录堆积。
- 【易错点 1】将幂等性等同于简单的防重复提交，忽略了并发下的状态一致性。
- 【易错点 2】依赖分布式锁时不设置过期时间或处理不当，可能造成死锁风险。
- 【易错点 3】幂等键设计不粒度过大或过小，导致错误拦截或漏拦截。