理解Raku中supply块与按需供应（on-demand supplies）的作用

很多开发者在接触supply块的初期，会觉得它只是map/merge等流组合子的语法糖，这是因为官方基础示例通常不会用到它的独有特性。实际上supply块的核心能力远不止简单的流转换与合并，核心价值可分为四类：

1. 按需初始化与自动资源清理 #

supply 块的代码只会在每次有新的订阅（tap）时才会执行，订阅结束（流完成、报错、主动关闭）时，块内申请的资源会自动释放。

举个实际场景：你需要实现一个读取本地日志文件的流，要求每个订阅者都从日志文件开头读取历史内容，之后持续推送新增的日志行。用supply块实现非常简单：

my $log-supply = supply {
    # 每次新订阅才打开文件，每个订阅者持有独立的文件句柄
    my $fh = open "app.log", :r;
    # 先发送所有历史行
    .emit for $fh.lines;
    # 监听文件更新，推送新行
    whenever Supply.interval(1) {
        .emit for $fh.lines;
    }
    # 订阅结束时自动关闭文件句柄，不需要手动管理
    CLOSE { $fh.close }
}

如果用Supplier实现，你需要手动管理文件句柄的创建、销毁，还要处理多订阅场景下要不要共享句柄的逻辑，代码复杂度会高很多。

2. 订阅者状态隔离 #

每个订阅触发的supply块执行上下文是完全独立的，块内声明的变量只会属于当前订阅者，多个订阅之间互不干扰。这正好对应官方提到的「Netflix点播」语义：

my $count-supply = supply {
    my $count = 0; # 每个订阅者有独立的计数器
    whenever Supply.interval(1) {
        emit $count++;
    }
}
# 订阅A和订阅B拿到的计数完全独立，各从0开始累加
$count-supply.tap(-> $v { say "订阅A: $v" });
sleep 2;
$count-supply.tap(-> $v { say "订阅B: $v" });

这种每个订阅需要独立状态的场景，用Supplier实现需要自行维护每个订阅的状态上下文，非常容易出错。

3. 复杂流逻辑的高表达力 #

对于带分支、状态判断、超时等复杂控制逻辑的流，用supply+whenever的写法可读性远高于嵌套组合子。

比如要实现一个流：收到用户登录事件后，开始监听该用户的消息事件，5秒内没有收到消息就推送超时通知：

my $user-event-supply = supply {
    whenever $login-flow {
        my $timeout = Promise.in(5);
        whenever $message-flow.grep(*.user-id == $_.id) {
            $timeout.break;
            emit "收到用户消息: $_";
        }
        whenever $timeout {
            emit "用户{$_.id}登录后5秒无消息"
        }
    }
}

同样的逻辑用map/merge/grep等组合子实现会非常绕，可读性差很多。

4. 自动生命周期与错误管理 #

supply块会自动处理所有源流的错误和完成事件：块内任何逻辑抛出的错误都会自动传递给订阅的错误处理器，不需要手动捕获转发；所有监听的源流都发送完成事件后，会自动向下游发送完成事件，不需要手动管理done调用。

而直接用Supplier的话，你需要手动try/catch所有可能的异常，手动调用.fail转发错误，手动跟踪所有上游的完成状态来决定什么时候发送done，很容易出现遗漏导致流泄露或者错误丢失。

适用场景总结 #

• 每个订阅者需要独立资源（如独立的网络连接、文件句柄）或者独立状态的场景
• 流逻辑包含分支、状态判断、超时等复杂控制流的场景
• 不想手动管理资源生命周期、错误传播、完成事件的场景

简单示例只是为了演示基础用法，没有用到这些特性，才会让人产生它只是组合子语法糖的误解。实际生产中复杂流逻辑的场景下，supply块能大幅降低代码复杂度，减少资源泄露、错误丢失之类的问题，所以才会有「优先用supply块而非直接用Supplier」的说法。

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