企业微信二次开发：业务处理中客户继续发消息时，如何避免新旧任务互相干扰

在企业微信二次开发中，经常会遇到客户上一条业务还没处理完成，又继续发送新消息的情况。

比如客户先查询订单，后台正在调用接口，随后客户又发送售后申请。如果系统只根据客户ID保存当前任务，就可能出现请求参数覆盖、任务状态混乱，甚至把旧任务的结果回复到新任务中。

使用星云API对接企业微信消息时，可以通过任务隔离和上下文管理，避免新旧请求相互影响。

相关接口参考顶部星云官网卡片里的接口文档 。

一、不要只用客户ID管理任务

同一个客户可以同时发起多个业务请求，因此客户ID只能用于识别消息来源，不能作为任务的唯一标识。

建议每次业务请求都生成独立的taskId。

例如：

{
  "taskId": "TASK1001",
  "customerId": "USER001",
  "businessType": "order_query",
  "status": "RUNNING"
}

客户再次发送售后申请时，创建新的TASK1002，而不是直接覆盖TASK1001。

二、为每个任务保存独立上下文

不同任务需要分别保存业务参数、执行进度和接口返回结果。

例如：

任务ID	业务类型	当前状态
TASK1001	订单查询	RUNNING
TASK1002	售后申请	PENDING
TASK1003	物流查询	SUCCESS

即使三个任务来自同一个客户，也应该独立记录。

如果新消息属于上一任务的补充信息，可以通过任务ID进行关联，而不是直接修改客户当前所有任务的数据。

三、新旧任务如何分开处理

客户发送订单查询
        ↓
创建TASK1001
        ↓
后台执行订单查询
        ↓
客户继续发送售后申请
        ↓
识别新的业务类型
        ↓
创建TASK1002
        ↓
判断两个任务是否存在依赖
     ┌──────┴──────┐
     ↓             ↓
  没有依赖       存在依赖
     ↓             ↓
  并行处理       顺序执行
     ↓             ↓
     └──────┬──────┘
            ↓
     分别保存执行结果
            ↓
     回复对应任务结果

对于相互独立的查询任务，可以并发执行；如果两个任务需要修改同一订单，则应根据业务规则控制执行顺序。

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

1. 区分新请求和补充消息

客户发送“查询订单”后，又发送订单编号，这可能属于同一个任务，而不是新任务。

可以通过会话状态、当前等待的参数和任务ID判断消息归属。

2. 防止旧任务覆盖新状态

数据库更新时，应使用taskId定位具体任务，不能只根据customerId更新当前业务状态。

3. 避免重复创建任务

同一业务被重复提交时，需要通过业务幂等键识别，避免每收到一条消息就创建重复任务。

4. 处理任务执行顺序

对于涉及相同订单、客户资料等共享资源的操作，可以使用任务队列按业务资源进行串行处理。

5. 保证回复准确

任务创建时保存原始群ID、客户ID和消息ID。任务完成后根据taskId找到对应会话，并在回复中附上任务编号，避免客户混淆不同结果。

五、总结

企业微信二次开发中，客户连续发送消息并不可怕，真正需要解决的是不同业务请求之间的状态隔离。

通过独立任务ID、上下文管理、消息归属判断和并发控制，可以避免新旧任务参数混用、状态覆盖和结果串线。