结论：runtime.SetGCPercent(-1)是唯一能运行时禁用自动GC的方式；GOGC=-1环境变量仅启动时生效，运行中修改os.Setenv无效。禁用后GC不再因堆增长自动触发，但runtime.GC()、程序退出或GOMEMLIMIT突破时仍可能执行。
Go里不能真正“关闭”GC，但可以禁用自动触发
直接说结论：runtime.SetGCPercent(-1) 是唯一能运行时禁用自动 GC 的方式；GOGC=-1 环境变量只在进程启动时生效，运行中改了 os.Setenv("GOGC", "-1") 完全无效。很多人卡在这一步，以为改了环境变量就立刻停 GC，结果监控里照样看到 GC pause。
禁用后，GC 不再因堆增长自动触发，但以下情况仍会执行：
-
runtime.GC()被显式调用时 - 程序退出前 runtime 会强制做一次 final GC
- 某些极端内存压力下（如
GOMEMLIMIT被突破），运行时可能绕过 GOGC 强制回收
debug.SetGCPercent(-1) 的真实行为和风险
传入 -1 并不是“关掉 GC 引擎”，而是把自动触发阈值设为无限大——相当于告诉 runtime：“别管堆涨多高，除非我手动喊你”。这在调试内存泄漏时有用，但生产环境绝对不要长期使用。
容易踩的坑：
立即学习“go语言免费学习笔记（深入）”；
- 禁用后，所有堆分配对象都持续累积，
runtime.ReadMemStats中的HeapAlloc和HeapObjects只增不减 - 如果代码里有未释放的 goroutine、闭包捕获大对象、或全局 map 持续写入，几小时内就可能 OOM
-
SetGCPercent(-1)返回旧值，建议保存并封装成可回滚操作，比如：old := debug.SetGCPercent(-1); defer debug.SetGCPercent(old)
GODEBUG=gctrace=1 怎么确认 GC 是否真被禁用了
加这个参数启动后，每次 GC 触发都会打印一行日志，形如：gc3@0.123s5%:0.1+0.2+0.3ms clock...。如果禁用成功，你只会看到启动时的初始化 GC（gc1），之后长时间（比如 10 分钟）无任何 gc2、gc3 日志，且 HeapLive 持续上涨，才说明生效。
注意两个干扰项：
- 即使禁用，
go tool trace里仍可能看到标为 “GC” 的小块，那是 runtime 内部的 sweep 或 assist 工作，不是完整 GC 循环 - 如果日志里出现
scvg（scavenger）相关输出，那是内存归还 OS 的行为，和 GC 无关，别误判
排查 GC 异常时，比“关不关”更关键的是定位根源
线上服务突然 GC 频繁、STW 时间长，第一反应不该是调 GOGC 或禁用，而应确认是否真由 GC 导致：
- 用
go tool trace -http=localhost:8080 ./app打开 trace，看 timeline 里 GC pause 占请求延迟比例是否 >5% - 跑
runtime.ReadMemStats，重点盯PauseTotalNs / NumGC算出平均停顿，若单次 -
GODEBUG=gctrace=1输出中，如果HeapLive（最后一个数字）持续上涨不回落，说明对象根本没被释放，调参没意义，得查代码里的泄漏点
真正难的从来不是怎么关 GC，而是怎么让对象不逃逸到堆、怎么避免 goroutine 积压、怎么让缓存有明确淘汰逻辑——这些才是 GC 压力的源头。
