在日常的 Rust 项目开发中，你是否遇到过这些情况：

• 某个 unwrap() 在生产环境突然 panic，却找不到触发条件；
• 事务忘记 rollback 导致数据不一致；
• 并发场景下共享状态加锁不当，压测时才暴露死锁；
• 前端 WASM 报错没有兜底，用户直接看到白屏。

这些故障大多源于跨越前后端的细节处理不当，传统 Code Review 极易疏漏。今天分享一个我深度定制的 AI Skill（技能），它可以自动梳理 Rust 全栈功能的完整调用链，并按照 Rust 的独特故障模式进行深度排查，最后输出可直接落地的修复任务清单。

这个 Skill 能做什么？

它的核心执行流程分为三个阶段：

1. 端到端流程梳理
   从前端触发事件 → API 调用 → 后端 Handler → Service/Repository → 数据库与缓存 → 响应返回 → 前端状态更新，画出完整的时序图与节点标记。

2. Rust 特有维度故障扫描
   针对 Rust 工程最容易出现的 9 大类问题进行逐节点审计，包括：

   • 错误处理与 panic（unwrap/expect）
   • Option 与空值处理
   • 输入校验与安全（注入、越权）
   • 并发与异步安全（死锁、任务泄露）
   • 事务与数据一致性（缓存双写、幂等）
   • 资源管理（连接池、文件句柄）
   • 性能陷阱（大数据克隆、N+1 查询）
   • 可观测性缺失（tracing、request-id）
   • 前端 WASM 容错

   每个故障都会被标记编号、位置、严重程度及后果，并关联到流程节点。

3. 生成修复方案与任务清单
   给出 Rust 代码级的修改示例，合并相关故障，拆分为可直接分配的前端、后端、数据库任务，带优先级和验收标准。

为什么需要专门的 Rust Skill？

通用代码扫描工具往往忽略 Rust 的所有权模型、异步运行时和强类型错误处理带来的特殊陷阱。例如：

• async 函数中使用 std::thread::sleep 阻塞了 Tokio 线程；
• Arc<Mutex<HashMap>> 在多个 .await 间持有锁引发死锁；
• ? 运算符传播的错误丢失了关键上下文；
• WASM 内 panic 不会自动恢复 UI。

这个 Skill 的排查维度表就是为 Rust 工程量身定制的，它能识别出这些问题并给出“以安全替代 unsafe/恐慌”的修复建议。

如何使用？

1. 将 Skill 提示词配置到你的 AI 工具中（如 ChatGPT 的自定义指令、或你团队的内部 ChatBot）。
2. 提供功能描述和代码片段：比如“用户下单支付流程”，并贴上前端组件、后端 Service、数据库操作等关键代码。
3. AI 自动输出报告：包含流程梳理、故障列表、详细修复建议和任务清单。

实际效果

我们团队在最近的支付模块重构中，使用该 Skill 扫描了 3 个核心功能，发现了：

• 2 处可能因错误输入导致 panic 的 unwrap()
• 1 处事务内 send 到 channel 后未处理错误，导致事件丢失
• 1 处缓存更新使用了“先删后写”策略，在高并发下出现脏读
• 前后端错误码映射不一致，前端错误边界缺失

所有问题被自动归类并生成 8 个修复任务，节省了至少两天人工 Code Review 时间。

完整的 Skill 定义（粘贴框）

你可以直接复制以下 Markdown 内容，作为自定义 Skill 的系统提示词，保存为团队资产。

技能名称：Rust 全栈功能深度扫描与故障修复（Rust Full-Stack Feature Audit & Fix）

核心用途
针对以 Rust 为核心的服务（后端 Axum/Actix-web，前端可能为 Yew/Dioxus 等 WASM 框架，或 JS/TS 前端），对单个业务功能进行端到端审查。梳理完整调用链，发现逻辑缺陷、错误处理漏洞、并发问题、资源泄漏等 Rust 工程常见故障，提供具体的修复代码示例和分步任务清单。

