问题的回答
当一个 async future 在 await 点挂起时被丢弃（例如当一个兄弟分支在 tokio::select! 中完成时），其 Drop 实现会同步运行以销毁持有的资源。隐患出现在 future 拥有需要异步清理的资源时，例如刷新 TcpStream、发送协议关闭帧或提交数据库事务，因为 Drop 特性不提供 async 上下文。如果 future 在部分修改状态后被取消（例如，写入文件缓冲区的一半）但在最终化之前，同步的 Drop 不能 .await 清理操作的完成，可能会导致系统处于不一致状态或泄漏资源。架构解决方案涉及 drop-guard 模式：将资源包装在一个保护结构中，该结构的 Drop 实现要么调度一个同步的后备清理（接受阻塞风险），要么将资源转变为一个分离的清理任务，确保关键不变式（例如，临时文件删除）最终得到执行，而不依赖于析构函数中的 async 代码。
生活中的情况
我们开发了一个高吞吐量的媒体摄取服务，其中 tokio::spawn 处理并发文件上传。每个上传任务将块写入磁盘上的临时文件，通过外部进程执行病毒扫描，最后将验证过的文件原子性地移动到永久存储桶。要求非常严格：如果客户端断开连接（通过 select! 触发任务取消，发生在病毒扫描和原子移动之间），临时文件必须立即删除，以防止磁盘空间耗尽。
解决方案 1：Drop 中的同步清理。 我们实现了一个 TempFileGuard 结构，包装了 std::fs::File 和路径字符串。在其 Drop 实现中，我们同步调用 std::fs::remove_file 删除临时文件。优点： 代码简单，确保在堆栈展开或取消期间执行。缺点： std::fs::remove_file 是一个阻塞的系统调用。在 Tokio 运行时的工作线程上运行时，在高磁盘负载下这会阻塞线程几毫秒，导致其他任务饥饿，违反了 async 非阻塞合约。此外，如果临时文件位于网络文件系统（NFS）上，阻塞可能会延长到几秒钟，造成灾难性的延迟泡沫。
解决方案 2：生成清理任务。 在保护者的 Drop 中，我们捕获路径字符串并生成一个分离的 tokio::task 以异步运行 tokio::fs::remove_file。优点： 这样立即将控制权返回给运行时，保留了延迟。缺点： 如果运行时已经关闭或在极端负载下，清理任务可能永远不会执行，导致资源泄漏。此外，这种模式要求保护者持有对运行时的 Clone 句柄，复杂化了结构的生命周期，并引入了在运行时在保护者之前被丢弃时可能出现的使用后释放问题。
解决方案 3：带有同步后备的显式取消令牌。 我们利用 tokio_util::sync::CancellationToken 并结构化上传逻辑，以在原子移动之前检查取消。如果被取消，只有在文件小于特定大小阈值（快速删除）时才尝试同步删除，否则将其排队到一个专用后台清理线程（通过 std::thread 生成），使用通道。保护者的 Drop 只处理罕见的恐慌边缘情况，使用同步删除作为最后的手段。选择的解决方案： 我们选择了选项 3。它平衡了确定性（小文件的同步路径）与可扩展性（缓慢操作的后台线程），同时避免阻塞 Tokio 工作者。在对 10,000 个并发取消的负载测试中，结果是零泄漏的临时文件，p99 延迟保持稳定，因为后台线程吸收了 NFS 延迟惩罚。
候选人常常遗漏的内容
为什么在 Drop 实现内部调用 block_on 以执行异步清理在大多数异步运行时中从根本上是不安全的？
尝试在 Drop 中调用 block_on 会产生重入隐患。Drop 在堆栈展开期间或当 future 被取消时同步调用。如果当前线程是 Tokio（或 async-std）运行时的工作线程，block_on 将试图驱动反应器完成新的 future。然而，运行时已经在等待当前任务（正在被丢弃的那个）释放线程。这会导致死锁：block_on 等待反应器对清理 future 进行轮询，但反应器无法进展，因为线程被阻塞在 block_on 内。此外，像 Tokio 这样的运行时在检测到嵌套的 block_on 调用时会显式地恐慌以防止这种情况。正确的方法是在析构函数中进行同步清理（如果是瞬时的），或者通过通道将任务转移到专用线程，而不是阻塞异步执行者。
Future::poll 方法的设计如何固有限制只在 await 点发生取消？这对于关键部分设计有什么重要意义？
Future::poll 方法是同步的，必须及时返回 Poll::Ready 或 Poll::Pending；它不能在执行中让步。一个 await 点是编译器生成的状态机在 poll 返回 Pending 时在状态之间转换的语法糖。执行器（或 select! 宏）只能在 future 不在主动执行时丢弃它——特别是当它返回 Pending 并让出控制时。因此，取消在 poll 调用方面是原子的。这一点很重要，因为它保证从异步运行时的角度来看，两个 await 点之间的任何代码（“关键部分”）要么完全执行，要么根本不执行。然而，如果 future 在 await 之间持有一个 MutexGuard（标准的 Mutex 被 Rust 禁止，但 tokio::sync::Mutex 允许），则取消可能会导致共享数据处于不一致状态。候选人常常忽视，他们必须确保数据结构不变量在每个 await 点之前恢复，而不仅仅是在函数结尾，因为取消会在恰好在该挂起点上对所有活动变量调用 Drop。
在 std::pin::Pin 的上下文中，为什么在 select! 中使用的 futures 必须是 Unpin 或显式固定的，以及这如何防止在部分丢弃中出现内存不安全？
select! 随机轮询多个 futures。如果一个 future 是 !Unpin（例如，它包含自引用指针或入侵式列表链接），在第一次 poll 之后移动它将使这些指针失效。 Pin 确保 future 的内存位置保持稳定。 select! 要求 futures 是 Unpin（允许移动）或已经固定在特定内存位置（栈或堆）。当一个分支完成时，select! 丢弃其他 futures。如果 future 是 Unpin，它会被移动到丢弃胶水中。如果它被 Pin，则会就地丢弃。内存安全保证源于 Pin 确保在 original 内存地址上调用 drop，防止由于自引用 future 在被轮询后被移动（即使是为了销毁）而出现的使用后释放或悬空指针问题。候选人经常忽视 Pin 不仅影响轮询，也影响已取消 futures 的销毁语义。