Rust 的 cfg 条件编译是怎么工作的？feature 和 target_os 各自适合什么场景？

直接回答：#[cfg(...)] 属性与 cfg! 宏在编译期按条件裁剪代码——未满足条件的代码在类型检查之前就被整段移除。条件来源有两类：编译器注入的平台信息（target_os、target_arch、unix 等），以及 Cargo 的包级 feature（cfg(feature = "serde")）。

展开解析：feature 定义在 Cargo.toml 的 [features] 段，适合可选依赖与功能开关；平台 cfg 用于写跨平台分支。cfg 是编译期裁剪而非运行时分支，两个分支的函数可以同名、各自引用只在本平台存在的 API。两个常见坑：一是不要用 cfg 做 rustc 版本检测，版本嗅探应由 build.rs 配合 autocfg 生成自定义 cfg；二是 workspace 中 feature 取并集（unification），设计要满足可加性（additive），不能表达互斥行为。

#[cfg(unix)]
fn enable_signals() { /* 只在 Unix 编译 */ }

#[cfg(feature = "metrics")]
pub fn record() { /* 开启 feature 才存在 */ }

追问方向：cfg! 与 #[cfg] 的区别？feature 并集在什么场景会踩坑？如何用 cfg 划分平台特定模块？ （约 500 字）