## 资源泄露（High）

### 触发信号

- 文件/网络/数据库连接操作（`open`、`connect`、`createConnection`、`createWriteStream`）
- try-catch 中创建资源但无 finally/using/defer 释放
- 未停止的 goroutine（`go func()` 中有阻塞操作但无退出机制）
- 未 join 的线程（线程 detach 或未等待完成）
- HTTP 请求的 Response Body 未关闭（`res.body` 未 `consume`/`close`）

### 判定流程

1. **识别资源创建点**：`Read` 提取所有资源创建操作（`open`/`connect`/`createConnection`/`createReadStream`），标记资源变量
2. **检查释放路径**：对每个资源变量，`Read` 检查所有退出路径（return、throw、break）是否都有对应释放：
   - 正常路径：是否有 `close`/`end`/`release`/`dispose`
   - 异常路径（catch）：资源是否在 finally 块或 using 语句中释放
   - 早返回（early return）：是否泄漏
3. **检查语言惯用释放模式**：
   - Python：是否使用 `with` 语句或 `contextlib`
   - Go：是否使用 `defer close()`
   - Java：是否使用 try-with-resources
   - C++：是否使用 RAII
   - Node.js：stream 是否 pipe 到正确目标或显式 destroy
4. **检查 goroutine/线程泄露**：
   - Go：`Read` 检查 `go func()` 是否有退出机制（context cancellation、channel done 信号）
   - Java：`Read` 检查线程池是否有关闭逻辑（`shutdown`/`awaitTermination`）
5. **检查 HTTP Response Body**：`Read` 确认 HTTP 响应体是否被完全消费或显式关闭（Node.js `res.body.pipe(devNull)`、Go `io.Copy(io.Discard, res.Body)`）

### 证据构造

确认缺陷后，输出需包含：
- 资源创建点（资源类型和创建位置，含文件:行号）
- 缺失释放的路径（哪条退出路径遗漏了释放）
- 业务影响（连接池耗尽、文件句柄耗尽、goroutine 泄露导致 CPU 飙升）

### 排除

- 已使用语言惯用释放模式（Python with、Go defer、Java try-with-resources、C++ RAII）
- 连接池管理的资源（由池自动管理生命周期）
- 框架管理的资源（Express 中间件、Spring Bean 生命周期）
- 一次性程序/脚本（进程退出后 OS 回收）
