Rust 通道 channel 发送端关闭后接收端 recv 会返回什么值？

当 Rust 标准库通道的所有发送端（Sender）被丢弃后，接收端调用 recv 方法会返回 Err(RecvError)。

该行为适用于 std::sync::mpsc 同步通道场景，接收端需处理错误分支以避免程序恐慌。

先说结论：发送端全部 drop 后，recv 返回 Err 而非阻塞或空值。

适合：std::sync::mpsc 多生产者单消费者模型
先看：Receiver::recv 返回值类型为 Result
建议：使用 match 或 if let 显式处理断开错误

代码速用版

use std::sync::mpsc;

let (tx, rx) = mpsc::channel();
drop(tx); // 显式关闭发送端
match rx.recv() {
    Ok(val) => println!("收到：{}", val),
    Err(_) => println!("通道已关闭"),
}

为什么会这样

Rust 通道基于所有权机制，当最后一个发送端被丢弃时通道视为关闭。

接收端 recv 方法设计为阻塞等待，但通道关闭意味着不会再有新数据，因此返回错误信号通知接收端停止等待。

分步处理

1. 引入标准库通道模块 std::sync::mpsc。

2. 创建通道并保留接收端 rx。

3. 在发送端作用域结束时确保 tx 被 drop。

4. 接收端循环中匹配 recv 返回结果。

怎么验证是否生效

运行包含上述逻辑的 Rust 程序，观察控制台是否输出“通道已关闭”。

检查程序是否正常退出而非卡在 recv 阻塞状态。

常见坑

1. 克隆发送端：若存在 tx.clone()，需所有克隆体均丢弃才会触发关闭。

2. 阻塞主线程：recv 是阻塞调用，需在独立线程或使用 try_recv 避免卡死。

常见问题

try_recv 在通道关闭后返回什么？

try_recv 会立即返回 Err(RecvError)，不会阻塞等待。

async 通道行为是否一致？

tokio 等异步库的通道关闭后 poll 返回 Ready(Err)，逻辑类似但接口不同。

参考来源

Rust Official Documentation, std::sync::mpsc::Receiver::recv, https://doc.rust-lang.org/std/sync/mpsc/struct.Receiver.html#method.recv