Pin 与 Tokio：从一个可取消的异步任务讲起

理解 Pin 最直接的入口，是看一个 Future 在首次 poll 后为什么不能随意移动。Tokio 负责调度任务，但不会替代码证明自引用结构安全。

先区分值和存储位置

Pin 包装的是访问方式，不会自动让类型不可移动。只有当类型依赖稳定地址时，才需要通过 !Unpin 和受控投影维护约束。普通 async fn 通常不必手写这些细节。

取消发生在 await 边界

任务被 drop 就可能取消，锁、临时文件和外部请求应在析构或显式 guard 中收尾。select! 的分支也要考虑某个 Future 被提前丢弃。

• 避免在持锁状态跨越不必要的 await。
• 自引用类型优先使用成熟投影库。
• 测试超时、取消与重复启动。

用状态机检查异步流程

把任务状态写成创建、运行、完成和取消，逐一确认每个转移后的资源归属。这样比只盯 happy path 更容易发现悬挂任务。

Pin 解决的是地址稳定性，Tokio 解决的是调度。把两个问题分开，异步代码的安全边界会清楚很多。