为使用Fire-and-Forget API的实体创建分配独立Redux状态是否为最佳实践？

首先得明确咱们说的场景：在CQRS架构下的Fire-and-Forget命令，就像你举的发推文例子——前端发请求后，服务器不会返回刚创建的推文实体，完全是“发完就不管”的异步模式。这种情况和常规同步CRUD的状态处理逻辑差异很大，那单独给这类创建操作分配Redux状态到底好不好？咱们拆解来看：

为什么这是个值得推荐的实践？ #

• 状态逻辑更清晰，互不干扰
  把创建操作的状态（比如「正在发送」「发送成功」「发送失败」）和已有的实体列表状态彻底分开，组件里判断操作状态会简单很多。比如你发推文时，不用去现有的推文列表里找有没有新增项，直接看createTweetStatus这个独立状态就行，不会因为列表状态的变化影响操作状态的判断。

• 避免状态污染
  因为服务器不返回实体，你没法直接把新创建的内容加到列表里（除非做乐观更新，但那是另一回事）。如果硬把创建状态和列表状态混在一起，很可能会导致列表里出现临时的、不完整的“幽灵”实体，反而增加状态管理的复杂度。独立状态就完全不会有这个问题。

• 便于复用和扩展
  要是以后有更多类似的Fire-and-Forget操作（比如点赞、转发、删除），每个操作都用独立的状态管理，逻辑可以复用，也不会互相影响。比如createTweetStatus、likeTweetStatus各自独立，组件里能分别处理它们的加载状态和错误提示，维护起来更轻松。

需要注意的边界情况 #

• 别过度拆分状态
  如果只是一个极其简单的操作（比如一个按钮的点击反馈），可能没必要单独建一个复杂的状态切片。但只要操作涉及加载状态、错误重试、用户提示这些逻辑，独立状态的优势就很明显了。

• 结合乐观更新时的处理
  如果你在发请求的同时做了乐观更新（比如先把推文加到列表里），这时候可以把乐观更新的临时实体和创建状态结合，但还是建议把「操作状态」和「列表本身」分开——这样就算后续需要回滚乐观更新的内容，也能通过创建状态来判断要不要执行回滚逻辑。

总结 #

总体来说，为这类Fire-and-Forget的创建操作分配独立Redux状态是非常值得推荐的实践，它贴合CQRS架构里命令与查询分离的思想，能让状态逻辑更简洁、低耦合，也更便于后续的维护和扩展。

内容的提问来源于stack exchange，提问作者Mik378