Tokio 1.28 版本中 spawn 和 spawn_local 使用场景有什么区别

tokio::spawn 适用于需要跨线程调度的 Send + 'static 任务，而 spawn_local 专用于不需要跨线程的非 Send 任务，必须配合 LocalSet 使用。在 Tokio 1.28 版本中，这一核心机制保持稳定，选择错误会导致编译失败或运行时 Panic。

先说结论：任务内部状态线程安全选 spawn，涉及线程局部存储或非 Send 类型选 spawn_local。

适合：spawn 用于多线程运行时通用任务，spawn_local 用于当前线程绑定的特定任务。
重点看：Future 是否实现 Send trait，运行时是否创建了 LocalSet。
别忽略：spawn_local 任务在 LocalSet drop 时会被强制取消，需处理资源清理。

代码对比

// tokio::spawn 要求 Send
let handle = tokio::spawn(async move {
    // 任务代码
});

// spawn_local 不要求 Send，但需 LocalSet
let local = tokio::task::LocalSet::new();
local.spawn_local(async {
    // 任务代码
});
local.await;

为什么会有这个区别

区别核心在于 Rust 的 Send trait 约束与线程调度模型。tokio::spawn 允许运行时将任务调度到线程池中的任意工作线程，因此任务内部数据必须线程安全（Send）。spawn_local 强制任务始终在同一线程执行，解除了 Send 约束，适合操作 Rc、RefCell 等非线程安全类型或线程局部存储。

怎么选

第一步检查任务内部是否包含非 Send 类型。若包含 Rc、std::cell 系列或线程局部变量，必须使用 spawn_local。第二步确认运行时环境，使用 spawn_local 前必须在外层包裹 LocalSet 运行。第三步评估并发需求，若需要利用多核并行计算，优先使用 spawn 确保任务可被窃取调度。

Tokio 1.28 版本中 spawn 和 spawn_local 使用场景有什么区别

怎么验证

编译期验证最直接，若误用 spawn 包裹非 Send 任务，编译器会报错 the trait Send is not implemented。运行时验证可打印 tokio::runtime::worker_index，spawn 任务索引可能变化，spawn_local 任务索引始终固定。日志中观察任务执行线程 ID 是否一致也能辅助确认。

常见坑

LocalSet 生命周期管理不当会导致任务意外取消。若 LocalSet 被 drop，其内所有 spawn_local 任务会立即停止，即使 Future 未完成。spawn_local 不能在标准多线程运行时顶层直接调用，必须包裹在 LocalSet 中，否则会 Panic。跨线程访问 spawn_local 创建的资源会导致数据竞争，需通过通道传递所有权。

常见问题

spawn_local 能在多线程运行时中使用吗

可以，但必须包裹在 LocalSet 中，且任务只会在创建它的线程上运行。

忘记加 Send 约束会怎样

使用 tokio::spawn 时会直接编译失败，提示 trait Send is not implemented for 类型。

LocalSet 会影响性能吗

公开资料中没有看到可靠的量化数据，但限制了任务窃取能力，可能降低多核利用率。

参考来源

深入 tokio::spawn 与任务派发机制-CSDN 博客
Tokio 并发编程:join! 与 spawn 的正确使用姿势
深入理解 tokio::spawn 与任务派发机制:Rust 异步运行时的核心