企业官网建设流程全解析

`beweb` 项目 。以下是 为你的 Go 项目进行内存泄漏检查的完整方案。

---

## 🔍 beweb 内存泄漏检查方案

### 1. 项目现状分析

好消息是，你的项目**已经启用了 pprof**，在 [webset.go](file:///E:\soft\gotrain\beweb\webset\webset.go#L391) 中已经注册了：

```go
root.Any("/debug/pprof/*any", gin.WrapH(http.DefaultServeMux))
```

同时也已经导入了 `_ "net/http/pprof"`（第5行）。

---

### 2. 使用 pprof 分析内存泄漏

#### 2.1 获取堆内存快照（Heap Profile）

**方法一：直接通过 HTTP 端点获取**

```bash
# 获取当前堆内存快照
curl -o heap.prof http://localhost:你的端口/debug/pprof/heap

# 获取 goroutine 快照（排查 goroutine 泄漏）
curl -o goroutine.prof http://localhost:你的端口/debug/pprof/goroutine
```

**方法二：使用 go tool pprof 交互式分析**

```bash
# 直接分析线上服务的内存
go tool pprof http://localhost:你的端口/debug/pprof/heap

# 或者先下载再分析
go tool pprof heap.prof
```

进入交互模式后，常用命令：

```
(pprof) top20 # 查看内存占用 Top 20
(pprof) list 函数名 # 查看具体函数的内存分配
(pprof) web # 生成调用图（需要 graphviz）
(pprof) png # 生成 PNG 图片
(pprof) traces # 查看内存分配调用栈
```

#### 2.2 对比两次快照（增量分析）

这是最有效的排查方式：

```bash
# 第一次采集（基线）
curl -o heap1.prof http://localhost:你的端口/debug/pprof/heap

# 等待一段时间，或模拟一些业务操作后再采集
curl -o heap2.prof http://localhost:你的端口/debug/pprof/heap

# 对比差异：base 是基线
go tool pprof -base=heap1.prof heap2.prof
```

---

### 3. 排查 Goroutine 泄漏（最常见的内存泄漏原因）

goroutine 泄漏是 Go 中最常见的内存泄漏来源。你的项目中有几个关键区域需要关注：

#### 3.1 WebSocket 服务检查

在 [websocket.go](file:///E:\soft\gotrain\beapi\trainframe\service\servicews\websocket.go) 中，`HandleConnection` 函数会启动一个 `subscribeToRedis` goroutine（第131行）：

```go
go w.subscribeToRedis(channelId, ctx, conn, pingCh)
```

**检查点：**
- `subscribeToRedis` 函数在 `ctx.Done()`、`sigChan`、Redis 通道关闭、写入错误时都会 `return`，清理逻辑相对完善
- 但需要注意：如果 `conn.ReadMessage()` 阻塞且连接未正常关闭，goroutine 可能不会被及时清理

```bash
# 获取 goroutine 快照，查看是否有大量阻塞的 goroutine
curl -o goroutine.prof http://localhost:你的端口/debug/pprof/goroutine
go tool pprof goroutine.prof
```

#### 3.2 Redis 队列消费者

在 [redisQueue.go](file:///E:\soft\gotrain\beapi\trainframe\traindomain\consumer\redisQueue.go#L42-L44) 中：

```go
func (q *RedisQueue) Run() {
...
go q.run() // 启动一个 goroutine
}
```

**检查点：**
- `BRPop` 是阻塞调用，正常只有一个 goroutine 在运行
- 确认 `Run()` 不会被重复调用

#### 3.3 Cron 定时任务

在 [cronjob.go](file:///E:\soft\gotrain\beapi\cronjob\crontask\cronjob.go) 中使用了 `robfig/cron`，需要确保定时任务中的资源正确释放。

---

### 4. 针对你项目的具体内存泄漏风险点

基于代码审查，以下是我发现的**潜在风险点**：

#### ⚠️ 风险点 1：全局 `connections` map

在 [websocket.go](file:///E:\soft\gotrain\beapi\trainframe\service\servicews\websocket.go#L50-L51)：

```go
var connections = make(map[string]map[*websocket.Conn]struct{})
var connLock sync.Mutex
```

虽然有 `defer` 清理逻辑（第118行），但如果连接异常断开（如网络中断）导致 `ReadMessage` 返回错误但 `defer` 未正确执行，连接可能残留在 map 中。建议：

```go
// 定期清理死连接
func (w *webSocketService) cleanDeadConnections() {
connLock.Lock()
defer connLock.Unlock()
for chId, conns := range connections {
for conn := range conns {
if err := conn.WriteMessage(websocket.PingMessage, nil); err != nil {
delete(conns, conn)
}
}
if len(conns) == 0 {
delete(connections, chId)
}
}
}
```

#### ⚠️ 风险点 2：`subscribeToRedis` 中的信号通道

在 [websocket.go](file:///E:\soft\gotrain\beapi\trainframe\service\servicews\websocket.go#L195)：

```go
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
```

每个 WebSocket 连接都会创建一个 `sigChan`，但 `signal.Notify` 会将信号发送到所有注册的通道。虽然 Go 会处理，但建议使用全局信号通道，避免每个连接都注册。

---

### 5. 完整的检查脚本

你可以创建一个内存泄漏检查脚本 `check_memory.sh`：

```bash
#!/bin/bash

# beweb 内存泄漏检查脚本
HOST="localhost:你的端口"
OUTPUT_DIR="./mem_profiles"
mkdir -p $OUTPUT_DIR

echo "=== 1. 获取基线堆内存快照 ==="
curl -s -o $OUTPUT_DIR/heap_base.prof http://$HOST/debug/pprof/heap
echo "基线快照已保存"

echo "=== 2. 获取 goroutine 快照 ==="
curl -s -o $OUTPUT_DIR/goroutine_base.prof http://$HOST/debug/pprof/goroutine
echo "Goroutine 快照已保存"

echo "=== 3. 获取内存统计信息 ==="
curl -s http://$HOST/debug/pprof/heap?debug=1 > $OUTPUT_DIR/heap_stats.txt
echo "内存统计已保存"

echo "=== 4. 等待 30 秒后进行第二次采集 ==="
sleep 30

curl -s -o $OUTPUT_DIR/heap_after.prof http://$HOST/debug/pprof/heap
curl -s -o $OUTPUT_DIR/goroutine_after.prof http://$HOST/debug/pprof/goroutine

echo "=== 5. 对比分析 ==="
echo "--- 堆内存增量分析 ---"
go tool pprof -top -base=$OUTPUT_DIR/heap_base.prof $OUTPUT_DIR/heap_after.prof

echo "--- Goroutine 增量分析 ---"
go tool pprof -top -base=$OUTPUT_DIR/goroutine_base.prof $OUTPUT_DIR/goroutine_after.prof

echo "=== 分析完成 ==="
```

Windows 版本 (`check_memory.bat`)：

```bat
@echo off
set HOST=localhost:你的端口
set OUTPUT_DIR=.\mem_profiles
mkdir %OUTPUT_DIR% 2>nul

echo === 1. 获取基线堆内存快照 ===
curl -s -o %OUTPUT_DIR%\heap_base.prof http://%HOST%/debug/pprof/heap
echo 基线快照已保存

echo === 2. 获取 goroutine 快照 ===
curl -s -o %OUTPUT_DIR%\goroutine_base.prof http://%HOST%/debug/pprof/goroutine
echo Goroutine 快照已保存

echo === 3. 等待 30 秒后进行第二次采集 ===
timeout /t 30 /nobreak

curl -s -o %OUTPUT_DIR%\heap_after.prof http://%HOST%/debug/pprof/heap
curl -s -o %OUTPUT_DIR%\goroutine_after.prof http://%HOST%/debug/pprof/goroutine

echo === 4. 对比分析 ===
echo --- 堆内存增量分析 ---
go tool pprof -top -base=%OUTPUT_DIR%\heap_base.prof %OUTPUT_DIR%\heap_after.prof

echo --- 分析完成 ---
pause
```

---

### 6. 启用 GC 追踪日志

在启动时添加环境变量，观察 GC 行为：

```bash
# Windows
set GODEBUG=gctrace=1
beweb.exe

# 或通过环境变量
$env:GODEBUG="gctrace=1"
```

GC 日志会显示每次 GC 后的内存使用情况，如果内存持续增长不回落，就说明存在泄漏。

---

### 7. 使用 Prometheus 监控（已集成）

你的项目已经集成了 Prometheus（`/metrics` 端点），可以添加以下指标来监控内存：

```go
// 在 Prometheus 中关注这些关键指标
go_memstats_heap_alloc_bytes // 堆内存分配
go_memstats_heap_inuse_bytes // 堆内存使用中
go_goroutines // goroutine 数量
go_memstats_gc_cpu_fraction // GC 占用 CPU 比例
```

---

### 8. 总结建议

| 检查项 | 方法 | 优先级 |
|--------|------|--------|
| **Goroutine 泄漏** | `go tool pprof /debug/pprof/goroutine` | 🔴 最高 |
| **堆内存增长** | 对比两次 heap profile | 🔴 最高 |
| **WebSocket 连接泄漏** | 检查 `connections` map 大小 | 🟡 高 |
| **Redis 连接泄漏** | 检查 Redis 连接池使用情况 | 🟡 高 |
| **定时任务资源** | 检查 cron job 是否有资源未释放 | 🟢 中 |

要开始检查，你只需要：
1. 启动 beweb 服务
2. 访问 `http://localhost:你的端口/debug/pprof/` 查看所有可用的 profile 端点
3. 使用上述脚本采集两次快照进行对比分析

需要我帮你针对某个具体模块做更深入的内存泄漏分析吗？