NgRx中监听按特定顺序派发的动作链是否属于反模式？

你这个写法靠全局Action流+pairwise()匹配动作顺序，确实能少写很多样板代码，但存在几个隐蔽且高发的逻辑缺陷，尤其在你提到的「两个动作间可能插入其他派发动作」的场景下很容易出问题：

• 无上下文关联导致的跨流程误触发
  这个实现完全没有绑定Action之间的因果关系，只要全局流中先出现过actionX、后出现actionZ，不管这个actionZ是不是之前那个actionX触发的，都会命中规则派发actionA。最典型的异常场景：某模块触发actionX后接口请求卡顿，用户跳转到其他页面，其他页面的独立逻辑刚好派发了actionZ，这时候effect会无厘头触发actionA，这类跨模块的串流bug极难复现排查。
• 匹配逻辑天然存在漏触发、重复触发问题
  pairwise()只会对筛选后流中相邻的两个动作做配对，面对多并发的Action场景完全无法正确匹配：
  • 如果派发顺序为actionX1 -> actionX2 -> actionZ2（第一个X触发后还没等Z返回，又触发了第二个X，第二个X先返回了Z），配对结果只有[actionX1, actionX2]、[actionX2, actionZ2]，第一个X对应的流程如果后续返回actionZ1，流里的配对会变成[actionZ2, actionZ1]，根本匹配不到actionX1，直接漏触发逻辑。
  • 如果派发顺序为actionX -> actionZ -> actionZ（X触发后因为API重试等逻辑发了两次Z），配对结果会出现[actionX, actionZ]、[actionZ, actionZ]，第一次匹配就会触发actionA，第二次Z不会触发，看起来正常，但如果两个Z携带的返回数据不同，你根本拿不到正确的参数。
• 缓存残留导致的延迟意外触发
  pairwise()会永久缓存上一个命中筛选规则的Action，哪怕这个Action是用户打开页面很久之前派发的。比如用户进入页面后误触发了一次actionX，后续流程走到一半退出了相关页面，过了十几分钟用户在其他模块操作触发了一次actionZ，会直接和十几分钟前缓存的actionX配对触发actionA，完全不符合业务预期。
• 无法绑定流程上下文参数
  实际业务中actionX、actionZ几乎都会携带业务参数（比如请求ID、资源ID、表单快照），这种全局配对的写法没法保证你拿到的前序actionX的参数，和当前触发的actionZ是同一个流程的，复杂业务下根本没法维护。

如果要实现「指定Action按顺序触发后执行逻辑」的需求，不要在全局Action流上做配对，应该把监听逻辑收敛到触发起始Action的流内部，从根源上避免跨流程串流问题，参考实现：

effectXZ$ = createEffect(() =>
  this.actions$.pipe(
    ofType(actionX),
    // 每次触发actionX时，才开启对当前流程下actionZ的监听
    switchMap((xPayload) => 
      this.actions$.pipe(
        ofType(actionZ),
        // 建议给每个流程加唯一flowId做关联，彻底避免误匹配
        // filter(zPayload => zPayload.flowId === xPayload.flowId),
        take(1),
        // 如果再次触发actionX，自动取消上一次未完成的监听
        takeUntil(this.actions$.pipe(ofType(actionX))),
        map(() => actionA(xPayload))
      )
    )
  )
);

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