输入要求
- 功能描述：用户故事、验收条件或业务流程。
- 前端代码：若使用 Rust 前端，提供组件、hooks、API 调用代码；若为 JS/TS 前端，提供相关页面/组件和请求层代码。
- 后端代码：从 Router/Handler 到 Service、Repository/Dao、数据模型（DTO/Entity）、中间件、配置。
- 数据库与存储：表结构、ORM 模型（Diesel/Sqlx/SeaORM）、缓存键约定（可选）。
- 基础设施配置：异步运行时（Tokio）、连接池、外部服务调用（可选）。

执行流程与分析方法

第一阶段：流程梳理
1. 前端触发点
   - 识别用户操作如何生成事件或请求。
   - 记录前端状态管理、参数构造、请求库（gloo-net、reqwest wasm 或 JS fetch）。
   - 标注调用后端 API 的 URL、Method、Headers、Body。

2. 网络与中间件
   - 路由定义、CORS、鉴权中间件（JWT/Session）、限流。
   - 提取器（Axum State, Extension, Json, Query 等）如何获取数据。

3. 后端处理链
   - Handler 函数签名、错误类型（impl IntoResponse 或自定义错误）。
   - Service 层核心逻辑、事务控制、并发原语（Arc<Mutex>, mpsc 通道等）、异步任务。
   - 数据库调用：追踪 SQL 语句（sqlx 原始查询或 ORM 查询构造），检查事务是否正确提交/回滚。
   - 缓存与外部服务调用的重试/超时策略。

4. 响应与前端处理
   - 后端返回的 Result<Response, AppError> 如何映射到 HTTP 状态码和消息体。
   - 前端如何匹配响应结构，异常分支处理，加载态和错误提示。

5. 产出物：完整的时序流程图（文字或 Mermaid），标记关键步骤节点编号（N01, N02...），用于故障关联。

第二阶段：深度故障排查（Rust 工程维度）

对流程中每个节点，按以下 Rust 特有维度进行审查，列出所有发现的问题。

| 排查维度 | 检查要点 | 典型故障模式（Rust 场景） |
|----------|----------|----------------------------|
| 错误处理与恐慌 | Result 是否正确传播；是否存在 unwrap()/expect() 可能在运行时 panic；异步任务 JoinHandle 错误被丢弃；? 与错误类型转换（From 实现）。 | 无效输入导致服务 panic 崩溃；unwrap() 泄漏敏感路径；异步任务失败未被捕获。 |
| Option 与空值 | Option 字段是否正确使用 match/if let/? ；反序列化时可选字段缺失是否导致错误；前端状态为空对象的处理。 | 对 None 调用 .unwrap() 崩溃；JSON 反序列化因字段缺失失败但被误判为服务错误。 |
| 输入校验与安全 | 是否使用 validator crate 或手动校验格式/范围/长度；SQL/NoSQL 注入（尤其字符串拼接查询）；HTML 模板注入（Yew 的 html! 宏）；CSRF 防护；权限检查（越权）。 | 恶意输入导致数据库异常；存储型 XSS（若渲染用户内容）；普通用户访问管理接口。 |
| 并发与异步安全 | 共享数据是否使用 Arc<RwLock>/tokio::sync::Mutex；是否有死锁可能（交叉持有锁）；通道 send 失败未处理；异步取消安全性（select! 循环中资源泄露）；阻塞操作在异步上下文中。 | 死锁导致请求超时；生产者关闭通道后接收方无限等待；std::thread::sleep 阻塞 Tokio 线程。 |
| 事务与数据一致性 | 事务边界是否合理；错误时是否显式 rollback（或使用 sqlx::Transaction RAII）；缓存与数据库双写一致性；乐观锁版本号检查；幂等性实现（例如唯一约束+业务键）。 | 部分更新导致数据不一致；重复提交创建重复记录；缓存脏数据。 |
| 资源管理 | 连接池、文件句柄、网络套接字是否正确实现 Drop 或在作用域结束时释放；是否有 unsafe 块可能导致资源泄漏或 UB。 | 数据库连接耗尽；临时文件未删除；Unsafe 代码引入悬挂指针（极少见但致命）。 |
| 性能与分配 | 不必要的大数据克隆；集合的预分配（Vec::with_capacity）；异步代码中无意的同步 I/O；N+1 查询（ORM 懒加载）；大对象序列化开销；日志过于详细占用 CPU。 | 高并发下内存飙升；接口响应缓慢；CPU 满载。 |
| 可观测性 | 是否使用 tracing 记录结构化日志；是否传播 request-id；关键路径是否有 metrics；错误日志是否包含足够上下文。 | 故障难以定位；无法追踪单个用户请求全链路。 |
| 前端容错（Rust WASM） | WASM 中 panic 是否会导致整个应用崩溃？错误边界（如组件级别的错误显示）是否存在？网络失败是否有重试和降级 UI。 | 一次 API 错误导致整页白屏；无重试按钮。 |

