Tokio多线程调度器拆解：任务队列、工作窃取与阻塞任务边界

并行执行的异步运行时里，Tokio 的多线程调度器是绕不开的一块硬骨头。很多人用#[tokio::main]写了大半年业务代码，对它的认知仍然停留在“它会把 Future 分给多个线程跑”。真正出问题的时候——P99 毛刺、任务饥饿、线程数失控、进程退出卡死——才发现对这套调度器的工作方式一无所知，只能靠加日志和猜。这篇内容就是把这层黑盒拆开：讲清楚 worker 线程怎么起来、任务队列分几层、偷任务到底偷什么、协作式预算怎么防止单任务霸占线程、阻塞任务为什么要单独开池子，以及这些机制在真实调优里分别对应哪些参数和观测指标。适合已经能写 async 代码、但还没系统读过调度器实现的 Rust 开发者，也适合正在被延迟抖动折磨、需要判断“这到底是不是调度器的问题”的后端同学。文中给的参数、代码和排查路径都可以直接拿去对照自己的服务验证。

1. 先厘清一件事：多线程调度器解决的不是“CPU 不够”

我在压测里见过很多次类似的误判：服务延迟抖，第一反应是机器不够、加核、把worker_threads从 4 调到 16，结果抖动更严重了。原因很朴素——多线程调度器的主要收益不在吞吐，而在“等待的隔离”。一个 Future 在poll里返回Pending之后，它占用的线程必须立刻去干别的活；如果恰好有多个任务同时在等 IO，单线程运行时只能让它们排队等同一个线程空出来，而多线程运行时可以让另一个 worker 接手。所以多线程调度器最先改善的是并发等待场景下的尾延迟，而不是单纯的算力。

1.1 单线程运行时会在哪一步先撑不住

current_thread运行时的模型非常干净：一个线程，一个本地队列，一个 reactor。所有任务在这个线程上串行poll，谁Pending谁让位，下一个任务顶上。只要任务是“短 CPU 段 + 长等待”的形态，这套模型的表现其实相当好，缓存局部性也好，没有跨线程唤醒开销。它撑不住的是两类场景。

第一类是唤醒风暴。比如一个服务同时挂了 3000 个长连接，某一刻对端集体发数据，reactor 一次性把上千个任务标成 Ready。单线程要把这一千个任务的poll全部跑一遍才能回到epoll_wait，期间新到的数据只能干等。这时候尾延迟会突然抬头，而且和业务逻辑毫无关系。第二类是单点阻塞。任何一次不经意的同步阻塞调用——读一个本地文件、解析一个大 JSON、调一次没走异步封装的库——都会把整条流水线一起钉死，因为根本没有第二条线程能顶上来。

1.2 换成 multi_thread 之后多出来的三笔开销

代价必须提前讲清楚，否则调参就是在瞎调。

我个人的经验是：如果你的任务形态是“一个连接一个任务、任务之间几乎不互相唤醒”，多线程几乎是纯赚；如果是“一个请求拆成十几个阶段、阶段之间用 channel 串起来”，多线程反而可能因为任务迁移把收益吃掉大半。后者更适合用current_thread配合多实例部署，让隔离发生在进程级别而不是线程级别，代价是内存翻倍，但延迟曲线会稳得多。

判断标准很简单：把worker_threads设成 1，压一遍；再设成 CPU 核数，压一遍。如果 P99 没有明显改善，甚至更差，说明你的瓶颈不在等待隔离上，加线程只是给调度器添乱。

2. Runtime::new() 之后发生了什么：worker、parker、driver 的分工

Runtime::new()是个被封装得太好的入口，一行代码背后干了相当多的事：按worker_threads起若干 OS 线程、给每个线程分配一个本地任务队列和一对 parker、选其中一个 worker 承担 IO driver 和 time driver 的职责、初始化阻塞线程池的骨架、最后把这些东西打包进Handle供外部克隆使用。理解这个启动顺序，后面所有“为什么某个参数没生效”的问题都能自己回答。

2.1 Builder 上那几个真正影响行为的参数

Builder的方法有一长串，但真正会改变运行特征的其实就那么几个，其余多半是措辞糖。

