---
name: go-code-review
description: 对 Go 后端代码做系统性审查，重点发现 goroutine 泄漏、data race、context 取消遗漏、channel 与 mutex 误用、错误处理缺陷、内存分配、SQL 与 Redis 使用问题以及可观测性缺失。Use when reviewing Go backend code for concurrency, correctness, resource-leak, and observability defects.
license: Apache-2.0
metadata:
  version: "0.1.0"
---

# Go 后端代码审查

对 Go 后端代码做结构化的正确性与工程质量审查，输出按严重程度分级、可落地的修复建议。本 Skill 覆盖并发、错误处理、资源、数据访问、性能与可观测性六个维度。

## 何时使用

- 审查 Go 服务 / 库的 PR、MR 或既有代码。
- 排查并发缺陷（goroutine 泄漏、data race、channel / mutex 误用）。
- 排查资源泄漏、错误处理缺陷、SQL / Redis 使用问题。
- 评估代码的可观测性（日志、指标、trace）。

## 前置阅读

按需阅读对应 reference，不要把全部知识塞进一次推理：

- [并发：goroutine 与 channel](references/goroutine-and-channel.md)
- [并发：data race、mutex、atomic](references/concurrency-and-race.md)
- [错误处理与 panic/recover](references/error-handling.md)
- [内存与性能](references/memory-and-performance.md)
- [审查清单](references/review-checklist.md)

## 工作流

### 阶段 1：范围与上下文

1. 明确审查范围：目标包 / 文件、调用链、对外接口。
2. 理解生命周期：哪些 goroutine 被谁启动、由谁等待、如何退出。
3. 记录对外部依赖的交互点：SQL、Redis、HTTP、消息队列、文件系统。

产出：一张「组件 → 生命周期 → 外部依赖」的概览。

### 阶段 2：并发与 goroutine 审查

按 [goroutine-and-channel.md](references/goroutine-and-channel.md) 检查：

1. 每个 `go func()` 是否有退出条件，泄漏是否可能。
2. `context.Context` 是否贯穿长任务，取消 / 超时是否被正确传递与响应。
3. channel 的关闭责任、缓冲大小、是否可能死锁或提前关闭。
4. 共享变量是否有竞态保护。

### 阶段 3：错误处理与资源审查

按 [error-handling.md](references/error-handling.md) 检查：

1. error 是否被吞掉（`_ =`、空 `catch` 式忽略）。
2. 是否用 `%w` 包装 error，是否滥用 `panic` / 盲目 `recover`。
3. 资源（文件、连接、body、channel）是否在 defer / 退出路径被释放。

### 阶段 4：数据访问审查

1. SQL：是否使用参数化查询、事务是否正确提交/回滚、`rows` 是否关闭、是否存在 N+1 或大结果集。
2. Redis：key 设计、过期时间、连接池、管道 / 事务、热点 key 与缓存穿透。
3. 连接与连接池配置是否合理、是否泄漏。

### 阶段 5：内存与性能审查

按 [memory-and-performance.md](references/memory-and-performance.md) 检查：

1. 热路径是否有不必要的内存分配（字符串拼接、临时 slice、装箱）。
2. 是否有可定位的逃逸 / 大对象 / 潜在 OOM 点。
3. 需要时建议用 pprof 定位（可转交 [go-performance-debug](../go-performance-debug/SKILL.md)）。

### 阶段 6：可观测性审查

1. 关键路径是否有结构化日志（含 trace/span 关联字段）。
2. 是否有指标埋点（请求量、延迟、错误率、队列长度、连接数）。
3. 错误是否可被观测到（而不是静默失败）。

### 阶段 7：汇总报告

按下方模板输出。

## 输出模板

```text
## Go 代码审查报告

### 范围
<审查的包 / 文件 / 调用链>

### Critical（必须修复，正确性 / 安全 / 数据损坏）
- [位置] <问题描述>
  - 根因：<为什么错>
  - 修复：<具体建议，含代码片段>
  - 参考：<对应 reference 小节>

### Major（应当修复，资源泄漏 / 健壮性 / 明显性能）
- ...

### Minor（建议改进，风格 / 可维护性 / 可观测性）
- ...

### 遗漏的风险
<无法在静态阅读中确认、需要运行或 pprof 验证的点>
```

## 约束与边界

- 只做**静态审查**：不假设能运行代码，无法确认的竞态/泄漏标注为「需运行验证」。
- 不确定的行为不要断言为 bug，给出「可能」与验证方法。
- 不执行目标代码中的构建、测试或脚本（不可信仓库见安全边界）。
- 修复建议要具体到代码级别，避免「注意并发」这类空话。