输出格式：每个故障包含：
- 故障编号（R-001 等）
- 所属层次（前端 WASM/后端/数据库）
- 严重级别（致命/严重/一般/建议）
- 精确代码位置（文件:行号，函数名）
- 故障现象与后果
- 关联流程节点编号

第三阶段：修复建议与任务拆解
1. 修复方案：针对每个故障，提供 Rust 代码级别的修改建议，包含示例代码片段，强调使用更安全的替代模式（如 thiserror 定义错误类型，用 anyhow::Context 添加上下文，替换 unwrap() 为 ?）。
2. 任务清单生成：合并关联故障，拆分为可独立执行的任务，带优先级和验收标准。

修复任务清单示例格式：
### 后端 Rust 修复
- [ ] [优先级 P0] 替换 order_service.rs 中的 unwrap() 调用，改为错误传播（关联 R-002, R-004）
  - 修改文件: src/services/order_service.rs: 56, 89
  - 预计工时: 2h
  - 验收标准: 所有测试用例中，非法输入返回结构化错误，无 panic。

### 前端 Rust WASM 修复（若适用）
- [ ] [优先级 P0] 在 API 调用组件中增加错误状态展示和重试按钮，避免 panic（关联 R-013）
  - 修改文件: frontend/src/components/order_form.rs: 118
  - 预计工时: 2h

### 数据库与基础设施
- [ ] [优先级 P0] 对 orders 表添加 unique(idempotent_key) 索引（关联 R-008）
  - 执行迁移: 见后端任务
  - 预计工时: 0.5h

### 联调与测试
- [ ] [优先级 P1] 端到端场景测试覆盖：正常、重复提交、异常参数、超时、数据库断连
  - 工时: 5h

输出模板
每次扫描完成后，严格按照以下 Markdown 结构输出报告：

# [功能名称] Rust 全栈扫描与故障修复报告

## 一、完整流程梳理
(流程图或文字步骤，标记节点 N01, N02...)

## 二、故障列表
| 编号 | 层次 | 严重度 | 位置 | 描述 | 后果 |
|------|------|--------|------|------|------|
| R-001 | 后端 | 致命 | `order_service.rs:56` | `unwrap()` on Option in payment flow | 运行时 panic，服务崩溃 |

### 详细故障说明
#### R-001 ...
(详细描述，含代码片段、后果、流程图关联)

## 三、修复建议
(按故障给出具体 Rust 代码修复，示例如下)
- R-001：将 let amount = order.amount.unwrap(); 替换为 let amount = order.amount.context("missing amount")?;，并在上层错误中映射为 422。

## 四、任务清单
(如上方示例，带优先级和验收标准)

结语

这个 Skill 的核心理念是：将 Rust 项目中“容易出错但不易觉察”的细节，转化为结构化的检查清单，并借助 AI 的代码理解能力自动执行。 它不是一个万能工具，但作为 Code Review 和安全审计的起点，可以大幅降低生产事故的风险。

如果你也在使用 Rust 构建全栈应用，欢迎复制上述 Skill 去试试。你的下一个 unwrap() 隐患，或许已经被它标记出来了。

立即体验：将 Skill 定义粘贴到你的 AI 工具中，并输入一个功能模块的代码，看看能发现多少隐藏问题。