企业微信二次开发实战：客户重复提交同一业务请求时，如何避免重复处理

在企业微信二次开发中，经常会遇到客户重复发送同一条业务消息的情况。

比如客户发送“查询订单”，由于接口响应较慢，又连续发送了几次。如果每条消息都触发后台接口，就可能造成重复查询、重复提交，甚至重复执行订单操作。

使用星云API对接企业微信消息时，可以在业务处理层增加去重和幂等机制，避免同一请求被反复执行。

一、先区分重复消息和重复业务

这两种情况需要分开处理：

• 消息重复： 同一条消息因回调重试等原因被多次接收。

• 业务重复： 客户连续发送多条内容相同、业务目标相同的消息。

消息重复可以通过消息唯一ID去重，业务重复则需要结合客户ID、业务类型和业务参数判断。

二、通过Redis记录请求状态

可以为每次业务请求生成唯一标识：

requestKey = 客户ID + 业务类型 + 业务参数

例如：

user123:order_query:20261001

收到请求后，先检查Redis中的执行状态：

• 不存在：创建任务并开始处理。

• 执行中：直接返回“正在处理中”。

• 已完成：根据业务规则返回缓存结果或允许重新查询。

创建任务时建议使用Redis的SET NX EX原子操作，避免并发请求同时通过检查。

三、业务处理流程

接收企业微信消息
       ↓
解析客户ID和业务参数
       ↓
生成业务请求唯一标识
       ↓
检查请求是否已存在
       ↓
  ┌────┴────┐
  │         │
 已存在    不存在
  │         │
返回状态   创建任务
            │
         执行业务接口
            │
         保存执行结果
            │
         回复客户

对于订单创建、支付等操作，仅靠Redis去重还不够，最好同时在业务数据库中设置幂等约束，避免重复写入。

四、实际开发需要注意什么

1. 设置合理的去重时间

不同业务的去重周期应该有所区别。普通查询可以设置较短时间，订单提交等操作则需要更严格的幂等控制。

2. 不要直接丢弃重复请求

如果任务仍在执行，可以回复客户“当前请求正在处理中”，避免客户因为没有反馈继续发送消息。

3. 失败任务允许重新处理

业务执行失败后，需要根据失败原因决定是否重试，不能简单地把所有失败请求永久拦截。

五、总结

企业微信二次开发中的重复请求问题，核心不是限制客户发消息，而是确保同一业务操作不会被重复执行。

通过消息去重、业务幂等、任务状态管理和结果缓存，可以减少重复接口调用，提高系统稳定性。

实际开发中，可以通过星云API接收和发送企业微信消息，再结合Redis与业务数据库实现完整的请求处理流程。

相关接口可参考：顶部官网卡片链接。