Go GC默认开启自动运行，需通过GODEBUG=gctrace=1观察触发时间、STW时长及堆变化；制造GC需显式堆分配大对象，避免栈分配小变量。
Go 的垃圾回收（GC）不是靠“搭环境”就能“测试出来”的——它默认开启、自动运行，你写完 main 函数一跑，GC 就在后台干活了。真正需要你主动干预的，是观察它、调它、验证它是否按预期工作。
如何确认 GC 正在运行
别猜，直接看日志。Go 提供了内置开关，打开就能看到每次 GC 的触发时间、暂停时长、堆变化：
- 启动程序时加环境变量：
GODEBUG=gctrace=1 - 或者代码里提前设置：
os.Setenv("GODEBUG", "gctrace=1")（需在import "os"后、main前） - 输出类似：
gc 1 @0.021s 0%: 0.024+0.19+0.012 ms clock, 0.096+0.12/0.27/0.048+0.048 ms cpu, 4->4->2 MB, 5 MB goal, 4 P
其中关键字段：@0.021s 是距程序启动的时间，0.024+0.19+0.012 ms clock 是 STW 时间拆分（标记准备 + 并发标记 + 标记终止），4->4->2 MB 表示 GC 前堆 4MB → 标记后 4MB → 清扫后剩 2MB 存活对象。
怎样制造可观察的 GC 触发
默认 GOGC=100，意味着堆增长到上次 GC 后存活堆的 2 倍才触发。但你刚启动程序，存活堆几乎为 0，所以得先“喂”出可观测的内存压力：
立即学习“go语言免费学习笔记（深入）”；
- 避免用小变量或短生命周期对象：它们大多分配在栈上，不走 GC
- 显式在堆上分配大量对象，比如：
make([]byte, 1（1MB 切片）重复几十次 - 用
runtime.GC()强制触发一次，再观察后续自动触发节奏 - 注意：频繁调用
runtime.GC()会强制 STW，仅用于调试，不要留在生产代码里
常见误判：为什么没看到 GC 日志
不是 GC 没工作，而是条件没满足。以下情况会导致 GC “静默”：
- 程序内存占用太低，远未达到
GOGC阈值（比如只分配了几 KB） - 对象全在栈上分配（如小结构体、短生命周期局部变量），GC 只管堆
-
GODEBUG=gctrace=1没生效：检查是否拼错、是否在子进程里运行、是否被父进程覆盖 - Go 版本较新（1.20+）且启用了
GOMEMLIMIT，可能优先受内存上限约束而非GOGC
GC 参数调整的实际影响点
GOGC 不是“越小越好”，它本质是在内存和 CPU 之间做权衡：
- 设成
50：GC 更勤快，内存峰值低，但 CPU 开销明显上升（尤其高并发写场景） - 设成
200：GC 更懒，内存占用翻倍，但单次 GC 暂停时间未必变长，吞吐可能更高 - 容器环境务必设
GOMEMLIMIT（如1G），否则GOGC在内存受限时可能失效，导致 OOM 被 kill - 修改参数必须在程序启动前生效，运行中调
debug.SetGCPercent()仅对后续 GC 生效，且不能低于 1
GC 的并发性、STW 时长、写屏障行为都深度耦合在 runtime 里，你改不了算法，只能调接口和阈值——真正要“测试机制”，重点不是看它动不动，而是看它动得是否符合你设定的约束条件。
