go内存上涨主因是全局缓存无淘汰、闭包隐式逃逸、c堆未释放及http超时未设；需用lru库限容、避免大对象闭包捕获、defer c.free、配置read/writetimeout。
python web服务迁移到go后，内存不降反升、持续上涨甚至oom，不是gc没起作用，而是你没意识到go的内存生命周期和python根本不在同一套逻辑里。
全局变量缓存未设限导致内存无限膨胀
Python里靠dict或lru_cache做缓存很自然，但Go中map是无自动淘汰机制的裸容器。一旦写成全局var cache = make(map[string]*Item)且不加过期/容量控制，它就会永远驻留——GC不会回收“还被引用着”的对象，哪怕你再也没查过它。
- 高频请求下，每个新key都往里塞，6小时内可能涨到2GB+
- 用
sync.Map也不能解决容量失控问题，它只解决并发安全 - 正确做法：用
github.com/bluele/gcache或github.com/hashicorp/golang-lru，显式设置size和expiration - 更稳妥的生产方案：把缓存下沉到Redis，Go进程只做无状态转发
HTTP handler里闭包捕获大对象引发隐式逃逸
Python的闭包捕获是浅层引用，而Go中闭包若引用了栈上大结构体（比如含[]byte或struct{...}的上下文），整个结构体会被强制分配到堆上，且只要handler函数还活着，这块内存就无法被GC回收。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 典型错误：
http.HandleFunc("/api", func(w http.ResponseWriter, r *http.Request) { data := loadBigData(); handle(w, r, data) }) -
data在每次请求中都被新分配，并被闭包长期持有，直到该handler被卸载（实际永不卸载） - 修复方式：把
data提取到函数外，或改用http.HandlerFunc显式构造，确保每次请求都新建作用域 - 验证是否逃逸：
go build -gcflags="-m" main.go，看到... moved to heap就要警惕
CGO调用未配defer C.free造成C堆泄漏
Python调C扩展通常由封装层兜底（如numpy、cryptography），但Go里直接用C.malloc或调用C库返回指针时，必须手动释放——Go的GC完全不管理C堆内存。
- 常见于图像处理、音视频编解码、加密计算等场景
- 漏掉
defer C.free(unsafe.Pointer(ptr))，泄漏速度可达2GB/天 - 更安全的做法：封装成带
Close()方法的结构体，在defer中统一释放 - 上线前必做：
pprof看inuse_space曲线，若C堆占比超15%，基本可断定泄漏
最易被忽略的一点：Go的http.Server默认不设ReadTimeout和WriteTimeout，慢连接会一直占着goroutine和底层缓冲区，这些内存既不归GC管，也不会自动释放——它不像Python的WSGI服务器有worker timeout机制，得你自己填上。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
