在本站中

本站的代码里搜不到 parking_lot，所有 crate 的 Cargo.toml 里也没有它。Cargo.lock 里的 parking_lot 全是间接依赖，版本和本卷完全一致。这一页回答四个问题：谁把它带进来、开了哪些 feature、本站哪些代码路径会用到它、本卷的 09 常见坑 在本站碰不碰得到，最后看升级 0.13 的条件。

flowchart TB
  app["本站 app（server 构建）"] --> tokio["tokio 1.52.3，feature full 含 parking_lot"]
  app --> dsrv["dioxus-server 0.7.9：features = send_guard"]
  app --> dcore["dioxus-fullstack-core / dioxus-signals / generational-box 0.7.9"]
  app --> sqlx["sqlx-core 0.8.6"]
  sqlx --> fi["futures-intrusive 0.5.0"]
  tokio --> pl["parking_lot 0.12.5（default + send_guard）"]
  dsrv --> pl
  dcore --> pl
  fi --> pl
  gw["网关 crates/gateway（单独的 Cargo.lock）"] --> pg["pingora-core / cache / lru / pool / timeout 0.9.0"]
  pg --> fl["flurry 0.5.2（← pingora-core、pingora-lru）"]
  pg --> pl2["parking_lot 0.12.5（default + arc_lock）"]
  fl --> pl2
  gw -.->|"tokio 1.52.3 没开 parking_lot"| tk2["tokio 内部用 std 锁"]

锁定的版本

写作时 main 的 3292b81：

没有版本差异要讲。两个 lock 里都只有这一组版本，没有 0.13。

主工作区：谁带进来，开了什么

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

parking_lot_core 只开 default，lock_api 开 atomic_usize（默认）。lock_api 另有一个直接用户 futures-intrusive（它自己的 GenericMutex<R: RawMutex> 等泛型锁）。

服务端构建打开了 send_guard

-F server 下多出来的那一条 feature 来自 dioxus-server 0.7.9 的 Cargo.toml：

[dependencies.parking_lot]
version = "0.12.4"
features = ["send_guard"]

它自己用 parking_lot 的地方是 src/document.rs 里一个 static RENDERER: LazyLock<RwLock<Renderer>>。按 GuardSend 与 send_guard 讲的 feature 合并规则，这意味着生产服务端进程里所有 parking_lot 守卫都是 Send，包括 tokio、dioxus 其他 crate 里的。两个直接后果：

• 本站服务端构建不能再给 parking_lot 打开 deadlock_detection，否则编译 parking_lot 时就是 compile_error!（坑）。默认的 web 构建、桌面构建没有 send_guard，可以开。
• tokio 不受影响：它内部把 parking_lot 的类型包成 struct Mutex<T>(PhantomData<std::sync::Mutex<T>>, parking_lot::Mutex<T>) 一类的形状（tokio 1.52.3 src/loom/std/parking_lot.rs 第 12–28 行），注释写明是为了不让 send_guard 外溢到 tokio 自己类型的 Send 性上。

tokio 为什么开了 parking_lot

根 Cargo.toml 的 [workspace.dependencies] 写了 tokio = { version = "1.49.0", features = ["full"] }，各 crate 用 workspace = true 继承；tokio 的 full 包含 parking_lot。dev 依赖里还有一条：llm crate 的 dev 依赖 mockito 1.7.2 默认 feature 含 parking_lot = ["tokio/parking_lot"]。

打开后 tokio 内部的同步锁（loom::sync::Mutex / RwLock / Condvar）全换成 parking_lot 的，切换点在 loom/std/mod.rs 第 55 行（tokio 卷 crate 图）。本站会走到的典型路径：

• tokio::sync::Semaphore（batch_semaphore）的等待链表锁，只在改链表时持有（tokio 卷 batch-semaphore）；tokio::sync::Mutex 建在它上面。
• watch 通道的值外面那把同步 RwLock，borrow() 持读锁（tokio 卷 watch）。
• 运行时自身的调度、定时器、IO 驱动里的内部锁。

dioxus 与 sqlx

• generational-box 的 SyncStorage 格子是 parking_lot::RwLock，同线程拿着写锁再读就卡死（dioxus 卷 generational-box）；dioxus-fullstack-core 的 FullstackContext 把请求头、上下文各放在一个 Arc<RwLock<..>> 里（src/streaming.rs）。
• futures-intrusive 0.5.0 由 sqlx-core 0.8.6 带进来，它的 std 默认 feature 打开 parking_lot。但 sqlx-core 0.8.6 里 futures-intrusive 只出现在 src/sync.rs 的 AsyncSemaphore，而且只在 _rt-async-std 且没开 _rt-tokio 时用；本站 sqlx 开的是 _rt-tokio，那里用 tokio::sync::Semaphore（sqlx 卷 PoolOptions 讲过 fair 只对 futures-intrusive 有意义）。所以 futures-intrusive 编进来了，本站运行时的连接池不经过它的 parking_lot 锁（读源码得出，没有在运行的进程里核对）。

网关工作区

crates/gateway 有自己的 Cargo.lock，同样是 0.12.5 一组：

parking_lot 的 feature 是 default + arc_lock（来自 pingora-core），lock_api 相应多了 arc_lock。网关的 tokio 1.52.3 没有开 parking_lot feature，tokio 内部用 std 锁；网关的部署见 pingora 卷 在本站中。

常见坑在本站

本站自己的代码不直接用 parking_lot，下面只看依赖的用法和构建配置：

升级到 0.13 要等什么

本站不改依赖，这里只看 registry 里各上游的版本约束（Cargo.toml 的 [dependencies.parking_lot]）：

结论：本站两个工作区里几乎所有上游都把 parking_lot 钉在 0.12 系列，tokio 还用到了 0.13 删掉的 API。升级要等这些上游发版。0.12 和 0.13 是不兼容的两个版本，Cargo 可以让它们并存：将来若只有一部分上游升级，进程里会同时有两份 parking_lot、两份 parking_lot_core（各自一张全局哈希表），这是 0.13 的「各依赖各自升级」阶段的正常现象。pingora-lru 的 0 约束在 cargo update 时会不会被解析到 0.13.0，本页没有试（不改本站的 lock）。升级时要逐条对照的行为差别见 07 0.13 的变化，最可能影响本站的是去掉自动的最终公平（去掉的与修正的）。

小结

• 本站没有直接依赖 parking_lot；主工作区和网关都锁定 0.12.5 / 0.9.12 / 0.4.14，与本卷相同。
• 主工作区经 tokio（full 含 parking_lot）、dioxus 0.7.9 一族、futures-intrusive（← sqlx-core）带进来；网关经 pingora 0.9.0 和 flurry，网关的 tokio 没开 parking_lot。
• 生产服务端构建里 dioxus-server 打开了 send_guard：所有 parking_lot 守卫都是 Send，服务端不能再开 deadlock_detection；tokio 用 PhantomData 挡住了外溢。网关开了 arc_lock。
• sqlx 在 tokio 运行时下用 tokio 的信号量，futures-intrusive 编进来但连接池不走它的锁。
• 上游几乎都要求 0.12，tokio 还用了 0.13 删除的 const_mutex；本站升级 0.13 要等上游。