use std::time::Duration; fn build_runtime() -> std::io::Result<tokio::runtime::Runtime> { tokio::runtime::Builder::new_multi_thread() .worker_threads(6) // 调度线程数，默认等于可用并行度 .thread_name("svc-worker") // 排查时靠它区分线程 .max_blocking_threads(128) // 阻塞池上限，默认 512 .thread_keep_alive(Duration::from_secs(30)) // 阻塞线程空闲回收时间 .enable_all() // IO + 时间驱动 .build() }

这几个参数的分工需要说清楚：worker_threads控制的是调度线程数量，这些线程的职责是pollFuture，它们不应该被任何阻塞操作占用；max_blocking_threads控制的是阻塞线程池上限，专门给spawn_blocking用，两套线程池完全独立。很多人把这两个数字混着理解，结果把worker_threads调到 64 想“多留点余量给阻塞任务”，实际只是让 64 个调度线程互相抢 CPU、加剧任务迁移。

提示：thread_name这一项看起来无关紧要，但它是事后排查性价比最高的设置。线上抓线程栈、看 CPU 火焰图，如果没有固定前缀，你很难在几十上百个线程里认出哪个是调度线程、哪个是阻塞线程。

还有个容易忽略的点：worker_threads的默认值不是“把核数乘二”，而是取可用并行度。这个值在容器里受 CPU 配额影响，某些编排环境下拿到的数字可能远大于实际可用核数，导致大量线程挤在少数核上反复切换。我一般会在启动日志里把实际生效的worker_threads和进程可见的 CPU 数一起打出来，出问题时第一眼就能对上。

2.2 park/unpark 与 IO driver 的归属

每个 worker 都有一个 parker。当它把自己本地队列和注入队列都清空、并且偷不到任务时，就进入 park 状态，让出 CPU。新任务到来时，负责调度的那一方会通过unpark把对应 worker 叫醒。这套机制的关键在于唤醒必须精确：如果来一个任务就把所有 worker 全部叫醒，就会出现大量无意义的上下文切换，也就是常见的惊群问题。Tokio 在这块用了比较克制的策略：只唤醒一个或少数几个 worker，并且在 park 之前会再检查一遍队列，避免刚 park 就有任务进来的竞态。

IO driver 的归属是个更隐蔽的设计。reactor 并不是每个 worker 都有一份，而是由其中一个 worker 持有。这个持有者在 park 时会带上超时，周期性去轮询一次 IO 事件；其他 worker 在 park 时则会设定一个较短的超时，醒来后发现没自己的事就继续 park。这么设计的原因是：IO 就绪事件的收集本质上是单点的，让多个线程同时去epoll_wait除了增加竞争没有收益。这个细节解释了为什么在某些极端情况下，承担 driver 的那个 worker 看起来比别的 worker 更忙——它除了跑任务，还多了一份轮询开销。

理解了这一层，你就知道Runtime不该被频繁创建销毁。每次build()都要起一批 OS 线程、注册 reactor、初始化时间轮，开销不小。正确的做法是一个进程建一个运行时，通过Handle::clone()分发给各处，而不是每个模块自己Runtime::new()。

3. 任务队列的三层结构：本地队列、短路径槽位与注入队列

调度的核心数据结构决定了性能上限。Tokio 的每个 worker 手上有一个容量有限的本地队列（一个无锁环形缓冲），外加一个只放一个任务的“短路径槽位”，全局层面还有注入队列。任务被spawn或者被唤醒时，会根据“谁在操作”走不同的路径进入这些队列。这套分层的意义全在减少竞争上：绝大多数调度决策都发生在本地，只有跨线程的少部分才需要碰共享结构。

3.1 本地队列的容量与溢出行为

本地队列按我读到的实现是固定容量 256 的环形缓冲，采用“生产者/消费者分离”的设计：自己往自己队列里推是单生产者，偷取方从另一端拿走是单消费者，两边不冲突。这个容量不是随便定的——太小会让任务频繁溢出去全局队列，太大又会让单个 worker 攒一堆任务而别的 worker 闲着。

队列满了之后的行为值得单独说：不是阻塞，也不是丢弃，而是把队列里大约一半的任务推到全局注入队列。这个设计很聪明，它让“本地队列溢出”从异常事件变成了一种天然的负载均衡信号：一个 worker 攒了太多活，就主动吐一半出去，让空闲的 worker 有机会接手。所以你在压测里看到注入队列长度上涨不一定是坏事，可能只是这台 worker 比较忙。

注意：这也意味着本地队列长度不是“这个 worker 有多忙”的可靠指标，它到 256 就封顶了，真实积压要看注入队列和全局任务数的组合。

3.2 短路径槽位为什么值得单独开一个位置

这是 Tokio 调度器里我认为最容易被低估的一个优化。设想一个典型的消息传递模式：任务 A 往 channel 里发消息，唤醒了任务 B。如果 B 被塞进队列尾部，前面可能还排着几十个任务，B 的延迟就被这些无关任务拉长了。而实际情况是，A 发完消息后大概率马上让出，B 立刻就能跑，这是最短的路径。

所以调度器给每个 worker 留了一个只放一个任务的槽位：唤醒发生在当前 worker 上时，被唤醒的任务优先塞进这个槽位，等当前任务让出后立刻执行。这个槽位在设计上还有一层讲究——它在被其他 worker 偷取时是最后才被考虑的，因为里面的任务大概率马上就要被执行，偷走反而是浪费。

我在做链路压测时对比过这个机制的影响：一个两段式 pipeline（上游解析、下游处理），在唤醒密集的情况下，关掉这个优化后尾延迟会有可感知的上升，因为每个下游任务都要在队列里排一段才能轮到。所以如果你写的是“生产者-消费者紧耦合”的代码，尽量让生产者和消费者在逻辑上靠近，别为了“解耦”硬加一层中转队列，那等于主动放弃了这个优化。

3.3 偷取策略：随机、批量与交叉惩罚

本地队列空了怎么办？去别的 worker 那里偷。这里有两个决策点：偷谁，偷多少。

偷谁：不是按顺序轮询，而是随机选起点。顺序轮询看起来公平，但在多核场景下会形成固定模式，导致某些 worker 反复被同一批对象偷，加剧缓存失效和伪共享。随机化打散了这种模式，代价是偶尔会偷到“刚被偷完”的空队列。

偷多少：一次偷走对方队列里约一半的剩余任务，而不是一个。理由是偷取本身有成本（需要访问对方的数据结构），偷一个太亏。但批量偷也有副作用：如果偷来的任务都是脏数据，缓存会直接被冲掉一大片。这就是所谓的交叉惩罚——A 偷走 B 的任务，B 的缓存里的数据在 A 那边全部失效。

实测里，这两种策略的组合在绝大多数负载下表现良好，但在任务粒度极不均匀的场景下会出问题：一个 worker 上排着一个要跑 50ms 的重任务和一堆轻任务，别的 worker 偷走了一半轻任务，重任务还留在原地，这个 worker 就长期处于“看起来有活但吞吐上不去”的状态。解决办法不是调调度器，而是把重任务挪出异步线程，用spawn_blocking或者干脆用独立的执行器，别让它和轻任务混在一个队列里。

4. 协作式预算：怎么防止一个任务把 worker 霸占死

协作式调度这个词听着抽象，落地到代码里其实就是一个计数器。Tokio 给每个被poll的任务分配一个初始额度，任务在poll过程中每做一次“可能就绪”的资源操作，就扣一点。额度耗尽之后，后续的资源操作不再返回Ready，而是直接返回Pending并把自己重新唤醒，强制这个任务让出线程。这一套机制解决的是协作式调度最怕的场景：一个任务因为在做流式处理，每次poll都能拿到数据，于是永远返回Ready，死循环一样霸占线程，其他任务全部饿死。

4.1 额度的消耗路径与真实触发点

按我读到的实现，每个任务拿到的是固定大小的初始额度。消耗发生在哪里？主要是在从 channel、socket 这类资源上取值的路径上——比如recv().await成功拿到一个消息、read().await成功读到一段字节，都算一次消耗。而纯 CPU 计算、纯内存操作并不消耗额度，因为没有统一的“资源就绪”钩子。

这就带来一个很重要的推论：预算机制能防住“IO 密集的无限循环”，防不住“CPU 密集的死循环”。

// 这种写法，预算救不了你 async fn bad_loop() { let mut sum: u64 = 0; loop { // 纯计算，没有资源操作，额度永远不消耗 sum = sum.wrapping_mul(6364136223846793005).wrapping_add(1); } }

上面这段代码只要跑起来，那个 worker 就彻底废了，其他任务在它上面排队的全部挂起。正确做法要么是把计算切块并主动yield_now().await，要么直接丢进spawn_blocking。前者适合可切分的大数组遍历，后者适合不可切分的一次性重计算。

反过来，一个读循环即使写得很“贪”，比如在没有背压的情况下疯狂recv，预算耗尽时会自动让出，让别的任务有机会跑。这就解释了为什么有些服务的阻塞问题在不同 Tokio 版本上表现不一样——预算相关的实现细节调整过，但核心思路一直是“给每个任务的单次执行设个上界”。

4.2 yield_now 到底做了什么，以及什么时候该用它

yield_now()经常被误解成“让出线程一小会儿”。它实际做的事情是：把当前任务重新放回队列（而且通常是很靠前的位置），让出执行权，等待下一次被调度。所以它不保证任何时间上的延迟，只保证“其他就绪任务有机会插队”。

合理的使用场景有两个。一个是长循环的切分点：你要处理一个百万级的数组，里面还有await，在每处理完一万条之后插一个yield_now，可以让同一 worker 上的其他任务不至于被饿太久。另一个是自旋等待的替代：有些代码用loop { if cond { break } }等一个标志位，这在异步函数里是灾难，改成每次检查后yield_now().await至少不会把线程锁死。

提示：别把yield_now当性能优化手段到处加。每一次让出都意味着一次队列操作和潜在的线程切换，在热路径上滥用会让吞吐明显下降。判断标准是“这段代码单次执行超过几百微秒”，低于这个量级没必要切。

还有个容易踩的坑：在spawn_blocking里调yield_now是没有意义的。阻塞线程池里的线程不跑调度循环，那个 await 只会让它原地空转，白白增加开销。这个错误我在 review 里见过不止一次，通常是从异步上下文复制粘贴过去忘了删。

5. 阻塞任务的处理边界：spawn_blocking 与 block_in_place

“异步运行时里不能有阻塞操作”这句话人人都知道，但真正落地的时候，判断标准往往很模糊：读一个 10KB 的配置文件算不算阻塞？调一个第三方 SDK 里的同步 HTTP 客户端算不算？答案取决于阻塞时长和频率。我的经验线是：单次超过 100 微秒、或者调用频率高于每秒几千次，就应该认真考虑挪走。低于这个量级，硬塞进阻塞池带来的调度开销可能比阻塞本身还贵。

5.1 阻塞线程池的容量、回收与堆积风险

spawn_blocking提交的任务进的是一个独立的线程池，默认上限 512 个线程，空闲线程默认 10 秒后回收。这个“上限”不是池子预创建的线程数，而是最多能同时存在多少个阻塞线程。超过上限的提交会排队等待，等待期间不占用任何线程。

这里藏着一个很典型的线上事故形态：某个下游接口变慢，每个请求的阻塞调用从 5ms 变成 500ms，阻塞池里的线程被快速占满，后续spawn_blocking全部排队。表现是接口整体超时，但 CPU 使用率很低，异步线程池看起来完全空闲。如果你只看调度线程的指标，会觉得服务什么都没干，实际上活全堵在阻塞池的队列里。

所以阻塞池必须单独观测。至少要盯两个数：当前存活的阻塞线程数、排队等待的任务数。前者接近max_blocking_threads就说明容量告急，后者不为零说明已经在排队了。容量调大不是万能药——512 个线程同时做磁盘 IO，磁盘本身的队列深度会成为新瓶颈，而且大量线程会让上下文切换成本飙升。真到了这一步，该做的是给阻塞调用加并发上限（用Semaphore控制同时在飞的数量），把压力反馈回上游，而不是无限扩池。

use std::sync::Arc; use tokio::sync::Semaphore; async fn guarded_blocking_call( permit: Arc<Semaphore>, payload: Vec<u8>, ) -> std::io::Result<Vec<u8>> { // 先拿许可，拿不到就在这里等，压力自然回传到调用方 let _p = permit.acquire().await.expect("semaphore closed"); tokio::task::spawn_blocking(move || do_heavy_io(&payload)) .await .expect("blocking task panicked") } fn do_heavy_io(input: &[u8]) -> std::io::Result<Vec<u8>> { // 同步实现细节省略 Ok(input.to_vec()) }

这段代码的价值不在于写法，而在于把不可控的排队变成了可控的限流。信号量拿不到时任务在异步侧等待，不占用阻塞线程，这比让 512 个线程全部卡死要好得多。

5.2 block_in_place 的代价与使用禁区

block_in_place是另一个工具，作用完全不同：它告诉运行时“我要在这个调度线程上阻塞一会儿，你另找个线程接替我的调度职责”。实现上会把当前 worker 转成阻塞线程，然后从别的线程或新建线程接替它的调度循环。

它只能用在多线程运行时上，current_thread下调用会直接 panic。除此之外还有两个隐性成本：一是接替过程本身有开销，频繁调用会导致线程数反复波动；二是被转换的线程在阻塞期间不再参与任务偷取，等于临时减少了可用调度线程数。所以它的适用场景很窄——只适合“我知道这里会阻塞，但阻塞时间很短、且调用频率不高”的情况，比如偶尔读一个小文件、偶尔做一次短同步调用。真正重的活，老老实实走spawn_blocking。

一个常见误用是在block_in_place里调用一个会等待很长时间的同步 API，然后以为“反正运行时会接管”。运行时会接管调度，但你的线程就是被占着，如果这种调用并发量一大，worker 会一个个被转换出去，最后没有线程做调度，整个运行时停摆。这种故障现场很难查，因为线程栈看起来“一切正常”。

6. 参数调优与线上观测：怎么确认瓶颈真的在调度器

调参之前必须先能观测，否则就是在做随机实验。我见过太多人改了worker_threads之后凭“感觉好像快了点”就收工，过两天抖动回来了又改回去，来回折腾。正确的顺序是：先定位瓶颈在哪个队列、哪类线程，再决定动哪个参数。

6.1 worker_threads 到底该设多少

这个问题的答案取决于任务形态，但有几条经验线可以参考。

一个反直觉的结论：worker 数超过物理核数，在等待密集场景下收益极小，在 CPU 密集场景下是负收益。因为调度线程本身也要消耗 CPU，线程越多，花在上下文切换和队列操作上的时间越多。我在一台 8 核机器上压过一组对比，worker_threads从 8 加到 16，吞吐基本持平，P99 反而涨了一截，问题就出在任务迁移和缓存失效上。

另一个经常被忽略的因素是容器环境。在 CPU 受限的容器里，available_parallelism可能返回宿主机的核数，运行时就会起一批根本抢不到 CPU 的线程。这种情况必须显式设置worker_threads，不要依赖默认值。

6.2 该看哪些指标，以及怎么读

观测有两个层次：运行时自带的指标和 tokio-console 这类可视化工具。

指标层面，需要开启不稳定特性才能拿到完整的运行时度量。这些数字里最有价值的是四组：worker 的忙碌时长、park 次数、偷取次数、本地队列深度。它们能直接回答“调度器是不是瓶颈”。

// 需要 RUSTFLAGS="--cfg tokio_unstable" 才能编译通过 fn dump_metrics(handle: &tokio::runtime::Handle) { let m = handle.metrics(); println!("alive tasks : {}", m.num_alive_tasks()); println!("blocking threads: {}", m.num_blocking_threads()); println!("blocking queued : {}", m.num_blocking_threads() as u64); println!("remote schedule : {}", m.remote_schedule_count()); }

读这些数的逻辑是：park 次数高、偷取次数低，说明整体负载不足，线程大量空转，这时候加线程纯属浪费；偷取次数高、本地队列长期接近满，说明负载不均或者单任务过重，要看具体是哪个任务卡住了 worker；阻塞线程数和阻塞排队数同时上涨，说明瓶颈在阻塞池，跟调度线程没关系。

tokio-console 提供的是任务粒度的视角，能看到每个任务的 poll 次数、忙碌时长、当前状态。它对定位“哪个任务在霸占线程”极其有效——直接按 busy 时间排序，排在最前面的那个就是嫌疑对象。

# 编译和运行时都要带上不稳定标志，服务端与客户端保持一致 RUSTFLAGS="--cfg tokio_unstable" cargo run --release

fn init_console() { console_subscriber::init(); }

注意：这套工具本身有开销，每个任务的 poll 都会被记录。线上长时间开启要谨慎，建议用采样或者只在排查窗口内开启，别长期挂在生产环境上。另外它依赖不稳定特性，跨版本升级时 API 可能变，别把它写死进核心链路。

7. 几个反复出现的坑与它们的排查链路

下面这几个问题我在不同项目里见过多次，症状各不相同，但根因都落在调度器语义上。把它们记下来，下次遇到类似现象可以少走弯路。

7.1 所有任务停住，但 CPU 和内存看起来都很闲

现象：服务在运行一段时间后完全无响应，健康检查超时，但进程还在，CPU 接近 0，内存没有明显增长，也没有 panic 日志。重启后恢复正常，过一阵又出现。

排查链路应该这样走。第一步，抓线程栈（gdb或者运行时的栈打印能力），看调度线程在干什么。如果全部停在 park 上，说明队列里没有任务可跑，问题在“任务根本没有被唤醒”，而不是“任务跑不完”。第二步，检查是否有一个任务持有了锁然后永久挂起——比如在持锁状态下await了一个永远不会返回的 Future，其他想拿锁的任务全部阻塞在等待上，而等待本身不消耗 CPU。第三步，检查阻塞池是否已经耗尽并且有任务在排队，如果是，说明某个阻塞调用卡住了。

这类问题最常见的根因是：异步上下文里用了同步锁，并且把锁跨await持有。同步锁在拿不到时会阻塞线程，而在异步函数里阻塞线程意味着那个 worker 被钉死，如果所有 worker 都这么被钉死，运行时就是完全停摆。修法是把锁换成异步版本，或者缩小临界区，确保锁在await之前释放。

7.2 线程数莫名其妙涨到几百

现象：一个本来很轻的服务，进程线程数稳定在 300 以上，top里看 CPU 不高但系统态占比很高。

第一步，按线程名前缀分类统计。如果涨的是阻塞线程，说明spawn_blocking的调用量远超预期——常见于在一个高频路径上做了“顺手”的阻塞调用，比如每次请求都去读一次本地配置。第二步，如果涨的是调度线程，那就要回头检查运行时的构建代码，是不是在多个地方各自Runtime::new()，或者某个库内部偷偷建了运行时。第三步，看thread_keep_alive的设置，如果设得很长，阻塞线程回收慢，短时高峰过去后线程数会长期维持在高位。

这里有个经验值：阻塞线程数应该和“同时在飞的阻塞操作数”量级相当，而不是和 QPS 挂钩。如果你的阻塞线程数和 QPS 成正比，说明每次请求都在开新的阻塞任务，这时候应该考虑把这类操作改成异步，或者用一个固定大小的工作池来承接。

7.3 进程退出卡在最后一步

现象：收到停止信号后，服务不再处理新请求，但进程迟迟不退出，最后被外部手段强杀。

原因是运行时的关闭过程会等待阻塞任务完成。如果阻塞池里还有任务，尤其是那种“在等一个永远不会来的信号”的任务，关闭就会一直等下去。异步任务相对好办，它们会在poll返回Pending后被丢弃；阻塞任务没这个机制，只能等它自己返回。

处理方式有三层。第一层是给阻塞任务本身加超时，不要写无限等待的循环。第二层是在关闭流程里显式控制等待时长，不要依赖运行时的默认行为。第三层是在设计上避免长时间阻塞任务，把“可能要跑很久”的活拆成可中断的小段，每段之间检查一次停止标志。

use std::sync::atomic::{AtomicBool, Ordering}; use std::sync::Arc; use std::time::{Duration, Instant}; fn cooperative_blocking_loop(stop: Arc<AtomicBool>, deadline: Instant) { while !stop.load(Ordering::Relaxed) { if Instant::now() >= deadline { break; } // 单次工作量控制在较短时间片内，保证能及时响应停止信号 do_one_chunk(); } } fn do_one_chunk() { // 具体处理逻辑省略 }

这段代码不长，但它是让“阻塞任务可被优雅关闭”的最低成本做法。我在需要跑后台任务的场景里基本都会保留一个这样的停止标志加截止时间，比事后追查为什么进程退不掉要省心得多。

再补一个容易被忽略的小点：如果一个 Future 在poll中途被丢弃（比如select!抢输的那一支），它的析构会在当前线程同步执行。如果析构里做了重活，那本质上就是一次阻塞。写自定义 Future 或者包装第三方资源时，注意Drop的实现别太重，需要清理的活丢进阻塞池去做比较稳妥。