在Rust+Tokio中，返回oneshot::Receiver作为处理回调是否合理？

这种用tokio::sync::oneshot返回Receiver让调用方延迟获取结果的模式，正是异步任务提交场景的经典做法——允许调用方先处理其他不依赖结果的逻辑，之后再await获取处理状态，完全符合你的需求。Clippy的报错只是通用场景下的建议，你的情况属于合理的例外。

clippy::async_yields_async的目的是防止开发者写出不必要的嵌套异步逻辑：比如一个async函数返回另一个Future，容易让调用方误以为需要两次await。但你的设计是主动让调用方控制await的时机，所以这是lint的误判。

1. 直接禁用该lint（最简便） #

既然你的设计是合理的，直接在submit函数上禁用这个lint，并加注释说明原因，避免后续维护者疑惑：

#[async_trait]
impl Submittable for Something {
    #[allow(clippy::async_yields_async)]
    // 有意返回Receiver，让调用方延迟await结果
    async fn submit(item: ProcessableItem) -> oneshot::Receiver<SubmissionResult> {
        let (sender, receiver) = oneshot::channel();
        let queue = get_processing_queue();
        queue.send((item, sender)).await.expect("Processing task closed!");
        receiver
    }
}

2. 封装Receiver为自定义类型 #

如果不想禁用lint，可以把oneshot::Receiver包装成一个自定义结构体，这样Clippy就不会识别它为可直接await的类型，同时保留await能力：

#[derive(Debug)]
pub struct SubmissionHandle(oneshot::Receiver<SubmissionResult>);

impl std::future::Future for SubmissionHandle {
    type Output = Result<SubmissionResult, oneshot::error::RecvError>;

    fn poll(self: std::pin::Pin<&mut Self>, cx: &mut std::task::Context<'_>) -> std::task::Poll<Self::Output> {
        std::pin::Pin::new(&mut self.get_mut().0).poll(cx)
    }
}

// 修改submit函数返回自定义类型
#[async_trait]
impl Submittable for Something {
    async fn submit(item: ProcessableItem) -> SubmissionHandle {
        let (sender, receiver) = oneshot::channel();
        let queue = get_processing_queue();
        queue.send((item, sender)).await.expect("Processing task closed!");
        SubmissionHandle(receiver)
    }
}

调用方的使用方式和之前完全一样，但Clippy不会再报错。而且自定义类型还能扩展功能，比如加个is_ready()方法检查结果是否已就绪。

3. 拆分API为提交+查询（备选） #

如果不想和lint纠缠，也可以把API拆成两个步骤：

• 提交任务时返回一个唯一ID（比如Uuid）
• 单独写一个get_result(id)方法来查询结果

但这种方式需要额外维护任务ID和结果的映射，复杂度更高，不如前两种方案直接。

你的初始设计是正确且符合oneshot通道的使用场景的。优先推荐直接禁用lint并加注释，这是最简洁的做法；如果需要更优雅的类型封装，自定义SubmissionHandle是不错的选择。

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