是协程泄漏：handler返回后协程数未回落，符合“单次请求后不下降”铁证；需提供三个时间点数值才能精准判断，仅一个数字无法排除初始化波动。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
用ChatGPT辅助排查Go协程泄漏，不是让它直接修bug，而是让它帮你快速识别泄漏特征、生成可验证的诊断代码、解读pprof堆栈、甚至补全缺失的context取消逻辑——关键在于提问要精准、输入要完整、验证要闭环。
第一步：用ChatGPT快速判断是不是真泄漏
把 runtime.NumGoroutine() 在三个时间点的日志截图或文本复制进去，明确告诉它：“这是空闲态、请求开始前、HTTP handler返回后的协程数，分别是62、148、148。请分析是否符合协程泄漏的典型特征。”
它会立刻指出：handler返回后数字没回落，符合“单次请求后不下降”这一铁证标准，排除初始化波动干扰。
注意：不要只给一个数字，【必须提供至少三个连续时间点的数值】，否则它只能泛泛而谈“可能有风险”。
立即学习“go语言免费学习笔记（深入）”；
第二步：喂给ChatGPT一段可疑代码，让它定位阻塞点
方法一：直接粘贴含 goroutine 启动的函数（如 leakyChannel()），并附上你 curl 到的 /debug/pprof/goroutine?debug=2 的部分堆栈（截取卡在 chan receive 或 select 的几行即可）。
方法二：如果你只看到堆栈里反复出现 io.ReadFull 或 http.(*persistConn).readLoop，就问：“这段堆栈显示 37 个 goroutine 卡在 io.ReadFull，调用链是 A → B → C → io.ReadFull，但 C 函数里没有 context 传入，怎么在不改 A/B 的前提下，让 C 支持超时退出？”
这一步它大概率会给出带 ctx.Done() 的 select 模板，并提醒你检查 defer cancel() 是否漏写——这个细节人容易忽略，但模型能稳定复现。
用于在用户想通过浏览器自动化与 Google Gemini 或 ChatGPT 交互时。触发短语包括“ask Gemini”“ask ChatGPT”“ask GPT”“让...”。
第三步：生成可运行的诊断脚本
第一步：创建 main.go，写入以下内容：
package main
import (
"log"
"net/http"
"runtime"
"time"
)
func main() {
go func() { log.Printf("goroutines@idle: %d", runtime.NumGoroutine()) }()
http.HandleFunc("/test", func(w http.ResponseWriter, r *http.Request) {
log.Printf("goroutines@start: %d", runtime.NumGoroutine())
time.Sleep(2 * time.Second)
log.Printf("goroutines@done: %d", runtime.NumGoroutine())
})
http.ListenAndServe(":6060", nil)
}
第二步：启动服务后，用 curl -X GET http://localhost:6060/test 触发一次请求。
第三步：翻看日志，确认 @start 和 @done 数值是否一致；若不一致，说明该 handler 内部存在未回收的 goroutine。
第四步：用ChatGPT补全修复代码
把泄漏函数原代码和 pprof 堆栈一起丢给它，明确指令：“请生成修复后的完整函数，要求：1. 所有 goroutine 必须接收 context.Context；2. 接收方使用 for range + select 检查 ctx.Done()；3. 发送方在完成时关闭 channel；4. 不引入新依赖。”
它输出的代码大概率能直接编译通过，且不会漏掉
如果它生成的代码里 channel 关闭位置在 for 循环内部，你要立刻重问：“关闭 channel 应该在 for 循环外，否则可能 panic，请重写。”
