rust-code-review

Rust 代码审查

审查实际差异及其调用方，而不是孤立代码片段或通用检查清单。优先关注可能改变行为、违反不变量、暴露数据、造成死锁、意外触发 panic 或破坏公共 API 的缺陷。

范围与路由

使用此技能审查：

• 所有权、借用、生命周期和 drop 行为；
• unsafe 前置条件及安全包装器的健全性；
• 错误传播、panic 路径、部分更新和回滚；
• 并发、取消、锁顺序和任务生命周期；
• 公共 API、semver、功能、目标平台和 MSRV 兼容性；
• 分配、克隆、阻塞、序列化和热路径开销；
• 测试、文档、依赖项和运维故障路径。

将格式和 lint 配置相关问题交由 rust-style-clippy 处理，将深入的 unsafe 或 ABI 分析交由 rust-unsafe-ffi 处理，将并发设计交由 rust-concurrency 处理，将依赖解析交由 rust-cargo-build 处理，将测试实现交由 rust-testing 处理，将 API 形态决策（trait 封闭、newtype 设计、错误分类、构建器模式）交由 rust-api-design 处理。

工作流程

1. 明确审查约定

检查仓库说明、变更文件、相关符号、调用方、测试、清单、锁文件、声明的 MSRV、启用的功能和支持的目标平台。确定此次变更是否影响私有实现、公共库 API、持久化数据、线格式、数据库架构或安全边界。

使用最精简的相关命令：

git diff --check
cargo metadata --format-version 1
cargo check --workspace --all-targets --all-features
cargo test --workspace --all-targets --all-features
cargo clippy --workspace --all-targets --all-features -- -D warnings

除非确实运行过命令，否则不要声称命令已通过。不要将成功编译视为行为正确的证明。

2. 沿边界追踪行为

针对每条变更路径，追踪输入、状态转换、副作用、错误、清理和可观察输出。检查：

• 引用的生命周期是否超出其所有者或守卫的生命周期；
• 移动、克隆或分配是否改变开销或语义；
• Option 和 Result 是否保留缺失和失败信息；
• 资源是否会在提前返回、取消、panic 和关闭时释放；
• 事务和多步变更是否能在必要时保持原子性；
• 重试次数是否有上限，且操作是否适合重试；
• 日志、Debug 输出、指标或错误是否暴露机密信息。

3. 审查 Rust 特有风险

Unsafe 和 FFI

• 每个 unsafe API 和实现都必须有文档说明其安全不变量。
• 将 unsafe 代码块限制在最小范围，并显式启用 unsafe_op_in_unsafe_fn。
• 验证指针来源、有效性、对齐、初始化、别名、布局、展开、所有权转移和释放对称性。
• 将手动实现 Send 或 Sync 视为 unsafe 合约，而不是标记样板代码。

并发

• 检查锁顺序，以及守卫是否跨越 .await、回调、阻塞 I/O 或用户代码。
• 要求队列有界，并明确过载处理、取消所有权、任务监管和确定性关闭机制。
• 区分 I/O 并发与 CPU 并行；增加任务或工作线程并不一定能解决性能问题。

错误处理

• 如果用户输入或外部输入可能触发 unwrap、expect、索引、断言、整数溢出假设和不可达分支，则应标记这些问题。
• 保留结构化库错误；在应用边界添加上下文，同时避免泄露内部信息。
• 验证清理或回滚失败是否被悄然忽略。

API 和兼容性

• 检查可见性、trait 边界、自动 trait、对象安全、#[non_exhaustive]、功能组合、特定目标平台的代码和 MSRV。
• 将生成的方法、序列化结构、错误变体和公共功能名称视为 API 表面。
• 对持久化或传输格式的变更，要求提供明确的迁移方案。

3a. API 指南审查视角

对于每个发生变更的公共项，对照 Rust API 指南清单的四个章节检查差异。提出问题前，先用具体的调用方确认每个匹配项，并将设计层面的修复交由 rust-api-design 处理。各章节的完整表格、严重性等级和建议评论见 API 指南清单。

• 可靠性 — 在接受调用方输入的公共方法中，标记 panic!、unwrap、expect、unreachable!、切片索引和 transmute（C-PANIC、C-UNWRAP、C-TRANSMUTE）。
• 类型安全 — 标记接受多个 bool 参数的函数，或使用可互换的原始类型、而枚举或新类型可以避免参数顺序错误的函数（C-BOOL、C-NEWTYPE）。
• 互操作性 — 标记缺少 Debug/Clone/PartialEq 的公共类型，以及对非智能指针类型实现 Deref 以借用方法的情况（C-COMMON-TRAITS、C-CONVERT）。
• 面向未来 — 标记未封闭的可扩展公共 trait，以及未添加 #[non_exhaustive] 的库错误或配置枚举（C-SEALED、C-NON-EXHAUSTIVE）。

不要标记 #[cfg(test)] 模块中的 unwrap/expect、带有已记录不变量的 FFI 适配层中符合惯用写法且不会失败的 unsafe，或用于单一目的的 bool setter；请参阅清单中的误报列表。

4. 以证据审查性能

只有当分配、克隆、锁或算法可能对变更路径产生实质影响时，才将其报告为性能问题。优先采用测量结果，而非审美层面的改写。检查异步执行器上的阻塞工作、意外的二次复杂度行为、重复解析、过大的枚举变体、不必要的缓冲以及无界增长。

5. 验证测试和文档

要求在可观察到回归的边界处进行测试。覆盖成功、无效输入、部分进展后的失败、取消、并发、功能和平台变体，以及公共示例。确保文档记录了公共安全要求、错误、panic 和兼容性约束，并且 doctest 仍可执行。

选择其他分析工具时，请阅读 审查工具和清单。了解预期的问题格式，请阅读 审查场景。将 C-PANIC / C-UNWRAP / C-TRANSMUTE / C-BOOL / C-NEWTYPE / C-COMMON-TRAITS / C-CONVERT / C-SEALED / C-NON-EXHAUSTIVE 规则应用于公共 API 时，请阅读 API 指南清单。

问题格式

先返回问题，再给出任何摘要。每个问题必须包含：

1. 严重性和简洁的标题；
2. 尽可能精确的文件和行范围；
3. 具体的失败条件或调用方路径；
4. 对用户、安全、兼容性或运维的影响；
5. 最小修正方案，或能证明修复有效的测试。

不要将纯风格偏好作为正确性问题报告。如果没有剩余的可操作问题，请明确说明，并指出尚未完成的验证。

完成标准

• 审查差异、调用方、测试、清单，以及相关的功能或目标边界。
• 按严重性顺序报告可复现的问题，并标注精确的位置。
• 将已确认的缺陷与仍需证据支持的风险分开。
• 运行相关检查，或明确说明未运行的检查。
• 除非收到请求，否则不要擅自扩大变更范围或实施修复。

上游来源

• Rust API 指南
• Rust 风格指南
• Rustonomicon
• Clippy 文档
• RustSec 公告数据库

数据隐私

此技能不会收集、存储或传输用户数据。查询私有注册表或外部审查系统前，请先确认已获授权。