在本站中

本站的 Cargo.toml 里没有 rayon，代码里也搜不到 rayon::、par_iter。Cargo.lock 里的 rayon 1.12.0 和 rayon-core 1.13.0 全是间接依赖，和本卷的版本完全一致。这一页回答四个问题：谁把它带进来、在哪个进程里真的会跑、本站的哪条代码路径会走到它、本卷 09 常见坑 哪些在本站碰得到。

flowchart TB
  site["本站 app（server 构建）"] --> search["module-search"]
  search --> tantivy["tantivy 0.27.0"]
  tantivy --> rayon["rayon 1.12.0"]
  rayon --> rcore["rayon-core 1.13.0"]
  rcore --> deque["crossbeam-deque 0.8.6"]
  tantivy --> meta["私有池 segment_updater：1 线程"]
  tantivy --> merge["私有池 merge_thread_i：4 线程"]
  desk["本站 app（desktop feature）"] --> dd["dioxus-desktop 0.7.9"]
  dd --> image["image 0.25.10（默认 feature 含 rayon）"]
  image --> rayon
  image --> ravif["ravif → rav1e → maybe-rayon、av-scenechange"]
  ravif --> rayon
  image --> exr["exr 1.74.0"]
  exr --> rcore

锁定的版本

本站仓库根目录的 Cargo.lock（写作时 main 的 3292b81）：

网关 crates/gateway 有自己的 Cargo.lock，里面没有 rayon。

依赖链

在本站目录下用 cargo tree --offline --locked -i rayon -e normal 和 -i rayon-core 反查（只解析 lock，不编译），三种口径：

所以生产进程里的 rayon 只有 tantivy 一个用户。module-search 的 tantivy 依赖是 optional 的，只在它的 server feature 下打开，app 的 server feature 把 module-search/server 带上。桌面端那一族只在打开 desktop feature 时编进来，生产构建没有；桌面端是否真会执行到 rayon 代码（图标解码之类大概不会进 avif 编码和 exr），本页没有核实，属推测。

tantivy 怎么用 rayon

tantivy 0.27.0 的 src/ 里 rayon 只出现在三个文件：core/executor.rs、error.rs（错误类型转换）、indexer/segment_updater.rs（git grep）。没有一处 par_iter、join，也没有调用全局池的函数；它只自己建 ThreadPool，用 spawn 和 scope。

搜索：Executor，本站走单线程

Executor 有两个变体：SingleThread 和 ThreadPool(Arc<rayon::ThreadPool>)。multi_thread 用 ThreadPoolBuilder 建一个池，线程名是前缀加编号；map 在多线程模式下 pool.scope，给每个段 spawn 一个任务，结果经 crossbeam 无界 channel 发回，scope 返回后按下标放回原位（本卷 scope 家族 末尾拿它做过例子）。

Index 的 executor 默认是单线程：唯一构造 Index 结构的 open_from_metas 写死 Executor::single_thread()，要多线程得显式调 set_multithread_executor / set_default_multithread_executor（线程名前缀 tantivy-search-）。本站全仓库搜不到这两个调用，module-search 的 engine 模块只 Index::open_or_create 加注册 jieba 分词器。所以本站的查询不经过 rayon：/api/search/query 这个 server 函数在 tokio worker 上直接调 searcher.search，各段在调用线程上顺序跑（tantivy 卷 Searcher；换成多线程 executor 时要在建 reader 之前设，见 executor 设晚了）。

写入：SegmentUpdater 的两个池

每个 IndexWriter 在 SegmentUpdater::create 里建两个 rayon 池：

两者都是 pool.spawn，即本卷 spawn 讲的 HeapJob + terminate_count。结果不经 rayon 传回：schedule_task 和 start_merge 各建一个 FutureResult，底下是 oneshot crate 的 channel，任务结束时 send。单线程的元数据池本身就是一把「串行化所有元数据修改」的锁：所有 schedule_task 的闭包在同一个线程上按 FIFO（池外 spawn 进注入队列）依次执行。

本站 module-search 每次写入（replace_all / upsert_documents / delete_documents）都新开一个 index.writer(50_000_000)，用完 commit 后 wait_merging_threads 再丢掉。50 MB 的预算按每线程至少 15 MB（index_writer.rs:29-32）算，最多 3 个索引线程（index.rs:753-763，在至少 3 核的机器上），所以每次写入建起 3 个索引线程（std::thread，名字 thrd-tantivy-index{i}）+ 1 个 segment_updater + 4 个 merge_thread_*，写完全部退出（tantivy 卷 IndexWriter 里数过线程）。也就是说本站每写一次就建、拆两个 rayon Registry；rayon 的全局池在生产进程里从未被初始化（tantivy 不调全局函数，别的依赖没有 rayon；由 git grep 和依赖树推出，没有在运行的进程里核对）。

写入时等在哪里

本站的增量重建（main 里 tokio::spawn 的每 10 分钟循环）和管理员的 search_reindex 都在 async 函数里直接调 engine 模块的同步写入函数，没有 spawn_blocking。调用线程是 tokio worker，它在三处阻塞，都不是 rayon 的 latch：

1. commit() → PreparedCommit::commit → schedule_commit(..).wait()：FutureResult::wait 是 oneshot::Receiver::recv()，等元数据池把提交做完。
2. wait_merging_threads 先 join 索引线程（std::thread::JoinHandle）。
3. 再调 wait_merging_thread：merge_operations.wait_until_empty()。MergeOperationInventory 是 census 0.4.2 的 Inventory，wait_until_empty 在一个 Mutex + Condvar 上等存活的 MergeOperation 计数归零。每个合并任务的闭包拥有一个 MergeOperation，任务结束时 drop，计数减一并 notify。

合并线程那一侧也有一处阻塞：合并写完后 end_merge 把收尾交给元数据池，再 .wait() 等它（第 700 行）。这是一个 rayon worker 阻塞在 oneshot 上、等另一个池的任务。它不会饿死：元数据池的任务（consider_merge_options → start_merge）只往合并池 spawn、把返回的 FutureResult 直接 drop，从不反过来等合并池（读源码得出）。

所以本卷讲的 in_worker_cold / LockLatch 在本站不出现：tantivy 从池外进 rayon 只用 spawn，不用 install、join、scope（多线程 executor 才用 scope，本站没开）。本站等 rayon 任务完成，靠的是 tantivy 自己的 oneshot 和 census 的 Condvar。

常见坑在本站

逐条对照 09 常见坑，依据是上面读过的 tantivy 0.27.0 源码和本站 module-search：

小结

• 本站没有直接依赖 rayon；lock 里是 rayon 1.12.0、rayon-core 1.13.0，与本卷相同；crossbeam-deque 是 0.8.6，比本卷旧两个补丁版本，没有行为差异。
• 生产构建只经 tantivy ← module-search 带进 rayon；wasm 前端没有；image 一族只在 desktop feature 下进来。
• 本站搜索走 tantivy 默认的单线程 executor，查询不碰 rayon。用到 rayon 的只有写入：每个 IndexWriter 一个 1 线程的 segment_updater 池和一个 4 线程的 merge_thread_* 池，都只用 spawn，结果经 oneshot 传回。
• 本站写入时 tokio worker 阻塞在 tantivy 的 oneshot 和 census 的 Condvar 上，不是 rayon 的 LockLatch；元数据池没有 panic_handler，那里的 panic 会让整个进程 abort。