关于cats-effect IO.orElse在pure与delay下行为的技术问询

核心背景：IO.pure vs IO.delay 的求值时机 #

先明确两个核心IO构造器的本质差异：

• IO.pure(a)：严格求值——创建IO实例时立即计算a的值，把结果包装成IO。如果a是抛出异常的表达式，创建瞬间就会触发异常，IO实例都无法生成。
• IO.delay(a)：惰性求值——把a的计算逻辑包装起来，只有当IO被执行（比如调用unsafeRunSync）时才会运行a。创建阶段不会执行任何逻辑，异常只会在执行阶段抛出。

逐个解答你的实验困惑 #

示例1：IO.pure(1).orElse(IO.pure(2)) 为何组合后是惰性IO？ #

IO.pure(1)的即时求值只是在创建IO时计算了值1，但这个IO本身仍是一个未执行的实例。orElse组合后的IO遵循IO的通用语义：只有当你调用执行方法（如unsafeRunSync）时，才会触发逻辑——先执行左边IO（直接返回已计算好的1），右边IO完全不会被执行。

这里的“惰性”指的是整个组合IO的执行是延迟的，和左边IO.pure(1)创建阶段的即时求值是两个完全独立的阶段，互不冲突。

示例2：为何IO.pure(throw new Exception).orElse(IO.pure(2)) 立即抛异常，而仅第二个pure含异常时返回惰性IO？ #

• 第一个场景：IO.pure(throw new Exception)在创建IO的瞬间就会执行括号内的异常抛出代码，直接终止当前流程，orElse根本没机会被调用（连左边的IO实例都没创建出来）。
• 第二个场景（你说的“仅第二个pure含异常”）：如果左边是正常IO（比如IO.pure(1)），右边是IO.pure(throw new Exception)——这个场景下右边的IO在创建时就会抛异常，组合过程会直接失败。你观察到的“惰性IO”大概率是混淆了构造器，比如右边实际用的是IO.delay(throw new Exception)。

关键结论：想用orElse做fallback，左边的IO必须用IO.delay（或IO.apply）包装可能失败的逻辑。只有这样，异常才会在IO执行阶段抛出，orElse才能捕获失败并执行备选IO。

示例3&4：IO.delay(throw new Exception) 与IO.pure(2)/IO.delay(2)组合结果一致，如何选择？ #

执行结果一致是因为：左边IO执行失败后，右边IO的逻辑都会被触发。两者的差异在于语义和性能：

• 用IO.pure(2)：创建时就计算好值2，执行时直接返回，性能更高，适合纯常量或已计算好的无副作用值。
• 用IO.delay(2)：执行时才计算2，适合需要延迟求值的场景（比如值的计算依赖上下文、有副作用）。

选择标准完全取决于值的语义：如果是“已有确定值”，用pure；如果是“需要执行操作才能得到值”，用delay。

可预测IO行为的启发式规则 #

1. IO.pure 的使用边界 #

• 仅用于纯常量、无副作用的已计算值，比如IO.pure(1)、IO.pure("fixed-string")。
• 绝对不要用IO.pure包装会抛异常、有副作用的表达式——否则副作用会在创建阶段触发，异常直接炸在当前线程，完全脱离IO的控制流。

2. IO.delay 的使用场景 #

• 所有需要延迟执行的逻辑：有副作用的操作（读写文件、打印日志）、可能抛异常的代码、依赖上下文状态的计算。
• IO.apply是IO.delay的别名，二者语义完全一致，可互换使用。

3. orElse 的正确用法 #

• 左边的IO必须是IO.delay创建的，确保失败发生在IO执行阶段，而非创建阶段。
• 右边的备选IO遵循上述pure/delay的规则即可。

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