Cursor对Go内存问题“半懂不懂”：能静态识别make([]byte, n)等高风险写法，但无法动态检测goroutine泄漏或GC暂停，需人工喂入pprof数据和版本信息才能精准辅助。
Cursor 不能直接检测 Go 的 runtime 内存溢出，但它能基于静态模式识别高风险写法，并给出符合 pprof 和 go tool trace 分析习惯的修复建议。 它不运行程序，也不接入 runtime.ReadMemStats，所以别指望它报出“goroutine 泄漏了 2000 个”这种动态结论——但对 make([]byte, n)、bytes.Buffer.Grow、未限制的 http.Request.Body 读取等典型隐患，它反应很准。
为什么 Cursor 对 Go 内存问题“半懂不懂”
Go 的内存问题分两类：一类是编译期可推断的（如无界切片预分配、channel 缓冲区失控），另一类必须靠运行时采样（如 goroutine 堆积、map 不释放）。Cursor 的模型训练数据里有大量 Go 开源项目，所以对前者识别率高；但后者依赖 pprof 的堆快照或 trace 的调度事件，它没能力实时拉取这些数据流。你让它“看代码”，它能指出 buf := make([]byte, 1024*1024*100) 很危险；你让它“看 pprof 报告”，它就只能猜。
- 它不会自动启动
go tool pprof http://localhost:6060/debug/pprof/heap - 它不解析
runtime.MemStats字段含义，比如分不清Alloc和TotalAlloc的业务意义 - 它无法感知 GC pause 时间突增——这需要
go tool trace的事件时间轴
怎么让 Cursor 真正帮上忙：三步喂数据
关键不是问“帮我修内存泄漏”，而是把上下文塞给它。实际有效的方式是：
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
- 选中整段有问题的 handler 函数，右键 → Ask Cursor → 输入：“这段代码在并发请求下可能触发 OOM，
body, _ := io.ReadAll(r.Body)没做长度限制，请改用带 size check 的读取方式，并返回 413” - 把本地
pprof的 topN 分配栈截图转成文字（比如 “bytes.makeSlice占 78%”），粘贴进聊天框，再问：“这个调用链说明什么？怎么改？” - 在项目根目录放一个
.cursorrules，明确写：“所有 HTTP handler 必须校验r.ContentLength，超过 10MB 直接返回http.StatusRequestEntityTooLarge”
常见误判和绕过方法
Cursor 会把一些安全写法误标为风险，比如：
-
var buf [4096]byte—— 它可能警告“栈空间过大”，其实这是标准做法，应加注释// stack-allocated, safe for small buffers并告诉 Cursor 忽略该行 -
sync.Pool的 Get/Put 配对 —— 它常漏掉 Put 调用，但实际代码里写了，这时要手动补一句：“此 Pool 已在 defer 中 Put，无需修改” - 用
strings.Builder替代fmt.Sprintf—— 它有时推荐错对象，比如对短字符串反而建议用fmt，此时应强调场景：“字符串长度稳定在 200 字节内，Builder 无收益”
最易被忽略的是：Cursor 的建议默认不考虑你的 Go 版本。Go 1.22 引入了 io.LimitReader 更简洁的限长方式，但如果你还在用 Go 1.19，它可能推荐不存在的 API。务必在提问时带上 go version go1.19.13 darwin/arm64 这类信息。
