什么时候不该用 Effect Stream？

为十条数据引入 Stream 是过度设计：多一层抽象，多一套 API，换来的背压和惰性拉取在这里一点用都没有。

数据量小且有限、只是一次请求一次响应、需要共享或广播、需要按元素精确协调状态，这四种情形都不该用 Stream；先用数组加 Effect.forEach，或者 Ref、Queue、PubSub 这类原语。

原因是 Stream 解决的是「多个值、不知道有多少、处理可能跟不上产生」的问题，它的价值在拉取式运行带来的有界内存（见Effect 的 Stream 是什么，背压为什么能让内存有界）。不在这个问题域里，成本就白付了。

数据量小而且有限，该怎么办？

几十条记录，直接用数组加 Effect.forEach 即可，需要并发就加 concurrency（见并发）。

只是一次请求、一次响应呢？

一个值就是一个 Effect，不需要 Stream。

多个消费者要看到同一份事件，能用 Stream 吗？

不适合。共享或广播是 PubSub 的问题，不是 Stream 的问题（见共享状态）。Stream 每次运行都是独立的一次执行，不是一份被共享的「热」数据。

需要按元素精确协调状态呢？

这更像状态管理，用 Ref、Queue 等原语更直接。

那什么时候才该用？

一个简单的判断：如果代码里出现了「循环里不断取下一批」「不知道会有多少条」「处理速度可能跟不上产生速度」，考虑 Stream；否则先用数组。

本文整理自本站 Effect 教程中关于 Stream 的章节，没有在本地重新运行；判断标准是该章节的经验总结，不是实验结论，具体 effect 版本号原章节未标明，使用前请对照你所用的版本。