源码地图

主线位置：不在主线上。本页说明两条主线经过的代码在哪个模块、要打开哪个 feature 才能编译到它，以及模块之间谁用了谁。

模块之间的依赖（只画 crate 内部 use 出来的边，测试代码不算）：

flowchart TB
  trace --> classify
  oed["on_early_drop（EarlyDropsAsFailures）"] -.->|"开了 trace 才有"| trace
  auth --> validate_request
  compression --> cu[compression_utils]
  compression --> ce[content_encoding]
  decompression --> cu
  decompression --> ce
  decompression --> body
  fs["services::fs"] --> ce
  fs --> set_status
  fs --> body
  limit --> body
  catch_panic --> body

一个 crate，三万行

仓库是一个 workspace，发布的只有 tower-http 一个 crate，旁边的 examples/ 是 axum、tonic、warp 各一个 key-value-store 示例，外加一个 custom-future-multiple-bodies。tag 里 tower-http/src/ 下所有 .rs 一共 31 619 行，包括注释、文档和模块内的 #[cfg(test)] 测试，只用来估计分量：

lib.rs 从第 210 行起是一串 #[cfg(feature = "...")] pub mod ...;，feature 名用连字符，模块名用下划线。有两个模块前面没有 cfg：

pub mod classify;
pub mod services;

classify 不受 feature 控制，任何配置下都能用（第 320 行）；services 本身总在，但里面的 fs、redirect 各自挂着 feature，都不开时它是个空模块。另外两个内部模块按「谁需要」编译：content_encoding 在任何 compression-*、decompression-* 或 fs 下编译，fs 那一行的注释写着「Used for serving precompressed static files as well」；compression_utils 只在压缩、解压下编译。

feature：默认全关

[features] 里 default = []。只写 tower-http = "=0.7.1"，依赖树是这样的：

nofeat v0.1.0
└── tower-http v0.7.1
    ├── bitflags v2.13.2
    ├── bytes v1.12.1
    ├── http v1.5.0
    │   ├── bytes v1.12.1
    │   └── itoa v1.0.18
    ├── percent-encoding v2.3.2
    ├── pin-project-lite v0.2.17
    ├── tower-layer v0.3.3
    └── tower-service v0.3.3

连 http-body 都不在：所有和 body 打交道的模块都挂在 feature 后面。默认能用的只有 classify、LatencyUnit 和 BoxError。bitflags、percent-encoding 两个非可选依赖都是给 classify 用的：gRPC 分类器用位掩码记「哪些 code 算成功」，0.7.0 的 #422 让它把 grpc-message 百分号解码后带进失败信息，percent-encoding 也就从 fs 的可选依赖变成了必选。

[features] 里显式写出的 feature：

一共 35 个。full 是 23 个模块 feature 加 compression-full、decompression-full。

隐式 feature

Cargo 会给每个可选依赖生成一个同名 feature，除非某个 feature 用 dep:名字 引用过它。tower-http 的可选依赖里，有的写了 dep:（http-body、tokio、url……），有的没写（fs = [..., "mime_guess", "mime", "httpdate", ...]），没写的就留下了隐式 feature。cargo metadata 看到的是 45 个：

0.7.1 features: 45 implicit: 10
implicit: base64 futures-core futures-util httpdate mime mime_guess tokio-util tower tracing uuid

这 10 个都能在 Cargo.toml 里直接写，比如 features = ["tracing"]，它的效果是打开可选依赖 tracing，让各处 #[cfg(feature = "tracing")] 的日志代码编译进来。trace 和 catch-panic 两个 feature 会顺带打开它，其余模块不会。

feature 之间的依赖

只有三处是 feature 依赖 feature：

on-early-drop 不依赖 trace，但它的 EarlyDropsAsFailures 包在 #[cfg(feature = "trace")] 里，两个都开才有。util 拉进 tower（ServiceBuilderExt 要给 tower::ServiceBuilder 加方法）；follow-redirect 只拉 tower/util，不需要 tower-http 自己的 util。

公开 API 只认这几个外部 crate

Cargo.toml 末尾有一段给 cargo-check-external-types 用的白名单，CI 用它检查公开 API 里出现的外部类型：

[package.metadata.cargo_check_external_types]
allowed_external_types = [
    "bytes::*",
    "http::*",
    "http_body::*",
    "mime::*",
    "tokio::*",
    "tower::*",
    "tower_layer::*",
    "tower_service::*",
    "tracing::*",
    "tracing_core::*",
]

http_body 在，http_body_util 不在。tower-http 内部到处用 http-body-util 的 Full、Limited、UnsyncBoxBody，但只要它们会出现在公开签名里，就得先包一层，这就是 body 模块存在的原因。

MSRV

rust-version = "1.65"，0.7.0 从 1.64 提上来（#684）。那个 PR 给 ServeDir 加了 Backend trait，里面用到泛型关联类型（GAT），GAT 是 1.65 稳定的。edition 还是 2018。

小结

• 一个 crate，src/ 3.16 万行；最大的是 services（5.2k，几乎全是 fs）、trace、cors、follow_redirect、compression。
• 35 个显式 feature：23 个模块、压缩 5 个、解压 5 个、default（空）和 full；cargo metadata 另有 10 个隐式 feature，tracing 是其中之一，0.6.9 起 fs 不再打开它。
• classify 不受 feature 控制；默认配置下连 http-body 都不依赖。
• feature 依赖只有 auth → validate-request、fs → set-status；模块依赖里 trace → classify 最重要，EarlyDropsAsFailures 要 trace 和 on-early-drop 都开。
• 公开 API 的外部类型白名单里没有 http_body_util；MSRV 1.65，来自 0.7.0 的 GAT。