根据一些阅读材料和我的经验......

使用 Thunk 而不是 Saga 来完成简单而琐碎的任务，例如：

• AJAX 调用
• 数据轮询，并且仅当它们由用户交互直接启动时。

使用 Saga

• 任务交织，文档的登录例子很完美
• 具有很多步骤并等待其他条件发生的流程（“有限状态机”流程）
• 在后台工作并独立于用户交互（或后台/交互的混合）进行的任务

喜欢传奇而不是 thunk 或相反的谎言取决于手头的任务。两者都有其公平的权衡份额。

Thunks 调度一个函数，该函数又调度一个动作。所以，

• 优点：维护简单的代码
• 缺点：必须在测试用例中模拟 thunk 的异步行为，这可能会变得非常笨拙
• 暗示：适用于应用程序的小而直接的异步部分

Sagas 在下面使用生成器函数，因此该函数实际上会在异步操作处暂停并在解决时恢复

• 优点：测试用例变得公平和直接，无需模拟异步行为
• 缺点：增加了代码的复杂性
• 暗示：适用于需要复杂单元测试用例的应用程序的复杂异步部分

两个 thunk 都是 saga 用作 redux 的中间件，通常用于 api 命中。与 saga 相比，thunk 非常容易使用，但是 saga 比 thunk 有很多好处，例如 saga 有效果takeLatest，如果用户反复按下按钮就会有效，thunk 会在每次点击时使 api 命中，但只使用最新的 saga 效果（一个) api 命中。它还有其他效果和好处，但它有学习开销