为何Rust会将仅开发用特性纳入Release构建？

云原生阿岚

2026-6-16

问题分析与解决方案

核心问题原因

你遇到的 Release 构建中 api_key 取到常量值的问题，根源在于对 Rust/Cargo 的配置标记（cfg）和依赖特性作用范围的误解：

#[cfg(test)] 仅在执行 cargo test（包括 cargo test --release）时生效，常规 cargo build --release 不会启用该标记。如果你的 Release 构建出现 "test" 值，大概率是误执行了测试构建命令，或是主依赖 auth 被意外启用了 dev 特性。
[dev-dependencies] 中的特性配置只影响测试代码编译时的依赖版本，不会改变主二进制构建时主依赖的特性。你当前主依赖配置是 default-features=false, features=["some_other_feature"]，正常情况下不会启用 dev 特性。

排查与修复步骤

确认构建命令
确保执行的是 cargo build --release 而非 cargo test --release。后者会触发 test 配置标记，执行 api_key = "test".to_string() 分支。
验证 dev 特性是否被意外启用
在 auth 库中添加临时编译检查，确认主依赖是否被错误启用 dev 特性：
```
#[cfg(feature = "dev")]
compile_error!("Dev feature is unexpectedly enabled in production build!");
```
执行 cargo build --release，若触发编译错误，说明你可能通过命令行参数（如 --features=dev）或其他配置意外启用了该特性，需排查并移除相关配置。

优化配置分支逻辑
为避免混淆，明确区分生产、开发、测试环境的逻辑，同时处理环境变量不存在的异常情况：

// 生产环境：从环境变量读取，强制要求变量存在
#[cfg(not(any(feature = "dev", test)))]
let api_key = std::env::var(API_KEY_HEADER)
    .expect("API_KEY environment variable is required for production");

// 开发/测试环境：使用常量值
#[cfg(any(feature = "dev", test))]
let api_key = "test".to_string();