Tokio watch通道接收异常：sender含await时仅能读取一次？

核心原因：Watch通道特性与协作式调度的交互 #

Tokio的watch通道是为传递最新值设计的单生产者多消费者通道，核心规则明确：Sender::send()仅当新值与当前存储值不相等（按PartialEq判断）时，才会触发接收器的通知。若值相同，send()会返回成功但不会唤醒等待的接收器。你的异常场景是这个规则结合Tokio协作式调度特性共同导致的：

• 无await的sender循环：
  没有await时，sender进入忙循环，Tokio的协作式调度器无法主动抢占该任务（任务未主动让出CPU）。此时sender快速重复调用send()，但receiver根本没机会执行。当sender最终被调度器强制让出时，receiver的recv().await会直接获取最新值——你误以为收到了所有消息，实际watch只触发了一次通知（若值未变），只是调度延迟让你看到重复结果。

• 有await的sender循环：
  加入await后，sender每次循环都会主动让出CPU，receiver能立即处理通知。如果sender每次发送的是同一个值，第一次send()会触发通知，后续send()因值未变化，watch不会触发新通知，receiver的recv().await会一直阻塞，表现为仅收到一次消息。

至于你提到的“添加await引入异常延迟”，这是因为await会触发任务调度切换，带来额外的调度开销，而忙循环则持续占用CPU，无调度延迟。

临时方案合理性：0毫秒sleep不可取 #

sleep(Duration::from_millis(0)).await完全不是合理方案：

• 它无法解决根本问题：只要发送的值相同，watch依然不会触发新通知，receiver还是收不到后续消息。
• 频繁的调度切换会加剧性能开销，反而让延迟问题更严重。

正确解决思路 #

1. 保证每次发送的是不同值：
   如果需要通知receiver每次发送动作（哪怕内容相同），可以给消息添加版本号或时间戳，确保每次send()的新值与旧值不相等：

   #[derive(Debug, PartialEq)]
   struct Msg {
       content: &'static str,
       version: u64,
   }
   
   // Sender循环示例
   let mut version = 0;
   loop {
       version += 1;
       tx.send(Msg {
           content: "test",
           version,
       }).unwrap();
       println!("SENT");
       tokio::time::sleep(Duration::from_millis(100)).await;
   }
   

2. 换用合适的通道类型：
   如果你的需求是传递所有消息（而非仅保留最新值），watch通道不适用，应该改用tokio::sync::mpsc——它专门用于传递一系列消息，不会丢弃历史发送内容。

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