这种问题我当初刚折腾自定义异步执行器的时候也踩过一模一样的坑！核心问题其实出在Waker的所有权绑定和安全克隆的正确姿势上，咱们一步步捋清楚：

首先得明确一个关键：Waker本身的clone()方法是合法的，但Waker的有效性完全依赖它背后绑定的任务实例的存活状态。自定义执行器里，每个任务通常是用Arc<Mutex<YourTaskStruct>>这类结构包裹的，目的就是通过引用计数来维持任务的生命周期，直到所有可能唤醒它的Waker都被销毁。

你原来的写法之所以失效，大概率是这两个原因之一：

• 你创建原始Waker的时候，没有把它和任务的Arc引用正确绑定：比如Waker的RawWaker虚表（定义clone、wake等操作的那套函数）里，clone逻辑没有正确增加任务Arc的引用计数。这就导致你克隆的Waker根本没持有任务的所有权——当执行器第一次poll完任务，把任务从队列里移除后，任务的引用计数降到0直接被drop了，后续Sleep future调用wake()时，Waker指向的是已经被释放的内存，自然没法唤醒任务，执行器一看队列空了就直接退出了。
• 你在执行器里的任务管理逻辑有漏洞：比如第一次poll后，没有保留任务的引用，或者错误地提前drop了任务的Arc实例，导致任务提前死亡，克隆的Waker成了“空壳”。

而你后来改用Arc::clone + into_raw的写法能正常工作，本质是补全了所有权绑定的逻辑：
当你把Arc<Mutex<YourTaskStruct>>克隆一份，再转成原始指针来创建RawWaker，同时在RawWaker的虚表实现里，严格遵循引用计数规则：

• 当克隆Waker时，调用Arc::clone来增加引用计数
• 当Waker被drop时，调用Arc::from_raw来减少引用计数
• 调用wake()时，先把原始指针转成Arc，再把任务重新加入执行器的待处理队列

这样一来，哪怕执行器的主队列里暂时没有这个任务，只要Sleep future里还存着克隆的Waker，任务的Arc引用计数就会保持在1以上，任务不会被销毁。等Sleep到时间调用wake()，就能正确找到任务并重新调度，执行器自然会等到任务完成再退出。

给你个实用的调试小技巧：可以在你的任务结构体里加个Drop实现，比如：

impl Drop for YourTaskStruct {
    fn drop(&mut self) {
        println!("Task dropped!");
    }
}

如果程序提前终止时打印了这句话，那百分百是任务被提前销毁了，就得回头重点检查Waker和任务Arc的绑定逻辑。

内容来源于stack exchange