在敏捷开发的快速迭代中，Rust 正被越来越多团队用于构建高性能、高可靠的系统。其所有权模型、零成本抽象和出色的并发安全承诺，理论上能大幅减少线上崩溃。然而，实际代码评审（Code Review）时，我们常发现许多因不熟悉 Rust 独特范式而埋下的隐患。评审者容易被复杂的生命周期标注或宏展开绕晕，导致评审流于形式。本文梳理了敏捷 Rust 项目中代码评审最常见的 7 个陷阱，并给出可操作的评审对策，让团队既保持速度，又不牺牲质量。
陷阱一：无条件信任 unwrap() 与 expect()
在原型阶段，开发者习惯用 unwrap() 或 expect() 快速处理 Option 和 Result。进入评审时，这些调用像一颗颗定时炸弹。敏捷冲刺的压力下，经验不足的成员会直接合并带有大量 unwrap() 的代码，导致生产环境一旦遇到 None 就 panic，且缺少上下文信息。
评审对策： 要求对每个 unwrap() 作出解释：是否已通过前置逻辑确保不会为 None/Err？若无法保证，必须替换为适当的错误处理，如早期返回 Result、使用 ? 操作符传播错误，或至少用 expect() 附带清晰的错误消息。同时启用 clippy 的 unwraps_used lint，将滥用 unwrap 视为构建失败。
陷阱二：错误类型粗糙，丢失上下文
敏捷开发中，快速串联逻辑时常出现“随便包一层 Box”或无数个 .map_err(|e| anyhow!(e))。虽然方便，但抹杀了错误的可区分性，上游调用者无法根据错误类型做出不同决策。评审者若只关注逻辑，会纵容这种“错误信息黑洞”。
评审对策： 审视自定义错误类型的粒度。对于库代码，要求定义明确的错误枚举并实现 std::error::Error。对于应用代码，可接受 anyhow 作为顶层错误，但关键分支仍建议保留类型信息。关注错误转换时是否附加了足够上下文，比如文件路径、导致错误的具体操作，而非仅仅转抛底层错误。
陷阱三：unsafe 块未充分说明与审查
Rust 的 unsafe 代码绕过了借用检查器，但必须由人肉保证内存安全。敏捷评审中，unsafe 块有时会被“功能能用就好”的心态忽视，甚至缺少安全注释（Safety comment）解释为何认为该块是安全的。
评审对策： 任何引入 unsafe 的 PR 必须标记为高优先级评审，并要求在 unsafe 块前用 // SAFETY: 注释逐条说明不变量（invariants）以及如何通过外部代码保证。评审者应严格验证这些不变量是否在其他地方被破坏。对于不必要的 unsafe，如调用已封装安全的 FFI 接口，应坚决要求改为安全封装。可使用 #![forbid(unsafe_code)] 在模块级别限制 unsafe 范围。
陷阱四：所有权误解导致的“克隆万能”
为快速解决借用冲突，开发者常常下意识地调用 .clone() 或使用 Arc 到处共享。这在敏捷前期能跑通，但随着数据结构变大或并发度升高，不必要的克隆和锁竞争会成为性能梦魇，且掩盖了真正需要优化所有权设计的问题。
评审对策： 对每个 .clone() 提出疑问：是否可通过借用、切片或重整数据布局来避免？检查 Arc 和 Rc 的使用场景，确认是否真的存在共享所有权的需求，还是因为生命周期设计混乱而采取的权宜之计。对于内部可变性，优先考虑 RefCell 是否比 Mutex 更合适。评审时结合 perf 工具指出潜在热点，用数据驱动优化。
陷阱五：异步代码中的阻塞调用
在 tokio 等异步运行时中，任何阻塞操作（如标准库 std::thread::sleep、同步 I/O 或长计算）都会阻塞整个线程，导致其他任务饥饿。敏捷开发中，快速集成第三方库时极易忽略某个同步函数调用，而代码评审往往只检查业务正确性，不深究异步调度。
评审对策： 明确要求所有异步上下文中的耗时操作必须使用异步替代方案（如 tokio::time::sleep、异步文件读写）。对于 CPU 密集型任务，应使用 tokio::task::spawn_blocking 并将其视为特殊点打上注释。可配置 clippy 的 async_yields_async 相关 lint，并在 CI 中加入 cargo check --tests 保持警惕。评审时关注函数签名是否为 async fn，内部却调用了非异步的阻塞 API。
陷阱六：宏与过程宏的滥用
敏捷迭代中，为减少样板代码，团队可能大量使用宏，甚至引入复杂的过程宏。这导致重构困难、错误信息难以理解、IDE 支持下降。评审者若仅检查宏的最终展开效果，会忽视宏本身的健壮性、卫生性和可调试性。
评审对策： 对非必须的宏提出质疑：是否存在更简单的 trait 或泛型方案？对于必须的宏，要求提供简单的单元测试覆盖宏生成的代码路径，并使用 cargo expand 查看展开结果。避免编写过于“聪明”的宏，限制其仅用于减少明显的重复，而非创造新的 DSL。复杂的宏应当要求设计文档。
陷阱七：忽视 Rust 的惯例与自动化质量门禁
Rust 社区沉淀了大量最佳实践，如遵循 API 命名规范、使用 From/Into 转换、避免在公共 API 暴露内部类型等。快速交付时，这些惯例很容易被忽略，导致代码库风格割裂，新人上手成本增高。评审全靠人工提醒，消耗大量精力。
评审对策： 将所有机械性检查前移至 CI 流水线。强制配置 cargo fmt --check、cargo clippy -- -D warnings、cargo deny check（许可证与安全漏洞）。使用 rustfmt.toml 和 clippy.toml 统一团队规范。评审时聚焦架构、所有权设计、业务正确性，而非格式和命名。同时定期运行 cargo outdated 和 cargo audit，保持依赖健康。
总结：让评审成为 Rust 敏捷的加速器
Rust 的强大来自编译器的严格，但这不意味着代码评审可以走过场。在敏捷开发中，应当将上述陷阱转化为团队的“评审检查清单”，用自动化工具屏蔽低层次问题，让人力专注于设计意图和安全边界。每发现一个坑，都可以沉淀为一条 clippy lint 或一段示例代码，形成持续改进的回路。如此，Rust 代码评审不仅能“避坑”，更能成为团队集体学习 Rust 设计理念、提升整体工程素养的绝佳场所。