runtime.GC() 是同步阻塞的全局 STW 操作，仅应在明确长时间空闲且堆中存大量可回收对象时谨慎使用，盲目调用会加剧延迟并干扰自适应 GC 机制。
runtime.GC() 是同步阻塞的，别在热路径里调用
runtime.GC() 会强制启动一次完整的、全局 STW（Stop-The-World）垃圾回收周期。它不是“建议 GC”或“触发后台回收”，而是等价于暂停所有 goroutine，直到本次 GC 完全结束。这意味着：
- 在高并发 HTTP handler 或循环处理逻辑中直接调用 runtime.GC()，会导致请求延迟陡增，甚至超时；
- 即使内存看起来“刚释放完”，也不代表立刻需要手动 GC —— Go 的 GC 是自适应的，会根据堆增长速率和 GOGC 设置自动调度；
- 真实场景中，只有在极少数明确知道“接下来有一段长时间空闲，且当前堆中有大量可回收对象”时才考虑它，比如 CLI 工具完成批量任务后准备退出前。
调用前先确认是否真有必要：看 pprof 和 GODEBUG=gctrace=1
盲目调用 runtime.GC() 不仅无效，还可能干扰 GC 的预测模型。验证必要性的方法包括：
- 启动时加 GODEBUG=gctrace=1，观察 GC 日志里 gc #N @X.Xs X%: ... 中的堆大小变化和触发间隔；
- 用 pprof 抓取 /debug/pprof/heap，对比调用前后 inuse_space 和 allocs 是否存在明显滞留；
- 检查 runtime.ReadMemStats(&m) 中的 m.Alloc 和 m.TotalAlloc 差值，若长期不下降，再排查是否有意外引用（如闭包捕获、全局 map 未清理、timer/worker 未 stop）；
- 大多数所谓“内存没释放”问题，根源是对象仍被强引用，而不是 GC 没跑。
如果真要调用，务必配合 runtime.GC() 后的 memstats 检查
单纯调用 runtime.GC() 并不能保证你看到“内存立刻下降”。因为：
- Go 的内存分配器（mheap）不会立即将归还的页交还给操作系统（尤其在 Linux 上，默认延迟归还）；
- runtime.ReadMemStats() 中的 HeapReleased 字段才反映真正归还 OS 的字节数，而 HeapInuse 只表示 heap 区域内已分配的内存；
- 若需主动提示 OS 回收，可紧接 runtime.GC() 后调用 debug.FreeOSMemory()（注意：该函数在 Go 1.22+ 已弃用，推荐改用 debug.SetGCPercent(-1) + runtime.GC() + debug.SetGCPercent(old) 组合控制）；
- 示例检查逻辑：
var m runtime.MemStats
runtime.GC()
runtime.ReadMemStats(&m)
fmt.Printf("HeapInuse: %v, HeapReleased: %v\n", m.HeapInuse, m.HeapReleased)
替代方案比手动 GC 更可靠：GOGC、SetGCPercent 和对象复用
与其依赖 runtime.GC()，不如从源头降低 GC 压力：
- 将 GOGC=20（默认 100）设为更低值，让 GC 更早更频繁运行，避免单次 STW 过长；
- 对高频小对象（如 JSON 解析中的 map[string]interface{}），改用 sync.Pool 复用结构体指针；
- 避免在闭包中无意捕获大对象（例如 handler 里引用整个 *http.Request）；
- 使用 unsafe.Slice 或预分配切片代替反复 make([]byte, n)；
- 对大数据处理流程，显式用 slice = slice[:0] 清空并复用底层数组，而非重新 make。
真正难的从来不是“怎么触发 gc”，而是判断“为什么 gc 没按预期工作”——那通常指向引用泄漏、缓存未失效、或对 go 内存模型的误读。手动 gc 是止痛片，不是退烧药。
