Rust 项目依赖选型与生态集成时，如何选 crate…

在 Rust 项目中新增依赖、排查 crate 找不到/私有项/feature 未启用等错误，或需要与 C、Python、Node.js、WebAssembly 互操作时使用。

适用场景

解决思路

1. 新增依赖前先问三个问题：是否存在标准方案？维护状态如何？API 是否稳定？
2. 按需求对照选型：序列化用 serde + serde_json（derive 方式）；异步运行时用 tokio（最流行）或 async-std；HTTP 客户端用 reqwest；HTTP 服务端用 axum 或 actix-web；数据库用 sqlx 或 diesel；CLI 解析用 clap（derive 方式）；错误处理应用侧用 anyhow、库侧用 thiserror；日志用 tracing 或 log。
3. 评估 crate 维护状况：看最近提交、issue 响应是否活跃、破坏性变更频率。
4. 评估依赖范围：判断需要整个 crate 还是只需某个 feature，用 feature flags 削减体积。
5. 评估集成方式：它是基于 trait 还是具体类型？同步还是异步？要求哪些 trait bound？
6. 把选型问题上溯到领域约束：问性能要求、查 domain-web 的延迟与吞吐需求、考虑团队对框架的熟悉度；库 vs 构建方式看部署模型；API 设计看消费方是谁。
7. 把集成问题下溯到实现层：外部 crate 集成时关注 trait bound 与泛型（m04-zero-cost）及错误类型兼容性（m06-error-handling）；FFI 集成时关注安全要求（unsafe-checker）与资源清理（m12-lifecycle）。
8. 语言互操作按场景选工具：C/C++ → Rust 用 bindgen 自动生成绑定；Rust → C 用 cbindgen 导出 C 头文件；Python ↔ Rust 用 pyo3 写扩展；Node.js ↔ Rust 用 napi-rs 写 addon；WebAssembly 用 wasm-bindgen（浏览器/WASI）。
9. Cargo feature 用法：[features] 定义可选功能；default = [...] 指定默认特性；feature = "serde" 条件依赖；[workspace] 组织多 crate 项目。
10. 按错误码修复：E0433 找不到 crate → 加入 Cargo.toml；E0603 私有项 → 查 crate 文档；feature 未启用 → 在 features 中启用；版本冲突 → cargo update 或固定版本；类型重复 → 在 workspace 中统一版本。
11. 按五条标准筛选 crate：维护（最近有提交为好，多年不活跃为警告）、社区（issue/PR 活跃为好，无响应为警告）、文档（有示例和 API 文档为好，文档稀少为警告）、稳定性（遵循语义化版本为好，频繁破坏性变更为警告）、依赖（少而知名为好，庞大且冷门为警告）。
12. 避免反模式：不要用 extern crate（2018+ 已过时，直接用 use）；不要用 #[macro_use]（污染全局，改为显式导入）；不要用通配符依赖 `*`（不可预测，改用具体版本）；不要堆砌过多依赖（供应链风险，评估必要性）；不要 vendoring 一切（维护负担，信任 crates.io）。
13. 相关延伸：错误类型设计看 m06-error-handling，trait 集成看 m04-zero-cost，FFI 安全看 unsafe-checker，资源管理看 m12-lifecycle。

适用边界 · 注意事项

• 非 Rust/Cargo 项目，或目标平台没有成熟 crate 生态时，本文的 crate 选型表不适用。
• 需要严格审计供应链、禁止外部依赖的场景，不宜直接按流行度引入 crates.io 依赖。