先看依赖墙，再选运行时

遇到Rust异步选型问题时，最先要做的不是对比性能，而是检查项目目前和未来可能引入的第三方库。tokio生态里hyper、tonic、reqwest这些库已经深度绑定了tokio的运行时特性，如果项目需要用到它们，基本没有选择空间，直接用tokio能省去大量适配工作。反过来，如果项目以文件操作为主、网络通信很少，async-std的API亲和性可能更合适。一位刚迁移Rust异步的同事曾跳过这一步，直接用async-std重写了一个依赖reqwest的服务，结果发现reqwest底层强制依赖tokio，不得不拆分运行时，多花了一周重构。所以第一件事：拉一个依赖清单，标记每个库的运行时要求，冲突项直接敲定方向。

选择tokio还是async-std，首要考虑的是生态成熟度。tokio诞生更早，社区贡献了大量现成的中间件，比如hyper、tonic、reqwest等，几乎成了Rust异步的事实标准。如果你的项目需要与这些库交互，或者团队已经熟悉tokio的Future调度模型，那么优先选tokio可以降低集成风险。async-std的特色是API更接近标准库，学习曲线平缓，但第三方库的支持范围和更新速度明显弱于tokio，在涉及复杂网络服务或需要长期维护的场景下，选择tokio往往更稳妥。如果团队里有人提议“async-std文档看起来简单”而想切换，可以先用一个原型模块跑通关键网络IO，看是否需要额外封装阻塞线程池，再决定是否全量迁移。

调度器选型：work-stealing vs 全局队列

tokio核心采用work-stealing调度器，多线程下每个worker维护独立的本地任务队列，空闲时主动偷取其他队列的任务，这种机制在高并发IO场景下能最大化CPU利用率。而async-std默认使用全局单一任务队列配合固定数量的工作线程，调度逻辑更简单，但在任务类型差异大或负载不均衡时可能导致某些线程过载。如果应用需要大量短连接、高吞吐或动态负载，tokio的work-stealing更具优势；若任务均匀且对调度公平性要求高，async-std的简单模型可能更易调试。实际排查中，一个常见现象是：用async-std跑HTTP短连接压测，一开始延迟平稳，但并发数升高后，某线程CPU飙到100%而其他线程闲置，这说明全局队列的瓶颈出现了。换成tokio后，通常worker线程利用率更均匀，但task窃取带来的缓存命中率下降需要额外观察。

验证调度器是否匹配负载的方法很简单：给应用一个模拟线上压力的场景，用perf或者tokio-console（仅限tokio）抓取任务执行时间分布和线程上下文切换次数。async-std可借助/proc/PID/stat或第三方profiler，但更直接的方式是看任务队列深度——如果全局队列持续堆积超过工作线程数两倍，就应该考虑换成work-stealing模型。如果项目对公平性有硬要求（比如多个租户共享一个运行时），且任务执行时间相近，async-std的FIFO队列反而能避免work-stealing导致的尾部延迟抖动。

取消与超时：边界行为不能想当然

任务取消和超时是异步编程的核心痛点。tokio提供了select!宏和tokio::time::timeout函数，取消行为遵循Drop语义，即被取消的Future的Drop方法会同步执行，这要求所有Future的Drop务必保持轻量。async-std同样有timeout，但它的取消实现依赖于内部线程协作，若Future正阻塞在某同步原语上，取消可能不会立即生效，存在潜在的内存泄漏风险。对于需要精确控制取消边界的系统，比如RPC超时或任务池管理，建议优先使用tokio的runtime，并确保关键Future实现了有界取消。曾经有个线上问题：async-std的超时后，一个持有锁的Future继续运行了数秒，导致整个任务池响应超时，底层原因是Future内部使用了标准库的Mutex，而async-std的取消信号没有传输到那个线程。

下一步判断：如果项目中用到了select!或tokio::time::timeout，并且任务内部有锁、channel或文件句柄等资源，建议强制使用tokio，并在每个分支的Drop里加一个检查点——比如记录日志或释放外部资源。对于async-std，可以在timeout后手动调用future.cancel()方法（需启用unstable特性），但要注意该方法只是设置一个标志位，并不能中断正在执行的同步阻塞代码。所以更稳妥的做法是：所有可能阻塞超过100ms的操作统一通过spawn_blocking委派，这样取消时至少能快速回收线程。

迁移路径：保留抽象层缓冲

如果团队经验偏少，建议先用async-std快速迭代业务逻辑，当遇到性能瓶颈或需要深度控制时再逐步替换组件到tokio，注意保留actor模式或消息通信的抽象层以降低重构成本。具体做法：在业务逻辑层统一使用async-trait定义trait，内部实现分别依赖tokio或async-std的spawn、sleep、IO操作。一旦要切换运行时，只需替换底层实现文件，无需改动业务代码。同时，可以利用cargo features控制依赖，比如default = ["async-std"]，当切换到tokio时启用tokio-runtime feature。迁移后需要全量回归测试，尤其留意JoinHandle的错误类型和取消行为差异——tokio的JoinError能区分panic和取消，而async-std的JoinHandle需要额外设计错误枚举。可以在CI中增加一个冒烟测试：启动一个简单TCP server，并发100个客户端请求，验证所有响应正常且无泄漏。如果发现tokio版本偶现连接重置，先检查是否误用了blocking API导致worker线程阻塞，再用tokio::task::spawn_blocking包裹文件操作。