通过Cargo特性标记管理开发依赖：与常规方式是否等价？会有解析风险吗？

背景 #

我正在开发一个Rust crate，包含若干[dependencies]和[dev-dependencies]。部分开发依赖是全新的crate，还有一些只是为已作为正式依赖引入的crate启用额外特性。

比如，我的crate使用serde但不需要派生序列化实现，但测试场景需要该功能，最初的Cargo.toml如下：

[package]
name = "example"
version = "73015087.0.0"
edition = "2021"

[lib]
path = "/dev/null"

[dependencies] 
serde = "1.0.139"

[dev-dependencies]
serde = { version = "1.0.139", features = ["derive"] }

我不想重复版本号（担心更新时不同步），曾尝试用无界版本范围：

[dev-dependencies]
serde = { version = ">=0", features = ["derive"] }

但这种方式不够优雅（还要规避crates.io禁止用*作为完全无界版本的限制）。我希望不用重复声明serde依赖，只启用其特性，于是采用了另一种方案。

方案思路 #

不再直接在[dev-dependencies]下声明开发依赖，而是在[dev-dependencies]中依赖当前crate自身，并启用名为dev-dependencies的特性标记，通过该标记启用serde的derive特性，无需重复版本号或使用无界范围：

[package]
name = "example"
version = "73015087.0.0"
edition = "2021"

[lib]
path = "/dev/null"

[dependencies]
serde = "1.0.139"

[dev-dependencies]
example = { path = ".", default-features = false, features = ["dev-dependencies"] }

[features]
dev-dependencies = [
  "serde/derive",
]

后来我还发现可以把所有依赖版本统一放在[dependencies]下，将新增的开发依赖设为可选依赖，通过该特性标记启用。比如把expect-test作为可选依赖加入，而非放在[dev-dependencies]中：

[package]
name = "example"
version = "73015087.0.0"
edition = "2021"

[lib]
path = "/dev/null"

[dependencies]
expect-test = { version = "1.3.0", optional = true }
serde = "1.0.139"

[dev-dependencies]
example = { path = ".", default-features = false, features = ["dev-dependencies"] }

[features]
dev-dependencies = [
  "serde/derive",
  "expect-test",
]

这种方式虽特殊，但我更倾向于集中管理所有版本信息，避免重复，正考虑长期采用该方案。

问题 #

这种通过Cargo特性标记管理开发依赖的方式，与常规声明开发依赖的方式相比，是否存在显著行为差异？或是两者完全等价？后续是否会遇到更复杂的依赖解析问题？

依赖解析结果 #

启用开发依赖前后的cargo tree输出：

$ cargo tree -e normal
example v73015087.0.0 (/workspaces/example)
└── serde v1.0.139

$ cargo tree -e normal,dev
example v73015087.0.0 (/workspaces/example)
├── expect-test v1.3.0
│   ├── dissimilar v1.0.4
│   └── once_cell v1.13.0
└── serde v1.0.139
    └── serde_derive v1.0.139 (proc-macro)
        ├── proc-macro2 v1.0.40
        │   └── unicode-ident v1.0.2
        ├── quote v1.0.20
        │   └── proc-macro2 v1.0.40 (*)
        └── syn v1.0.98
            ├── proc-macro2 v1.0.40 (*)
            ├── quote v1.0.20 (*)
            └── unicode-ident v1.0.2
[dev-dependencies]
└── example v73015087.0.0 (/workspaces/example) (*)

分析与结论 #

行为差异与等价性 #

• 依赖传递逻辑不同
  常规方式下，dev-dependencies是独立于主 crate 的依赖集，仅在测试、文档构建等开发场景下被引入；而你的方案是通过主 crate 的特性来激活可选依赖，本质是让主 crate 在开发场景下作为自身的依赖，间接启用特性和可选依赖。从最终依赖树看，两者引入的依赖项一致，但依赖关系的层级不同——你的方案多了一层主 crate 作为 dev 依赖的引用。

• 特性与可选依赖的可见性
  常规方式中，开发依赖的特性不会影响主 crate 的特性集；但你的方案里，dev-dependencies特性属于主 crate 的公开特性（除非用private-features标记），这意味着如果其他 crate 依赖你的 crate 并启用该特性，会意外引入这些本应仅用于开发的依赖，这是一个关键差异。

• 构建产物的影响
  常规开发依赖不会被包含在主 crate 的编译产物中；而你的方案中，可选依赖是主 crate 依赖集的一部分，若不小心在主代码中引用了这些可选依赖的代码（即使未启用特性），可能导致编译错误，或者在启用特性时主 crate 的编译产物会包含这些依赖的代码（不过你仅在开发场景启用，所以主产物不受影响）。

潜在的依赖解析问题 #

• 循环依赖风险
  虽然当前通过path = "."依赖自身不会触发循环依赖（Cargo 处理这种情况有特殊逻辑），但如果后续主 crate 的依赖或特性设计变得复杂，可能会引入难以排查的循环依赖问题。

• 版本冲突概率提升
  当你的 crate 被其他项目依赖时，主 crate 的可选依赖版本会参与全局依赖解析。如果其他依赖也依赖expect-test等 crate 且版本范围冲突，可能会导致依赖解析失败——而常规开发依赖不会参与主依赖树的解析，仅在开发场景下独立解析，冲突概率更低。

• 特性组合的复杂性
  若后续需要添加更多特性组合，dev-dependencies特性可能会和其他公开特性产生意外的交互，增加维护成本。

建议 #

如果你的 crate 是内部私有 crate，这种方案可以接受，毕竟能集中管理版本；但如果是要发布到 crates.io 的公开 crate，不建议长期采用——因为公开特性可能被误启用，引发不必要的依赖问题。

替代方案：使用cargo-edit等工具自动同步版本号，或者在Cargo.toml中使用版本变量（Cargo 1.60+支持），比如：

[package]
name = "example"
version = "73015087.0.0"
edition = "2021"

[lib]
path = "/dev/null"

[dependencies]
serde = { version = "1.0.139" }

[dev-dependencies]
serde = { version = serde.version, features = ["derive"] }
expect-test = "1.3.0"

这样既避免了版本重复，又保留了常规开发依赖的清晰逻辑。

内容的提问来源于stack exchange，提问作者user19567871